My first Propeller design
Peter Jakacki
Posts: 10,193
Well I did my first Propeller design late last year and finally got around to building and testing. It turned out successfully, even though I had a glitch there in the beginning with programming through the USB port which utilizes the Silabs CP2102 instead of the FTDI device. The first proto I simply cut and rewired to program from the RS-232 port of my unit but later on I was able to use Remy's Loader which worked without complaints on the CP2102.
This is basically a super USB serial converter or a stand-alone communications terminal. The idea is that I can carry it in my laptop case and whip it out to tackle the most common serial interfaces and protocols. Being electrically isolated means I won't get any nasties breaking through and frying my laptop, especially when I plug it into mains power. I didn't want DTR transitions to trigger a reset in normal use so I have a push-button to enable this when it is being reprogrammed. Personally, I use break detection on other designs to trigger a reset.
PORTS
ADVANTAGES OF USING A PROPELLER
The RTS/CTS lines on the RS-232 can also become a secondary full-duplex RS-232 port. The Propeller is very versatile due to the way that there are very few dedicated pins and any COG can access any port pin. On conventional CPUs I would connect a dedicated RXD and TXD pin to the RS-485 chip plus the TE line. As RS-485 is half-duplex I tie the RX-485 RXD and TXD together to one Propeller pin not only saving one pin but having the flexibility without sacrificing resources.
There is a implicit advantage to using the Propeller in that practically any serial interface can be emulated in software smoothly and reliably. If I needed a synchronous HDLC interface on RS-485 then it is possible without having to redesign.
I really didn't need a VGA and PS/2 port on this unit but it has turned out well as I can use the SCC as a communications terminal or a RS-485 networked terminal/display. I am even using the VGA simply for communications diagnostics, quite useful.
A production version will use faster opto-couplers and perhaps even the FTDI USB serial chip if necessary. There is also a need for a simple regulator and DC power jack for those stand-alone applications where it won't be connected to USB permanently.
WHAT I THINK
My overall experience with the Propeller is very positive. Other CPUs have more program memory or faster dedicated peripherals which may sway me a bit but I tend to design with things that are fun too, of course it has to meet the design goal criteria. So if the Propeller meets this criteria along with XYZ and ABC then I would choose the Propeller and with the recent pricing I have less of a problem with justifying it too.
What are the cons with using the Propeller? At the moment I would say the lack of memory for firmware. To some extent I can overlay sections I guess, though how I can instruct the compiler to do this I'm not sure, there may be a bit of fudging. Another thing which I have also mentioned before is the lack of a high-speed SPI port which limits the interface to other chips and to SD cards etc. SPI can be implemented as a simple 8-bit shift register and counter and certainly is way simpler than the video support hardware that is implemented on each cog.
Also on the topic of SPI there is a small 512KB 8-pin soic dataflash that I used recently that would be immensely superior to the slow and limited I2C EEPROMS. I know the boot routines are in mask ROM and they are not about to be changed. I suppose it would be possible to have a small I2C boot EEPROM plus the SPI dataflash for all that extra memory in such a small package. The SPI clock and DI/DO can be shared with the I2C lines without any problems and so there is only the extra CS signal (I've done this on many occasions).
I have used LPC2xxx ARM chips before and the thought strikes me that the LPC2138 has 512KB of Flash amongst many peripherals. This chip could be setup to emulate a large EEPROM(s) for the Propeller
as well as provide those dedicated functions (or vice-versa). Hmmm, that's a thought for one of my designs.
*Peter*
This is basically a super USB serial converter or a stand-alone communications terminal. The idea is that I can carry it in my laptop case and whip it out to tackle the most common serial interfaces and protocols. Being electrically isolated means I won't get any nasties breaking through and frying my laptop, especially when I plug it into mains power. I didn't want DTR transitions to trigger a reset in normal use so I have a push-button to enable this when it is being reprogrammed. Personally, I use break detection on other designs to trigger a reset.
PORTS
- Isolated USB Serial
- RS-232 RXD,TXD,RTS,CTS + 4 unbuffered lines (via 10K)
- RS-485 PORT 1
- RS-485 PORT 2
- RS-422 (using both RS-485s)
- VGA
- PS/2 Connecter + I2C
ADVANTAGES OF USING A PROPELLER
The RTS/CTS lines on the RS-232 can also become a secondary full-duplex RS-232 port. The Propeller is very versatile due to the way that there are very few dedicated pins and any COG can access any port pin. On conventional CPUs I would connect a dedicated RXD and TXD pin to the RS-485 chip plus the TE line. As RS-485 is half-duplex I tie the RX-485 RXD and TXD together to one Propeller pin not only saving one pin but having the flexibility without sacrificing resources.
There is a implicit advantage to using the Propeller in that practically any serial interface can be emulated in software smoothly and reliably. If I needed a synchronous HDLC interface on RS-485 then it is possible without having to redesign.
I really didn't need a VGA and PS/2 port on this unit but it has turned out well as I can use the SCC as a communications terminal or a RS-485 networked terminal/display. I am even using the VGA simply for communications diagnostics, quite useful.
A production version will use faster opto-couplers and perhaps even the FTDI USB serial chip if necessary. There is also a need for a simple regulator and DC power jack for those stand-alone applications where it won't be connected to USB permanently.
WHAT I THINK
My overall experience with the Propeller is very positive. Other CPUs have more program memory or faster dedicated peripherals which may sway me a bit but I tend to design with things that are fun too, of course it has to meet the design goal criteria. So if the Propeller meets this criteria along with XYZ and ABC then I would choose the Propeller and with the recent pricing I have less of a problem with justifying it too.
What are the cons with using the Propeller? At the moment I would say the lack of memory for firmware. To some extent I can overlay sections I guess, though how I can instruct the compiler to do this I'm not sure, there may be a bit of fudging. Another thing which I have also mentioned before is the lack of a high-speed SPI port which limits the interface to other chips and to SD cards etc. SPI can be implemented as a simple 8-bit shift register and counter and certainly is way simpler than the video support hardware that is implemented on each cog.
Also on the topic of SPI there is a small 512KB 8-pin soic dataflash that I used recently that would be immensely superior to the slow and limited I2C EEPROMS. I know the boot routines are in mask ROM and they are not about to be changed. I suppose it would be possible to have a small I2C boot EEPROM plus the SPI dataflash for all that extra memory in such a small package. The SPI clock and DI/DO can be shared with the I2C lines without any problems and so there is only the extra CS signal (I've done this on many occasions).
I have used LPC2xxx ARM chips before and the thought strikes me that the LPC2138 has 512KB of Flash amongst many peripherals. This chip could be setup to emulate a large EEPROM(s) for the Propeller
as well as provide those dedicated functions (or vice-versa). Hmmm, that's a thought for one of my designs.*Peter*
Comments
Graham
Trivial question, why did you contour the board edges? Form or function in mounting?
You mentioned the need for SPI for storage. Have you checked out rokicki's SD Card code? I have a 1GB microSD connected to a microSD breakout board from sparkfun.
http://www.sparkfun.com/commerce/product_info.php?products_id=544
I can even boot a FemtoBasic program off of it. It is very nifty, and small.
BTW, nice looking design. What is the best way to get started on making a custom propeller board like that? I was thinking of doing a dual prop design with a 1Mx8 SRAM attached to one of them(somebody's design on the forum).
Thanks,
Doug
I find the forum members enthusiastic experimenting very stimulating and motivating. The Propeller is a CPU of "special consideration" amongst many hundreds of "special" designs and is probably more so because of this forum and the hands-on attitude and support of Parallax and users.
Hinv
You mentioned SD cards and they are something I have worked with and developed code for on the ARM. There is an extended Propeller based design that I will implement next which will have an SD card slot plus the Vinculum for easy USB access plus ethernet amongst many other peripherals. So it is going to be like a hand-held embedded PC but it can't just rely on the Propeller alone and will probably require an ARM chip to handle the "higher-level" (boring) functions.
Another design I am looking at which really utilizes the Propeller fully is a digital Public Address system where multiple distributed Propellers digitize and control microphone and audio inputs and either feed analog output directly to conventional power amplifiers or as digital signals to "smart" PA speakers. Of course there is the touch-screen VGA for displaying and controlling all these functions along with SD card style storage and playback. I think the microphone sockets will take-up more room than the electronics but that's the way it is.
Originator
It's only the USB port which is used for programming except for the original proto as I had to hack that to program it via the RS-232. You can have both though, it's not really a problem to run the inputs of the chips together, it's just the outputs that need to be "wired-or" together, either through diodes and pullups or logic gates.
The board is contoured as it slides into a metal case and is designed for screwless mounting, the only exception being an optional case grounding screw. The sides are recessed to alleviate insertion friction plus allow room for case screws to protrude. The card sort of guides itself in and locks into place and makes assembly a breeze.
*Peter*
The touch vga you mentioned, could I pry as to which you are referring?