I was wondering if anybody got a c166 to run the debugging at a baudrate higher than 57600baud? if the program becomes large it is odd to watch the loading process rising in 5% steps. i gave the 115200baud a try but it might come from the deviation error and thus didn't work:
f_cpu = 20MHz; S0BRS=0;
with S0BRL=4 i get 125000baud (which is 8%) with S0BRL=5 i get 104167baud (which is 9.5%)
is my calc correct? is there anything else i missed to set/check?
I think the deviation error is the only problem here. With an oscillator frequency like 20 MHz you'll find that your higher baudrate options are extremely limited. You might be more lucky with special frequencies like 18.432 MHz...
in case i did calculate the baudrate correct, i could use the 125000baud. and so have no error at all. but therefore i need a setting in the debugging software to make it suiting to the 125000baud of the controller. unfortunately the setting is not yet there. am i right?
a much harder task is to change the xtal frequency or the scaling factor to suit the software debugging speed of 115200baud as you probosed. that's true.
but therefore i need a setting in the debugging software to make it suiting to the 125000baud of the controller
Well, sorry, but that won't work. The choices available on the PC side are limited the same way (and for basically the same reasons) that kept you from using 115200 on your micro controller. I.e. a standard PC serial port can't run 125000 baud any better than your 20 MHz '166 can run at 115200.
Thanks for your reply.
1.) 125000baud was just a suggestion which suits good to a 20MHz board but is not a must. the initial questions was if there is a setting that makes me able to debug gt. 57600baud.
2.) as the baudrate is generated by the uart it is a setting for the chip itself. depending on the chip your computer owns it is even possible to use higher baudrates than 115200. but i didn't look too much into details concerning this. i guess a handmade serial driver is necessary for that. (but should be worth it)
3.) assuming i did calculate the settings correct the follwoing clock-frequencies are necessary to achive 115200baud
fcpu BS 0 1 BRL 0 3.686.400 5.529.600 1 7.372.800 11.059.200 2 11.059.200 16.588.800 3 14.745.600 22.118.400 4 18.432.000 27.648.000 5 22.118.400 33.177.600 6 25.804.800 38.707.200 7 29.491.200 44.236.800
i was wondering whose board offers the weired frequencies.
if there is a setting that makes me able to debug gt. 57600baud.
Of course there is such a setting --- on your board. But there's almost certainly none that works on both a standard PC serial port and your board.
depending on the chip your computer owns
There's no such dependency to speak of --- I said "standard PC" for a reason. PCs clock their UARTs at a frequency that allows 115200 baud, but not 125000.
Those of all designers who cared enough about PC compatibility of their serial ports that they stopped to think about it a moment before picking a quartz frequency.
For 57600 baud you can choose a setting for BR = 10 (assuming a 20MHz clock). This gives you an actual baud rate of 56818 (error of 1.357% which is less than 2% so should work).
To my knowledge these are standard crystal frequencies: 3,686.400 7,372.800 11,059.200 14,745.600 18,432.000 22,118.400
Which would allow you to achieve 115200 baud.
Newer derivates have a fractional divider so you can reach PC baud rates while still using a whole number MHz clock to support common CAN frequencies and sample point.
Yes, it is possible to drive the debugging at 57600baud. (-) I allready did it successfully. Yet higher speeds would shorten the time needed for downloading the program.
General boards from phytec for example are shipped with 5.0Mhz or similar. So I have just to replace the crystal for a debugging board, I see. (--)
Another joice might be the debugging hardware from keil which needs the special interface on the board. (---) Speeking of downloading time. Is the ULINK much faster than the serial debugging?