μblog: engineering from the trenches

This is in part a follow-up to the CC1110 IC Friday post from a few weeks back. TI has released a USB-dongle based development kit featuring their CC1111 system-on-chip radio communications IC. The board features an msp430 and the CC1111 on a self-contained USB stick and is about 50USD, a very reasonable price. For those that want something cheaper, the samples for the family of low-power RF chips are already available and shipping. Finally, the board reference design can be found here and is also mirrored below.

( swrr049.zip )

del.icio.us | digg

Finally finished a rough card reader for my 8051 (formerly PS3 emulator) board. The board runs the program from NVRAM which starts at 0×8000, so the included hex file starts there. This is in no way efficient as it just polls the various control lines on the card reader and calls most of the I/O routines from PAULMON2. Because of this, the cards should be swiped slowly if this is to be used. One final note is that the software strips the leading and trailing zeros from the data and the first hex number is total bits read from the card.

( card-test.c ) ( card-test.ihx )

del.icio.us | digg

An easy way to develop programs for the 8051 is to build a board and write the PAULMON2 monitor to the chip. Furthermore, it is useful to hook up an max232 chip for rs-232 functionality as well as a NVRAM chip for program storage and a reset button. The PAULMON2 monitor has plenty of built-in routines, so, here is a very simple example of accessing the built-in features using code taken from Dr. Kin Hong Wong’s class site.

del.icio.us | digg

When setting the baud rate on the S51 UART, there are four modes. Two of these modes divide the clock rate by either 16 or 32 and use that to set the baud rate, while the other two modes are triggered based on Timer1 overflow. Most places recommend that you set Timer1 into mode 2: 8 bit timer with auto reload. In this mode, you set TH1 to some value (>255) which will cause it to verflow every (CLOCK RATE)/([192 or 384]*(desired baud rate)). This can work well if you have a crystal that matches a baud rate pretty well, but that is not allways the case. If you have a crystal that does not give a desired baud rate, or you want to automatically detect the baud rate (as is done in PAULMON2) fancier timing may be needed. The benefit of mode 2 for Timer1 is that it breaks up the 16-bit timer into high and low bytes, TH1 and TL1 respectivly. TL1 is used for the timer, and every time it overflows, it is set to the value of TH1 and the timer is restarted. By using the timer in 13-bit or 16-bit modes, we can have better timing control than with the 8-bit mode. The downside is that the timer does not auto reload so we need to use an interrupt handler (for IE1) to manually reload the value. Don’t forget to take into account the time it takes to execute instructions involved in handling the interrupt and returning in your calculations. With this in hand, you can have a wider choice of crystals for a certain baud rate. Don’t worry about getting very close to it, that is, dont worry about getting higher resolution than provided by your clock source, as it wont do you any good.

A particularly elegant way is demonstrated by Paul Stroffregen in PAULMON. PAULMON waits for a CR character to be sent to determine the effective baud rate. It uses a timer to measure bit transmission times as it matches the bit pattern for the CR and then sets the baud rate based on those calculations. The source code is available so it provides a nice example. (This document notes that as much as a 2.5% communication clock mismatch is tolerated.)
( doc4316.pdf ) ( doc2487.pdf )

del.icio.us | digg

I finished soldering the prototype 8051 board and started working on getting the timing right to output a NTSC signal. As a reminder, each line has a ~5us blanking period, a ~5us front porch, and a ~52us active segment. It has been non-trivial to get the timing right using SDCC, so we will see what happens with this. Right now, I would be happy to generate an 8×8 checkered test patter on the screen, far short of implementing text-writing capability as I had originally hoped. That is to say, it is still possible, but I would have to do most of the coding in assembly to get the timing just right and the needed resolution, something I might not be willing to invest too much time into with parts for my msp430-ethernet project on the way. Hopefully I will have something to display on a TV tomorrow or day after.

del.icio.us | digg

Finally got my 5V, PDIP 8051 development board designed and bread-boarded. I know I planned to go with the DS80C400, but it is more complicated and the Atmel works fine (for now). I ended up writing PAULMON2 very slowly onto on AT89S51 and using an 8KB NVRAM for program memory. The small trick is to wire the WR to WR and RD to PSEN, so the NVRAM is written like data memory and read like program memory. An OR gate between RD and PSEN outputs would effectively merge the separate program and data address space and make a very simple development target. As for development, I have been using sdcc (with –code-loc option) to generate code that starts at the start address of the NVRAM (0×8000). I will probably start working on the video code tomorrow try to solder the dev board together.

del.icio.us | digg

The in-circuit programmer that I was using for the 8051 (AT89S51) seems to have some problems with programming the chips correctly. The data is sent and verified, but then a memory map pulled from another method does not show the same results. To be more specific, I wrote a serial programmer in LabView that I used to verify the operation of the parallel-port ISP and found that the parallel-port ISP did not program all of the bytes correctly. Although the LabView programmer can program the whole chip without problems, it is very, very slow (doesn’t take advantage of page-write or DIO buffering.) I did manage to put PAULMON2 on one of the AT89S51 chips some time ago, so the current plan is to use that chip and external nv-ram to test code on or just move to a DS80C400, which has a built-in serial monitor. It seems that using a boot monitor is the easiest path to testing code on the 8051. For kicks, the poorly done LabView code is attached at the end.

( nchernyy-serial-programmer-slowio.zip )

del.icio.us | digg

My digikey order came in today, but some of the msp430-ethernet parts are on backorder until late March. I am not going to lay out the PCB and have it fabricated until I have these components, as the results can be devastating. To keep myself busy, I have been looking around at the Playstation3 specs released by Sony and have been thinking about designing a PS3 emulator based on a single 8051. I hope to have a playable Metal Gear Solid demo by the end of the month!

del.icio.us | digg