You should set Extended Fusebit Q into 0 then Extended Fusebits became &HF8 Boot reset vector should simply point to Bootloader - not to $00 cause it means flash start where Bootloader is on the flash end.
Dear All, I adapted the bascom bootloader example to my processor AVR (ATMEGA168 -20PU), crystal and baud rate. [code:1:a15dde6e4f] $crystal = 6144000 $baud = 57600 $regfile = "m168def.dat" Const Loaderchip = 168 [/code:1:a15dde6e4f] I sent the compiled program via ISP device to the AVR using the fuse set decribed in the attached image. Does this set allow the bootloader to work ?
When trying to load another program I use the fuses set as follows
$prog &HFF , &HE7 , &HDF , &HF9 When selecting in the IDE the MCS Bootloader I put the serial values on COM11 ( USB,RS232 adapter with 57600 baud) In the MCS loader section I put Bootsize to 1024 and reset to soft with the value ABC(123) When trying to send another compiled program to the AVR COM 11 gets opened and it says sending init byte. The bootloader gets stuck and after cancellation I see in the Log Window Loader returned: 0
I assume that i did something wrong on the fuse bits.
If you have some adivce to me it would be great.
best regards Christian
[b:a15dde6e4f][color=red:a15dde6e4f](BASCOM-AVR version : 22.214.171.124 , Latest : 126.96.36.199 )[/b:a15dde6e4f][/color:a15dde6e4f]
'The dataport is the portname that is connected to the data lines of the LCD 'The controlport is the portname which pins are used to control the lcd 'CE =CS1 Chip select 'CE2=CS2 Chip select second chip 'CD=Data/instruction 'RD=Read 'RESET = reset 'ENABLE= Chip Enable
As long as both ends use the same baud rate, it does not matter what it is. Bascom neither knows or cares. I have often done this, just to confuse people who want to meddle with gear. There are many non standard baud rates you can pick by directly writing to the AVR baud rate registers, and of course selecting odd crystals, like you are doing.
Thinking about your question about what is "special" about the Enhanced DMA in E Series XMEGA (versus the DMA provided in A Series), I can provide 2 comments:
1. The EDMA tries to provide 4 DMA channels (like the A Series), but in a "small" and inexpensive chip. But to get 4 channels, we need to work with Peripheral DMA channels instead of Standard DMA. As far as I can see, Peripheral channels are OK in some functions and not others. For example, they work well for USART Receiving, but do not work for USART Transmitting.
2. The EDMA provides a Byte or Word search function where a SRAM Array can be searched for a match. The following code works for searching a byte: [code:1:7c541713a8]$regfile = "xm32e5def.dat" $hwstack = 200 $swstack = 200 $framesize = 200
Edmach_rx_isr: If Edma_intflags.0 = 1 Then 'DMA Channel 0 Transaction Interrupt Edma_intflags.0 = 1 'Clear Interrupt Match_ok = 1 'set flag End If Return
BUT, the search feature has some significant problems:
- it must be done with the CPU fully active and, as far as I can determine, only on SRAM variables (not Flash or EEPROM), - for each byte searched without a match, the channel is disabled has to be re-enabled by EDMA_CH0_CTRLA = EDMA_CH0_CTRLA Or &B10010000 - a match throws the EDMA Interrupt, but unless the index is saved before the interrupt, the value of the index is reset to 0 once the interrupt occurs.
So, after spending time to figure this out, I cannot see much use for the Enhanced DMA SRAM search feature.
[PS: to tried to see if the match feature could be used in a way similar to Bytematch on a USART receiving channel. But, as far as I can determine, match only works on SRAM array variables.]
I [i:68bc47fed2]think[/i:68bc47fed2] the answer to this question is "yes" ... but, I just want to double-check to be sure.
Assuming that I have total control of "both ends" (i.e., the transmitting device, and the receiving device), then there should not be a problem using a non-standard baud rate for communication between two MCU's - correct?
A lot of you might be wondering ... why would I want to do this? :shock: It is a good question. Here is why ...
In some cases, I have pre-built hardware which is already configured with 16MHz crystals (which happen to be in small, surface mount packages, and very difficult to unsolder/change). 16MHz is not one of the "magic" clock speeds which result in 0%-error, stable baud rates (especially not at higher speeds like 115K).
So, in cases where I have to live with a 16MHz clock, and I am communicating between two devices where I have total control over the firmware (BASCOM) at both ends, I am very tempted to just use 125K baud (instead of 115K). 125K works out nicely from 16MHz, and results in 0% timing error. Sure, it is not a "standard" baud rate, but do I really need to care?
Does BASCOM support non-standard baud rate values? And ... does anyone see an issue with this (other than the obvious, "you won't be able to hook up the devices to other standard stuff")?
[b:68bc47fed2][color=red:68bc47fed2](BASCOM-AVR version : 188.8.131.52 , Latest : 184.108.40.206 )[/b:68bc47fed2][/color:68bc47fed2]
yes there are plans but like you noticed, it is more a tiny xmega, than a new tiny. it also uses yes another programming protocol. while the dat files are ready it will not help much since a lot of other changes are required for these chips.
we do not give a release date. but i would get a free kit. i had to pay for mine