115200 on NE64?

[Dell]

Does anyone know of a way to improve the accuracy of the baud rate on the MC9S12NE64 when running 115200? It does not seem to be accurate enough for some of the devices we are trying to connect. The fact sheet on the device claims exact baud rate matching but we are measuring an error of more than 5%.

[mjbcswitzerland]

Hi Dell

I have also experienced the problem. I never had it when working with a PC but when using another embedded device with a not so good tolerance the mismatch can be adequately large to get errors - I remember then understood each other in one direction but not always in the other. (I think that the best you can get is 104,2k which is quite a bit off...but if two NE64s are communicating it is of course perfect...since they are both off by the same amount!)

The problem is the 25MHz quarz used on the NE64 due to the Ethernet controller, which needs exactly 25MHz multiplied up. If you don't need the Ethernet (but why take an NE64 in this case...) then another crystal could be used (multiple of 1.8432MHz).

Unfortunately when working with the 25MHz crystal 115200 can not be guarantied. There are also a numbner of other restrictions about the number of stop bits, parity and number of characters. Some combinations are possible but some are not, which makes it difficult to use in applications where user selectable settings are required (see for example an on-line demo at http://212.254.22.36 - go to the side "Configure serial interface". This project was intended for an NE64 (and also runs on it) but not all settings do work properly.

Take a look at the M5223X (the NE64's big Coldfire brother). It is more or less footprint compatible and has much better SCI support so it will run at high speeds with no problems and is flexible enough to satisfy all user demands.

Also take a look at the threat at http://groups.yahoo.com/group/68HC12/message/11712 (it is quiet long with a fair amount of detail about the NE64 and possible solutions).

Regards

Mark Butcher
www.mjbc.ch

[DrSeuss]

Maybe I'm confused. But I checked the math again.

25MHz / 16 / 13 (rate reg) = 120192 baud. This is 2% error.

The RS232C specification used to require a 4% min tolerance. Last time I read it anyway.    :smileyhappy:

I know that the mismatch may be different at different rates, but this speed should work.

I reviewed the referenced thread and cannot comment on mismatched settings, but 8/1/n should not be a device issue.

[mjbcswitzerland]

Hi Doc

Oooops. Don't know where that came from... - of course you are right with the calculation. If one device is +2% and the other is -2% then it could still be critical...different devices of course.

Just a note on calculations in the program:
DIVIDE = 25000000/16/115200 is 13.56337. The best value to set is in fact 14 and not 13 (only marginally though...). Therefore it shows that this speed is rather unfortunate since it requires a value right between the two possible integers 13 and 14.
It also shows that the better way to calculate the value in code (assuming a define or even at run time) is
DIVIDE = (CLOCKSPEED/16 + ulSpeed/2)/ulSpeed;

This performs up/down rounding so can squeezes a little more accuracy out of the calculation which certainly helps when the divide ration gets smaller.

By the way. I did have to decide against the NE64 in a LAN/serial converter application since the required speed of 230400 (which is really 3,2%) seems pushing toward the acceptable limit (marketing expects 230'400 or higher since most such devices give this as their upper speed range). However the biggest argument was not actually this but the fact that certain combinations of 7 bit/8bit/even/odd parity are not possible.

Regards

Mark Butcher
www.mjbc.ch

[DrSeuss]

My math tells me you should be within 2.12%. Are you sure you do not have the IREN bit set? This reduces the divide factor by two. Math shows an error of 6.11% with this function enabled.

Otherwise, make sure that you have a high speed RS232 driver.