This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.
Posted: Fri Sep 16, 2005 9:28 pm
I have a question about the SCI and stop bits. I am using the MC9S12NE64 and assume that the SCI in this device is the same as in other HC12 types.
It is possible to configure 8 or 9 bit mode, with or without parity. This means that I can set 8 bit mode without parity and 8 bits are transmitted and received. If I want to use 8 bits and parity I have to set 9 bit mode so that the last bit (MSB) is set with the parity bit. If I want 7 bit characters with parity this is possible using 8 bit mode with parity enabled.
However I am wondering about the case of 7 bit characters without parity? Must 8 bit mode, no parity be set with the MSB always set to '1'? This would then produce 7 bit transmissions with 2 stop bits (do you all agree?).
Then there is the fact that only 1 stop bit is possible in 8 bit mode with parity (if I have understood everything correctly).
The general question is then - if the SCI can only do 1 stop bit, what can be done if the receiver being sent to is set to 2 stop bit mode of operation (or 1,5bit)? 2 back to back transmitted characters with only 1 stop bit may cause a problem (?)
So what is the HC12 philosophy behind this design? How can 7 bit 1 stop be sent and how can 2 stop bit 8 bit character transmissions with parity be supported??
Posted: Fri Sep 16, 2005 10:43 pm
Mark,
> However I am wondering about the case of 7 bit characters without
> parity? Must 8 bit mode, no parity be set with the MSB always set
> to '1'? This would then produce 7 bit transmissions with 2 stop bits
> (do you all agree?).
Correct, but this is OK for transmission if you have a little bandwidth to spare. It's always acceptable to send more stop bits than needed. The only cost is that your maximum characters per second is 11% lower. That's often acceptable.
The bad news is that 8-N-1 won't work for receiving 7-N-1. If the remote device ever sent two characters with minimum spacing, you would get a framing error.
If you can get the remote to use 7-N-2 or 7-M-1 ("mark" parity), reception with 8-N-1 will be OK. Just strip the MSB on each received character.
> The general question is then - if the SCI can only do 1 stop bit,
> what can be done if the receiver being sent to is set to 2 stop bit
> mode of operation (or 1,5bit)? 2 back to back transmitted characters
> with only 1 stop bit may cause a problem (?)
Run your transmissions out of a timer interrupt, instead of out of the SCI interrupt. Set up the timer to get the number of stop bits you want.
A delay loop in the transmit loop could do the same thing.
If you have to interoperate with 1.5-stop-bit equipment, send 2 stop bits and accept 1 stop bit. It will be fine.
> How can 7 bit 1 stop be sent and how can 2 stop bit 8 bit character
> transmissions with parity be supported??
The bail-out technique is to bit-bang the serial. My lab has a device that is downright wierd: It wants async serial in 14-E-2, with opposite polarity stop bits (the first stop bit is a space, the second is a mark), all at 100.0 kbps. The HC12 talks to the device by bit-banging one of its port pins.
Posted: Sat Sep 17, 2005 11:28 am
Thanks for the details. It seems as though i have more or less understood the operation and restrictions, although don't understand the Freescale solution since it will probably cause some problems with interfacing to general equipment.
Bit banging can't be used because the project needs more or less continuous throughput and the processor is doing Ethernet TCP/IP in parallel as well as the application. The interrupt routine must be as short as possible (it consumes about 15% of the power at the moment at 115k).
I am offering a new project where the device should be configurable to suit the other side (baud, parity 7/8 bit and stops 1,1.5, 2). I will have to see whether they accept the restrictions (I will say we can only do 1 stop since the rest is ok) and it will either be accepted or they will reject the chip - have to wait and see.
Regards
Posted: Mon Sep 19, 2005 4:07 pm
One solution to the problem is to put an external UART onto your board. One board designed in my lab has an HC12 controlling a TI 16C752B UART. This design needed the deep FIFOs and operation to 460.8 kbps, so we went with an external UART. This board uses a 68C812A4, which has an external bus, but you could bit-bang an Intel bus interface on any HC12 and get pretty decent bandwidth, particularly if you take the advantages of the UART FIFO into account. Anyway, if you can afford the extra chip, it will probably give you every serial format the customer is looking for.
Maxim/Dallas sells an SPI-interfaced UART, too, that people on the list have reported using with HC12s.
Posted: Mon Sep 19, 2005 7:10 pm
I will probably be adding a 16k or 32k SPI EEPROM so that I can free up 16k of internal FLASH memory (presently used as file system for htlm and parameters). This will give more code space - but make paging necessary, which wasn't needed until now.
With this and an external serial controller as well, the design will get messy. Therefore I have decided to offer the solution as it is, with the known configuration restrictions. I don't have any real worries with the internal SCI at 115k and it should also be ok at 230k (with no FIFO - based on present measurements and estimations).
The customer has more or less decided that he wants to move to the Atmel AT91SAM7X128 for his project due to the known restrictions, although there may still be a chance (possibly for a reduced version) with the MC9S12NE64. I should know in the next day or so - the AT91 looks fun anyway...there are still lots of opportunities with the NE64...
Posted: Tue Sep 20, 2005 4:05 am
> The customer has more or less decided that he wants to move to the
> Atmel AT91SAM7X128 for his project due to the known restrictions
The new SAM7X series is incredible. You get Ethernet and USB 2 and very high 32 bit performance. And they're probably cheaper than a similar solution with 9s12 devices because a 9s12 solution requires more support chips. Higher performance AND lower cost makes it an obvious choice.
Freescale has been reluctant to make the 9s12 devices more powerful by adding USB and/or Zigbee. I know they are offering Zigbee on some hcs08 devices but they seem to have passed on adding this to the 16 bit platform. I've been told that its hard to be a "middle kid" in a family and now I understand what that means!
The rest of the world isn't standing still ... XGate is cool, but its most useful if coupled with other high performance peripherals (preferrably on chip).
Sorry to sound pessimistic but I had to vent a bit. We all know (though we hate to admit) that the automotive market is the only serious driving force behind the 9s12 family.
Posted: Tue Sep 20, 2005 7:04 am
I don't know 9s12 apart from the NE64, which I decided on purely due to the internal 10/100 MAC + PHY. This chip is great because it really allows a single chip system in many applications. The full parts list of a board we are making is NE64 + 25MHz crystal + a few coupling caps + about 4 resistors + Ethernet RJ45 with magnetics (+ connectors and PCB of course).
Posted: Wed Sep 21, 2005 1:59 pm
Thanks for your concerns. We understand your frustration with the lack of USB on the S12 platform. We do, however, offer 10/100 Ethernet and integrated Ethernet PHY with the MC9S12NE64 device.
After carefully analyzing the market, we decided to develop our future high performance Ethernet and USB devices with our 32 bit (ColdFire) platform. In addition, we plan to offer documentation for an easy migration from our S12 to our ColdFire platform. Furthermore, the price target for the 32 bit devices is similar to the current S12 Ethernet device, which means you get a higher performance MCU for the equal price.
Posted: Wed Sep 21, 2005 8:44 pm
[...]
> After carefully analyzing the market, we decided to develop our future
> high performance Ethernet and USB devices with our 32 bit (ColdFire)
> platform. In addition, we plan to offer documentation for an easy
> migration from our S12 to our ColdFire platform. Furthermore, the price
> target for the 32 bit devices is similar to the current S12 Ethernet
> device, which means you get a higher performance MCU for the equal
> price.
I looked around the site, and I couldn't see any specs on the chip that has an integrated phy... I assume that this chip will be released in the future? Right now the MCF5208 can't replace the NE64 due to lack of onboard flash and ethernet phy... For many applications, the board space necessary for a PHY and/or flash is problematic...
I like the example board you guys pictuer where a complete NE64 + RJ45 was on a board about 1"x1.5" in size.. 
Posted: Wed Sep 21, 2005 3:42 pm
At 06:59 AM 9/21/2005, you wrote:
>Thanks for your concerns. We understand your frustration with the lack
>of USB on the S12 platform. We do, however, offer 10/100 Ethernet and
>integrated Ethernet PHY with the MC9S12NE64 device.
>
>After carefully analyzing the market, we decided to develop our future
>high performance Ethernet and USB devices with our 32 bit (ColdFire)
>platform. In addition, we plan to offer documentation for an easy
>migration from our S12 to our ColdFire platform. Furthermore, the price
>target for the 32 bit devices is similar to the current S12 Ethernet
>device, which means you get a higher performance MCU for the equal
>price.
Ummmm..... so, you are going to replace a $13 chip with 64K of FLASH and a bunch of peripherals with a $33 chip (MCF5482, Arrow Electronics, quantity one) with no FLASH but with 384 pins?!? Is there any way you can get rid of the MMU, FPU, about 200 pins and about $20 off the price?
