Hello all,
Matthias Trute writes:
> Hi,
>
> I need some independent tests, so I'd like to ask for volunteers.
>
> The command prompt got its characters via a simple interrupt
> routine. That works quite well for years now. However some users
> wanted to replace this routine with some other (forth hll) code
> and were unpleasantly surprised that the word INT! did not do what it
> does for all other ISR's. Not surprisingly since that (and only that)
> one interrupt was not dealt with the way all other interrupts got
> handled.
>
> That has changed now. Now every character is processed the "standard"
> way and the INT! word can easily change the actions. I did some
> tests, but for the high speed ones I lack some resources. So I ask
> you to test and give feedback whether the new code works for serial
> line speed like 56k (or more) - my boards don't have the necessary
> baud rate clock quartzes...
>
> Please get the sources from the repository trunk after version 2141
> and recompile them. To check if everything works good enough,
> it is sufficient that you can enter commands at all....
The question was: does receiving data work if serial receive is
done via deferred ISR, not the hard coded one. Especially does
it work at higher baud rates?
So I set out today to run some tests.
Surprisingly, it's not all that clear cut ...
Experiment on atmega644p:
- amforth trunk (6.3), revision 2156
- set WANT_ISR_RX = 1 (default)
WANT_ISR_TX = 0 (default)
- set BAUD_MAXERROR to 10 (default) --- which corresponds to 10%
error allowed, if I read the docs correctly.
- set F_CPU to 18432000
- set BAUD to 4800 ... 115200, 230400, 460800, and maybe higher
For a given baud rate I did
- assemble (wine+AVRASM2) and flash (avrdude) the controller
- connect via minicom, list the dictionary with "words"
- upload a large program file
- from main.fs
- resolve all includes with a small script
- strip (almost) all comments and empty lines with another
small script
- results in 2735 words
- upload with (an old, stupid version of) amforth-upload.py
There should be no receive errors whatsoever! Loading the file
lasted 162 seconds at higher baud rates.
| f_cpu[Hz] | baud[1/s] | load[s] | |
|-----------+-----------+---------+-----------------|
| 1843200 | | | |
| | 4800 | 216 | loads ok, works |
| | 9600 | 181 | dto. |
| | 19200 | 164 | dto. |
| | 38400 | 163 | dto. |
| | 57600 | 162 | dto. |
| | 115200 | 162 | dto. |
| | 230400 | 162 | dto. |
| | 460800 | | assembly error! |
Results:
1. The assembler refused to configure a baudrate of 460800.
Increasing baud_maxerror did not help. When it compiled (at
200 or so) the serial connection displayed garbage.
I checked the data sheet. It seems to suggest that indeed a
speed larger than 230400 is hard to achieve. But I have not
looked into details let alone tried any tricks.
2. RX: The time needed to upload the file seems to be dominated
by compile time rather than transfer time for baudrates of
19200 and larger. To me this boundary seems surprisingly low
...
3. TX: The time needed to fully list the current dictionary (
words ) does change noticably with higher baud rates. Surely
this was one reason why I switched to 115200 baud.
4. Ever since I switched to using baud rate crystals (11.059200
MHz) and a baud rate of 115200 I have not seen any hickups
while uploading program files --- except occasionally when
using rs485 rather than rs232. But that might have other
causes unrelated to the software on the microcontroller and I
did not investigate further.
5. The tests using a 11.059200 MHz crystal are very similar, the
upload time was 225 seconds. Interestingly:
18432000/11059200 = 1.66 whereas
225/162 = 1.40
Interestingly, the upload time does not scale the same way as
the crystal frequency.
Hope this helps.
Cheers,
Erich
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
