TuxScreen on SourceForge TuxScreen CVS search the Wiki
Browsing -> Wiki -> Users -> [BillDanielson]
edit, info, topics, orphans, hubs and nodes, or recent changes in the Wiki create a new user or login

BillDanielson got the TuxScreen to use as a GUI and system to use with some one-button weather instruments and also a PIC system he built that decode those wireless temperature sensors from Oregon Scientific.

BillDanielson has also been playing with the WebPal, another ARM based system. This system makes a good, small, quiet, no-moving-parts Linux server system. You can find out more about BillDanielson did with the WebPal on:




I hooked up my BitScope ( http://www.bitscope.com ) to the SPI port between going to the Wheaties to see if I could figure out something about the protocol. I'm using a TuxScreen running the standard Inferno stuff. Here is what I figured out:

1. The DSP_RESET GPIO pin is indeed a reset...pulling that line low reset the chip.

2. The clock rate for the SPI interface seems to be running at about 900Khz or the 3.6Mhz clock divided by 4 (which would be a 1 in the register I think)

3. I haven't figured out what the RTS line does. When I hook something up to that line, the system panics just after it finishes initializing. Leaving that line unconnected seems to solve that. Looking at that line after booting, there just seems to be noise on it.

4. The CTS line seems to be the indication from the Wheaties that it has data to send. As expected, you see CTS go high, then FRAME goes low, and then 8 bits are transferred. As expected the write bits are zero. It looks as though the Wheaties lowers CTS after each 8 bit transfer, even if it has more data to send.

5. The SA1100 seems to send a byte every so often (looks like about once a second) to the Wheaties. Value seems to be 11101101 assuming I decode the SPI correctly. I've uploaded a postscript dump of that transfer ( http://bill.danielson.com/plot0.ps ). Times are in microseconds.

Since my BitScope doesn't really have enough features to really collect a lot of data, I decided to build a little PIC system that will monitor the data. Also, starting with the pfs168_spi.c code, I've been fiddling with the Linux side, but no success (done before I had done the traces so I was clueless about the parameters). Note that I turned off the alternate UART0 stuff that was in shannon.c since we were using PORT3 rather than UART0

If anyone has any other info on the DSP chip, let me know. I know about shannon.c, but haven't seen anything else.

SourceForge Content of these pages are owned and copyrighted by the poster. SourceForge