Interfacing to the DOSonCHIP
Cliff L. Biffle
Posts: 206
I got my DOSonCHIP module in the mail yesterday, and wrote a simple program for interfacing with it.
It turns out to be remarkably easy; most of my time was spent figuring out the pin functions (their datasheet is a joke). Here are my notes and code.
Connecting the DoC to the Prop: Simplest Possible Circuit
There are three lines the Prop must drive, and one you must tie to ground. (Well, and also VCC/VSS.) The hookups below are designed for the Propeller Demo Board; users of other boards, adapt the pins to suit.
Connect:
- UART_TX (pin 3) to P7
- UART_RX (pin 4) to P6
- RESET# (pin 5) to P5
- CTS (pin 13) to VSS
- DoC's VCC to Demo Board's VDD
- DoC's VSS to Demo Board's VSS
There's nothing special about the I/O pins I chose, except that they line up directly with the corresponding pins on the DoC, so short jumpers are all you need. Picture attached.
The Details the Datasheet Forgot
Disregard what the manual tells you: UART_TX is the DoC's transmit (host receive), and UART_RX is the DoC's receive (host transmit). Both these lines are non-inverted direct-drive logic (e.g. not open collector/drain) and require 8N1.
The manual states that the RESET# line can be left hi-Z when you're not trying to reset the device. This has not worked for me. The only way I can get the DoC to speak is by actively driving RESET# high.
Use of the RTS/CTS pins is required. CTS's MARK state is logical low, so tying it to ground tells the DoC it can always send. (Using low for MARK when the data lines are noninverted seems backwards to me, but I haven't done this in a while.)
115,200 bps was no problem, though my terminal got pretty flaky. (It's not the best code I've written.
) Once PropellerForth's driver is working I'll give it a go at 230,400. (Nearly floppy speed!)
As you can see from my screenshot, while the chip claims FAT16/FAT32 compatibility, it does not support the vfat long filename standard. (Since this predated FAT32 by several years, it strikes me as misleading, though technically correct; people think of FAT32 as a long-filename filesystem.) The chip requires all filenames in your commands to be in uppercase, but the commands in lowercase.
I can't figure out how to close a file handle; the 'q' command doesn't work like the manual says it does, and the 'c' command (referenced only indirectly from the firmware update page) seems to only work in some cases. Issuing a 'q' seems to close all file handles.
And, finally, the reason they don't have timing info on the datasheet seems to be "the chip is pretty damn slow." They seem confident that they can fix this.
The SPIN code
PropellerForth's full-duplex serial driver isn't working yet, so I wrote a demo in SPIN. It's basically a simple serial terminal, albeit a very slow one (if you push it much above 9600 bps, it will start dropping characters due to buffer overruns). It uses a TV and PS/2 keyboard to interact with the DoC.
Remember that the DoC does not support line editing -- in particular, backspace. Type carefully. (A more advanced terminal would buffer commands a line at a time and allow editing, but this is a before-work hackjob.)
Archive and screenshot attached.
Post Edited (Cliff L. Biffle) : 11/16/2006 6:10:12 PM GMT
It turns out to be remarkably easy; most of my time was spent figuring out the pin functions (their datasheet is a joke). Here are my notes and code.
Connecting the DoC to the Prop: Simplest Possible Circuit
There are three lines the Prop must drive, and one you must tie to ground. (Well, and also VCC/VSS.) The hookups below are designed for the Propeller Demo Board; users of other boards, adapt the pins to suit.
Connect:
- UART_TX (pin 3) to P7
- UART_RX (pin 4) to P6
- RESET# (pin 5) to P5
- CTS (pin 13) to VSS
- DoC's VCC to Demo Board's VDD
- DoC's VSS to Demo Board's VSS
There's nothing special about the I/O pins I chose, except that they line up directly with the corresponding pins on the DoC, so short jumpers are all you need. Picture attached.
The Details the Datasheet Forgot
Disregard what the manual tells you: UART_TX is the DoC's transmit (host receive), and UART_RX is the DoC's receive (host transmit). Both these lines are non-inverted direct-drive logic (e.g. not open collector/drain) and require 8N1.
The manual states that the RESET# line can be left hi-Z when you're not trying to reset the device. This has not worked for me. The only way I can get the DoC to speak is by actively driving RESET# high.
Use of the RTS/CTS pins is required. CTS's MARK state is logical low, so tying it to ground tells the DoC it can always send. (Using low for MARK when the data lines are noninverted seems backwards to me, but I haven't done this in a while.)
115,200 bps was no problem, though my terminal got pretty flaky. (It's not the best code I've written.
) Once PropellerForth's driver is working I'll give it a go at 230,400. (Nearly floppy speed!)As you can see from my screenshot, while the chip claims FAT16/FAT32 compatibility, it does not support the vfat long filename standard. (Since this predated FAT32 by several years, it strikes me as misleading, though technically correct; people think of FAT32 as a long-filename filesystem.) The chip requires all filenames in your commands to be in uppercase, but the commands in lowercase.
I can't figure out how to close a file handle; the 'q' command doesn't work like the manual says it does, and the 'c' command (referenced only indirectly from the firmware update page) seems to only work in some cases. Issuing a 'q' seems to close all file handles.
And, finally, the reason they don't have timing info on the datasheet seems to be "the chip is pretty damn slow." They seem confident that they can fix this.
The SPIN code
PropellerForth's full-duplex serial driver isn't working yet, so I wrote a demo in SPIN. It's basically a simple serial terminal, albeit a very slow one (if you push it much above 9600 bps, it will start dropping characters due to buffer overruns). It uses a TV and PS/2 keyboard to interact with the DoC.
Remember that the DoC does not support line editing -- in particular, backspace. Type carefully. (A more advanced terminal would buffer commands a line at a time and allow editing, but this is a before-work hackjob.)
Archive and screenshot attached.
Post Edited (Cliff L. Biffle) : 11/16/2006 6:10:12 PM GMT
320 x 240 - 42K
320 x 240 - 43K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 11/16/2006 6:37:49 PM GMT
Several of their FAT-patent claims have recently been overturned, and others are still in litigation (the Wikipedia article actually has a good collection of links on the matter).
8.3 is good enough for my application, but I think the DoC folks should either (1) implement LFN or (2) explicitly document that the feature is missing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 11/16/2006 6:45:33 PM GMT
Not on FAT filesystems.
I'm referring to the method for reading/writing long filenames onto FAT filesystems using the standard introduced in Win95 -- the idea covered by this patent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Mac OS X, Linux, and FreeBSD, however, aren't derived from AT&T's code, and the license wouldn't transfer. These are, if you will, rogue implementations of vfat, with a number of obvious targets to sue (Apple?) -- and yet Microsoft has been quiet, has an excellent relationship with the BSD camp (including use of our TCP stack), and has even extended patent protection agreements to some Linux distributors.
IANAL, but these FAT patents seem to be more bark than bite -- and the bark itself has trailed off in the past year or so.
In any case -- the DoC does not do long filenames, just so everyone understand before purchasing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
I got my DOSonCHIP. Plugged it into the bread board on my demoboard according to the documents and
programmed it with the doc_demo.spin source you provided.
I get the banner "Press Enter twice to begin". pressed <cr> twice and nothing happened.
Am I missing something or have I fried another device? I'm not much of a hardware person...
Thanks, David