I have several versions of that utility. You are right that if I'd used it from the outset I may have avoided the 'problem with the Bytek'.

However it is still best to be able to have root caused the problem.

Michael Karas


PS. The Atmel Part is now running the code that was working well on the SiLabs board despite the 12X versus 1X clocking difference between the execution rate of the two MCUs.

This is on a project where I have one MCU board (SiLabs EVB with an C8051F344) attached to some circuitry and an RTC chip. This board also connects to an 434MHz low cost RF transmitter board. The software on this encodes a time display into a Manchester encoded data stream that is then fed out through the RF at a bit rate of 500baud. (The basic timing unit of the Manchester encoding state machine is 1msec).

I made a separate board that has a string of eight large 7-segment LED displays that are driven from a series of eight TI TLC5916 LED display driver shift registers. This hoard also has one of the low cost 434MHz RF radio receivers on it. The radio output goes to the AT89C4051 on this board. Firmware in the '4051 decodes, validates and syncs to the Manchester data stream to get the 64 bits of data that are meant to format a display on the 7-segment modules. After all bits are received the '4051 shifts them all into the string of display driver shift registers.

The whole RF display update is done once per second as synchronized to the seconds change at the RTC of the transmitter board.

The time display is being made for a gag thing to show the time remaining till 5:00 PM on Friday when it is time to go home from work. I've been calling the project the TGIF display. I share some more details and some pictures of all this when it is finished. I may also post the Manchester source code as an example of how to improve the reliability of using cheap RF transmitters and receivers instead of just trying to feed async UART signals through the RF pipe.


Michael Karas