Hello Marc,
yes i have evaluated the custom code, it runs but sporadic bytes will still fail. I have made the overall experience, that using of any kind of IRQ driven
functions or subs are contraproductive at this level of speed. I have written at least 10 different types of how to read/write, also by using parts in assembler
to read directly from UDR. Furthermore, in my case a word based buffer is not usable because i stronly need to read byte by byte, because of cocatenating
bytes while preprocessing results in special proprietary raw data of the javad. Using word variable can produce bad data.
I agree, this is a very specific application.
The best results, but never error free where catched with free running codes, without any USART IRQ.
As source by the way i have developed a 230400 baud rs232 pattern generator, it generates char patterns which easily can be checked out after recording.
At ne view you will see in a 4096 kB pattern if, for example space and Ü was send, if a byte was gone lost. In the past i have often used the real source but with
not repetitive serial data the troubleshooting is looking for the needle under the mountain ;-)
example:
Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü
Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü
Ü Ü ÜÜ Ü Ü Ü Ü Ü Ü Ü Ü Ü <- missing space error
Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü
Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü Ü <- one char missing
in this manner you can find 5 to 13 errors in a 4096kB recording.
Is that possible to the source code of the AVR-DOS in my case to see how it can be modified to split maybe the delay into parts while reading and storing some data to avoid buffer overrun.
best regards
Ingolf
↧