Just bought a couple of propeller chips, to investigate how I might connect one to the Bifferboard. I'll add notes here.
The propeller chip boots up first checking for a connected PC on the serial port, then it checks an i2c EEPROM for a program to load. Now suppose we can make the Bifferboard serial console behave like the Propeller-programming component of the PC. That would allow us to store Propeller firmware on the Bifferboard, bootstrap from it, transfer any needed data, and then let let it act as a TV terminal, or use it for super-fast IO for robotics, or whatever. We already have the console @3.3v so all that's theoretically needed is the Propeller chip, xtal, and some passive components. The propeller chip can communicate with the Bifferboard either via the serial 'console', or for even faster data transfer via the 4 JTAG pins converted for IO. That's up to 6 parallel bits to shift data, resulting in about 0.5MB/sec. Easily enough for basic LCD displays, possibly even enough to play games.
Diary below:
20/01/2010- Enough dreaming... now down to business
Idecided to just buy the chips, and attempt to make my own serialprogramming cable. It seems though, that the protocol isn't documentedanywhere, or is it? A very useful thread can be found here which might help with the hardware.
After much searching, it seems there is some codeto bootstrap one Propeller from another one, the closest thing I canfind to a spec. Hang on a minute, that's not C! Guess I will have tolearn about the Spin thing... sigh...
21/01/2010 - Tried to talk to the chip, failed, but realised some things. There's a thing called Loader.py,which documents the serial protocol in a way I can understand :). I'vetried to run it on the laptop, but the PL2303 serial cable (AKA Bifferconsole cable) I've got doesn't expose the DTR signal which seemscritical for communication with the Prop. I even cut open the case onthe PL2303, and can't find the control signals there either :(. You seeyou need to get hold of the reset line on the Prop and wiggle it at theright time as well as doing the right stuff on the serial port. Ithink this is required because the thing auto-bauds. So I've switchedto the Bifferboard, and used GPIO12 to control the reset line. I'vemodified Loader.py to wiggle GPIO12 instead of DTR, which is how itnormally works. I tried this using an echo to the sysfs file. Unfortunately the Bifferboard, it seems (under Python at least) is tooslow to keep up with the serial communication rate needed to talk tothe board - various discussions on the Prop. forum seemed to say thatif you had background tasks running, comms with the Prop could fail. No question then that timing on the BB is going to be tight. This wasusing a PL2303 as well, which is very inefficient for single bytes backand forth since it has to create a complete USB frame for this, and Ithink you have to wait 1mS for start-of-frame.. or something likethat. It looks like the next thing will be to re-code Loader.py intoC, and switch to using the console serial port instead of my PL2303cable. I guess I may as well do both at the same time. Well, at leastI got a *couple* of bytes back from the Prop in *some* of the runs, sothat's a start.
22/01/2010 - Here is a circuit showing all connections between Prop and Bifferboard. Of course, I've made the JTAG GPIO mod. I put an electrolytic cap between the power rails (not shown), 10uF. It seems not to upset the Bifferboard when connected/disconnected.
24/01/2010 13:30 - Propeller initialised! There was no way Loader.py was going to work on the Bifferboard, it was just too slow, and I think the way initialisation is done in that program makes assumptions about the serial transmit buffer size and, well, I didn't really understand how it was supposed to work. The serial protocol is described in this page and I really wished I had found that before I started. Anyhow, I've created my own 'Loader.py' in C, and instead of using the serial device I've just iopermed the serial port IO addresses so I can hammer the UART directly - in any case I'll need that to convert this stuff for use in Biffboot, which can't use interrupts. I can pulse the reset line, issue the lfsr sequence (250 bytes) to initialise the board, and read back the continuing lfsr sequence form the Prop, I also get to read back a version number, which for my Prop. appears to be '1', a little disappointing for a chip that's been around a few years, but I'll let that one slide :>.
Communicating is all very well, but I need to be able to run stuff on the Propeller. There is something called Brad's Spin Tool, which allows native compilation of Spin programs under Linux, however it's also supposed to be possible to compile programs using the official software running under Wine. I read some reports of random crashes with BST, so decided I'll try the Wine route. I started off running the Propeller IDE under Wine, however all it seemed useful for was editing and saving a program with syntax highlighting, as when I tried to change the preferences to configure it to just output a compiled file instead of compiling and connecting to the demo board all I got was garbage fonts that I couldn't read. So I just used that to write myself a blinken-lights-type program. Here it is:
test.spin
CON
_xinfreq = 12_000_000
_clkmode = xtal1 + pll8x
PUB LedOnOff
dira[23] := 1
repeat
outa[23] := 1
waitcnt(clkfreq + cnt)
outa[23] := 0
waitcnt(clkfreq + cnt)
I only had a 12MHz xtal, so reduced the clock multiplier to 8x so it's not too fast. Now how to compile it? Fortunately there is something called Propellent.exe, another tool which is just a command-line compiler. I fared a bit better with this, and got myself a Makefile for compiling my first spin program:
Makefile:
all : test.binary
test.binary: test.spin
wine Propellent.exe /COMPILE /IMAGE $@ /GUI OFF /SAVEBINARY $<
clean:
rm -f test.binary
After a short time I realised the Propellent.exe tool steadfastly ignores the extension of the file you pass it for output using the /IMAGE directive, and instead always gives it a .binary extension, so I (grudgingly) changed my makefile so the target was 'test.binary'. Sigh...
wine Propellent.exe /COMPILE /IMAGE test.binary /GUI OFF /SAVEBINARY test.spin
EVT:501-Compiling: TEST
EVT:502-File(s) compiled successfully.
INF:401-Image file saved successfully.
That looks OK, and gives me a 56-byte long file 'test.binary', that I can try to upload to my Propeller.
24/01/2010, 21:10 - Blinking lights! Finally I have a blinking LED, so time to upload a pic of the setup, I think:
The final version of the upload program is attached below (biffprop.c). Forinfo: That's one of the earlier, 1MB Bifferboards, running Slackwareon a Western Digital Passport drive (underneath the breadboard), itselfontop of a USB hub. I tried without the 10k resistor and it stillworks, so don't know if I need that. I've used a 1.5k pull-up resistorfor the LED. I suppose it would be handy to have some supplydecoupling for the Prop, but the Bifferboard doesn't seem too botheredfor this experiment. The LED seems to flash too fast according to mycalculations, but it's a start.
24/01/2010, 21:50 Stripboarded and still working - Iswitched the LED to GPIO pin 8, just to ensure I left all the portsfree that are used with the demo board, since I'm kind-of hoping I can turn this into something that behaves in a similar way.
The demo code from the demo board page above can be compiled with the following Makefile:
all : propeller_demo.binary
wine Propellent.exe /COMPILE /IMAGE $@ /GUI OFF /SAVEBINARY $<
It seems the propeller_demo.spin file references the other modules, and if they're in the same directory they just get picked up - no need to specify library directories or stuff like that. Nice, but I guess you can't specify Makefile dependencies, so not so nice. I ended up with an 8268-byte propeller_demo.binary file, and at this point I have to call it a day, because I'm sure I don't have the right crystal to get any TV display. Maybe tomorrow. Oh yes, and you can edit these spin files in vi, because joe doesn't seem to like the unicode. View them in Firefox if you want the graphics to come out right.
25/01/2010 - Added keyboard and SVGA connectors, resistors for the keyboard, by following the demo board schematic but still no software to drive them... yet. Working my way through the tutorial.
The cable at the bottom-left is a USB cable with the device end hacked off. Connected to a USB hub it's a convenient way of getting 5v for the keyboard.
26/01/2010 - Moved upload program to SVN. Will put any software there.
Decided to checkout the native Linux compiler, made by someone called BradC. First thing I noticed is it's UPX-packed, and I wondered if that's an issue for a puny CPU like the one on the Bifferboard - unpacked it and tried it both ways. Didn't seem to be too slow so left it packed. Just goes to show how cool UPX is, I guess. Decided to try out my 'LED blink' program with that, and it worked perfectly - nice.
All spin files supplied with the Windows Propeller compiler seem to be in Unicode. The Linux 'file' command says it's utf-16, so I wrote a small script (decode.py) to convert the files to utf-8, so I can at least look at them in Joe.
Time to try to get that keyboard connector I wired up working. I got a little way through the tutorial, but then got bored. I found Keyboard.spin, that seems to control a PC keyboard. The object has:
PUB start(dpin, cpin) : okay
So, I guess you don't need to look at the tutorial to understand it takes a data pin, a clock pin and returns whether it initialised OK, so I will add this to my led_blink program and see if it still works. The Propeller demo board puts 'data' on P26, and 'clock' on P27, so it's not rocket science to work out:
OBJ
kb : 'Keyboard'
PUB start()
kb.start(26, 27)
...
will do the trick. I tried this, and my blink program still worked, so I decided to instead try to wait for a keypress between blinks. The compiler seemed to be telling me that functions without parameters can't have brackets, so I tried:
repeat
outa[23] := 1
kb.newkey
outa[23] := 0
kb.newkey
My keyboard plugged in and the light came on, so it seemed to be recognised. Pressing any key switched the LED on and off. This is too easy, I thought. Can't be working. So being the untrusting soul I am I tried something more adventurous:
repeat
tmp := kb.newkey
if tmp $31 ' ascii for #1
outa[8] := 0
if tmp $32 ' ascii for #2
outa[8] := 1
Once I saw the LED go on when I pressed the '1' key, and off when I pressed the '2' key, and doing nothing else with any other keys, even a doubting Thomas like me was convinced. Wow! Perhaps I am starting to see why people are raving about this chip. It's not the hardware itself, but the fact they are giving you solutions like this on a plate, in easy-to-swallow OO-form, and with a MIT license to boot. I think next up I will try to do something with VGA.
27/01/2010 - PC keyboard connected to Bifferboard! A trivial addition to my 'terminal' program. I've nabbed an object off the object exchange (obex.parallax.com), modestly described as a 'medium speed serial port driver', and modified my simple program so it reads a key, then sends it to the serial port. Hey presto, Minicom on the Bifferboard confirms I'm receiving the bytes from the keyboard! Looks like the 'keyboard' half of my terminal is there, although I'm sure I'll need some character translation, to convert the keys to vt100-style escape sequences. It's a great start though.
Wired up the composite video output, then realised that the TV is just too far from where my computer is, so I wired up all the demo-board resistors for the SVGA connection - 16 of them in all. I didn't have the right values, so chose the closest I could get - I expect to see some odd colours, but I'm hoping I'll still get a display. Here's the circuit:
I took the demo programs from the demo board zip, vga.spin, and vgatest2.spin, changed the clock speed and multiplier to match my 12MHz crystal (8x multiplier), compiled/uploaded with bstc and 'ta da...', got myself a slightly off-center, slightly off-colour picture. It wasn't as bad as it looks: I think I have to get myself a new camera.
05/02/2010 - Crystals arrived a few days ago, so time to try them out. I tried the 5MHz one, with 16x oscillator, but that didn't work too well, tried the 10MHz one, with 8x oscillator, and that worked somewhat better, giving me a picture. Found a set of Spin objects in the firmware from another project called PocketTerm, which seem to do almost exactly what I want. Starting to look really good now, however I get some character errors on the display - maybe the software doesn't work too well up at 115200 (9600 was the default setting), and I suspect the vt100 emulation is not 100%, still impressive though, considering it cost me about a tenner.
Conclusion
So this is a potentially cheap way of getting a 'user interface' for your Bifferboard. When you compare with the Tellymate, which gives you a much lower resolution, and doesn't have a keyboard input, it's pretty good value, although the Tellymate is still a cool project. The hardware can easily be adapted to output via a TV (at lower resolution), and a graphical display is possible, although due to the limited Propeller ram there will not be too many colours. The bit that hasn't been done is the code to upload the terminal program to the propeller from the BIOS, because without that you don't get to see the BIOS messages. Biffboot would have to be modified for this. Alternatively, you can store this program in EEPROM connected to the Propeller, and then there is no setup from Linux required, it's just a stand-alone terminal.
A similar project to this one (less flexible, more expensive, but pre-assembled) is http://www.microvga.com/
Component List
By popular request, the BOM. I buy most of my components from BitsBox, since there's no minimum order, but you can also get any of this stuff from Farnell. I've found www.active-robots.com to be the cheapest UK supplier of Propeller chips if you want to pay by Paypal, however, if you are happy to pay with normal credit card, you can try www.active-robots.co.uk, which gave slightly cheaper prices including postage. Very odd, but never mind. You can certainly get away with smaller stripboard, but I like to leave room for later expansion.
Note that assuming you have wire and solder the above is all you need to construct the circuit. I used crimps and housings to connect my stripboard to the Bifferboard, and SVGA, but these are optional. You may be able to get away without the 8x 240 ohm resistors on the SVGA outputs, however the Parallax Demo board had them, so I put them in.
A flip is a mini board similar to the MICRO but powered with a parallax propeller running at 5-80 MHz. The freq is set by PLL and has 8 processors in a single chip. I originally planned on starting with I2C questions and may still return to I2C. The Parallax Propeller is an 8-core RISC microcontroller from the company that had found success in the 1990s with the BASIC Stamp, the PIC-based board that was all the rage before Arduino came.
The ideaThe propeller chip boots up first checking for a connected PC on the serial port, then it checks an i2c EEPROM for a program to load. Now suppose we can make the Bifferboard serial console behave like the Propeller-programming component of the PC. That would allow us to store Propeller firmware on the Bifferboard, bootstrap from it, transfer any needed data, and then let let it act as a TV terminal, or use it for super-fast IO for robotics, or whatever. We already have the console @3.3v so all that's theoretically needed is the Propeller chip, xtal, and some passive components. The propeller chip can communicate with the Bifferboard either via the serial 'console', or for even faster data transfer via the 4 JTAG pins converted for IO. That's up to 6 parallel bits to shift data, resulting in about 0.5MB/sec. Easily enough for basic LCD displays, possibly even enough to play games.
Diary below:20/01/2010- Enough dreaming... now down to business
Idecided to just buy the chips, and attempt to make my own serialprogramming cable. It seems though, that the protocol isn't documentedanywhere, or is it? A very useful thread can be found here which might help with the hardware.
After much searching, it seems there is some codeto bootstrap one Propeller from another one, the closest thing I canfind to a spec. Hang on a minute, that's not C! Guess I will have tolearn about the Spin thing... sigh...
21/01/2010 - Tried to talk to the chip, failed, but realised some things. There's a thing called Loader.py,which documents the serial protocol in a way I can understand :). I'vetried to run it on the laptop, but the PL2303 serial cable (AKA Bifferconsole cable) I've got doesn't expose the DTR signal which seemscritical for communication with the Prop. I even cut open the case onthe PL2303, and can't find the control signals there either :(. You seeyou need to get hold of the reset line on the Prop and wiggle it at theright time as well as doing the right stuff on the serial port. Ithink this is required because the thing auto-bauds. So I've switchedto the Bifferboard, and used GPIO12 to control the reset line. I'vemodified Loader.py to wiggle GPIO12 instead of DTR, which is how itnormally works. I tried this using an echo to the sysfs file. Unfortunately the Bifferboard, it seems (under Python at least) is tooslow to keep up with the serial communication rate needed to talk tothe board - various discussions on the Prop. forum seemed to say thatif you had background tasks running, comms with the Prop could fail. No question then that timing on the BB is going to be tight. This wasusing a PL2303 as well, which is very inefficient for single bytes backand forth since it has to create a complete USB frame for this, and Ithink you have to wait 1mS for start-of-frame.. or something likethat. It looks like the next thing will be to re-code Loader.py intoC, and switch to using the console serial port instead of my PL2303cable. I guess I may as well do both at the same time. Well, at leastI got a *couple* of bytes back from the Prop in *some* of the runs, sothat's a start.
22/01/2010 - Here is a circuit showing all connections between Prop and Bifferboard. Of course, I've made the JTAG GPIO mod. I put an electrolytic cap between the power rails (not shown), 10uF. It seems not to upset the Bifferboard when connected/disconnected.
24/01/2010 13:30 - Propeller initialised! There was no way Loader.py was going to work on the Bifferboard, it was just too slow, and I think the way initialisation is done in that program makes assumptions about the serial transmit buffer size and, well, I didn't really understand how it was supposed to work. The serial protocol is described in this page and I really wished I had found that before I started. Anyhow, I've created my own 'Loader.py' in C, and instead of using the serial device I've just iopermed the serial port IO addresses so I can hammer the UART directly - in any case I'll need that to convert this stuff for use in Biffboot, which can't use interrupts. I can pulse the reset line, issue the lfsr sequence (250 bytes) to initialise the board, and read back the continuing lfsr sequence form the Prop, I also get to read back a version number, which for my Prop. appears to be '1', a little disappointing for a chip that's been around a few years, but I'll let that one slide :>.
Communicating is all very well, but I need to be able to run stuff on the Propeller. There is something called Brad's Spin Tool, which allows native compilation of Spin programs under Linux, however it's also supposed to be possible to compile programs using the official software running under Wine. I read some reports of random crashes with BST, so decided I'll try the Wine route. I started off running the Propeller IDE under Wine, however all it seemed useful for was editing and saving a program with syntax highlighting, as when I tried to change the preferences to configure it to just output a compiled file instead of compiling and connecting to the demo board all I got was garbage fonts that I couldn't read. So I just used that to write myself a blinken-lights-type program. Here it is:
test.spin
CON
_xinfreq = 12_000_000
_clkmode = xtal1 + pll8x
PUB LedOnOff
dira[23] := 1
repeat
outa[23] := 1
waitcnt(clkfreq + cnt)
outa[23] := 0
waitcnt(clkfreq + cnt)
I only had a 12MHz xtal, so reduced the clock multiplier to 8x so it's not too fast. Now how to compile it? Fortunately there is something called Propellent.exe, another tool which is just a command-line compiler. I fared a bit better with this, and got myself a Makefile for compiling my first spin program:
Makefile:
all : test.binary
test.binary: test.spin
wine Propellent.exe /COMPILE /IMAGE $@ /GUI OFF /SAVEBINARY $<
clean:
rm -f test.binary
After a short time I realised the Propellent.exe tool steadfastly ignores the extension of the file you pass it for output using the /IMAGE directive, and instead always gives it a .binary extension, so I (grudgingly) changed my makefile so the target was 'test.binary'. Sigh...
wine Propellent.exe /COMPILE /IMAGE test.binary /GUI OFF /SAVEBINARY test.spin
EVT:501-Compiling: TEST
EVT:502-File(s) compiled successfully.
INF:401-Image file saved successfully.
That looks OK, and gives me a 56-byte long file 'test.binary', that I can try to upload to my Propeller.
24/01/2010, 21:10 - Blinking lights! Finally I have a blinking LED, so time to upload a pic of the setup, I think:
The final version of the upload program is attached below (biffprop.c). Forinfo: That's one of the earlier, 1MB Bifferboards, running Slackwareon a Western Digital Passport drive (underneath the breadboard), itselfontop of a USB hub. I tried without the 10k resistor and it stillworks, so don't know if I need that. I've used a 1.5k pull-up resistorfor the LED. I suppose it would be handy to have some supplydecoupling for the Prop, but the Bifferboard doesn't seem too botheredfor this experiment. The LED seems to flash too fast according to mycalculations, but it's a start.
24/01/2010, 21:50 Stripboarded and still working - Iswitched the LED to GPIO pin 8, just to ensure I left all the portsfree that are used with the demo board, since I'm kind-of hoping I can turn this into something that behaves in a similar way.
The demo code from the demo board page above can be compiled with the following Makefile:
all : propeller_demo.binary
Parallax Propeller Pdf
propeller_demo.binary: propeller_demo.spinwine Propellent.exe /COMPILE /IMAGE $@ /GUI OFF /SAVEBINARY $<
It seems the propeller_demo.spin file references the other modules, and if they're in the same directory they just get picked up - no need to specify library directories or stuff like that. Nice, but I guess you can't specify Makefile dependencies, so not so nice. I ended up with an 8268-byte propeller_demo.binary file, and at this point I have to call it a day, because I'm sure I don't have the right crystal to get any TV display. Maybe tomorrow. Oh yes, and you can edit these spin files in vi, because joe doesn't seem to like the unicode. View them in Firefox if you want the graphics to come out right.
25/01/2010 - Added keyboard and SVGA connectors, resistors for the keyboard, by following the demo board schematic but still no software to drive them... yet. Working my way through the tutorial.
The cable at the bottom-left is a USB cable with the device end hacked off. Connected to a USB hub it's a convenient way of getting 5v for the keyboard.
26/01/2010 - Moved upload program to SVN. Will put any software there.
Decided to checkout the native Linux compiler, made by someone called BradC. First thing I noticed is it's UPX-packed, and I wondered if that's an issue for a puny CPU like the one on the Bifferboard - unpacked it and tried it both ways. Didn't seem to be too slow so left it packed. Just goes to show how cool UPX is, I guess. Decided to try out my 'LED blink' program with that, and it worked perfectly - nice.
All spin files supplied with the Windows Propeller compiler seem to be in Unicode. The Linux 'file' command says it's utf-16, so I wrote a small script (decode.py) to convert the files to utf-8, so I can at least look at them in Joe.
Time to try to get that keyboard connector I wired up working. I got a little way through the tutorial, but then got bored. I found Keyboard.spin, that seems to control a PC keyboard. The object has:
PUB start(dpin, cpin) : okay
So, I guess you don't need to look at the tutorial to understand it takes a data pin, a clock pin and returns whether it initialised OK, so I will add this to my led_blink program and see if it still works. The Propeller demo board puts 'data' on P26, and 'clock' on P27, so it's not rocket science to work out:
OBJ
kb : 'Keyboard'
PUB start()
kb.start(26, 27)
...
will do the trick. I tried this, and my blink program still worked, so I decided to instead try to wait for a keypress between blinks. The compiler seemed to be telling me that functions without parameters can't have brackets, so I tried:
repeat
outa[23] := 1
kb.newkey
outa[23] := 0
kb.newkey
Parallax Propeller Activity Board
My keyboard plugged in and the light came on, so it seemed to be recognised. Pressing any key switched the LED on and off. This is too easy, I thought. Can't be working. So being the untrusting soul I am I tried something more adventurous:
repeat
tmp := kb.newkey
if tmp $31 ' ascii for #1
outa[8] := 0
if tmp $32 ' ascii for #2
outa[8] := 1
Once I saw the LED go on when I pressed the '1' key, and off when I pressed the '2' key, and doing nothing else with any other keys, even a doubting Thomas like me was convinced. Wow! Perhaps I am starting to see why people are raving about this chip. It's not the hardware itself, but the fact they are giving you solutions like this on a plate, in easy-to-swallow OO-form, and with a MIT license to boot. I think next up I will try to do something with VGA.
27/01/2010 - PC keyboard connected to Bifferboard! A trivial addition to my 'terminal' program. I've nabbed an object off the object exchange (obex.parallax.com), modestly described as a 'medium speed serial port driver', and modified my simple program so it reads a key, then sends it to the serial port. Hey presto, Minicom on the Bifferboard confirms I'm receiving the bytes from the keyboard! Looks like the 'keyboard' half of my terminal is there, although I'm sure I'll need some character translation, to convert the keys to vt100-style escape sequences. It's a great start though.
Wired up the composite video output, then realised that the TV is just too far from where my computer is, so I wired up all the demo-board resistors for the SVGA connection - 16 of them in all. I didn't have the right values, so chose the closest I could get - I expect to see some odd colours, but I'm hoping I'll still get a display. Here's the circuit:
I took the demo programs from the demo board zip, vga.spin, and vgatest2.spin, changed the clock speed and multiplier to match my 12MHz crystal (8x multiplier), compiled/uploaded with bstc and 'ta da...', got myself a slightly off-center, slightly off-colour picture. It wasn't as bad as it looks: I think I have to get myself a new camera.
05/02/2010 - Crystals arrived a few days ago, so time to try them out. I tried the 5MHz one, with 16x oscillator, but that didn't work too well, tried the 10MHz one, with 8x oscillator, and that worked somewhat better, giving me a picture. Found a set of Spin objects in the firmware from another project called PocketTerm, which seem to do almost exactly what I want. Starting to look really good now, however I get some character errors on the display - maybe the software doesn't work too well up at 115200 (9600 was the default setting), and I suspect the vt100 emulation is not 100%, still impressive though, considering it cost me about a tenner.
Conclusion
So this is a potentially cheap way of getting a 'user interface' for your Bifferboard. When you compare with the Tellymate, which gives you a much lower resolution, and doesn't have a keyboard input, it's pretty good value, although the Tellymate is still a cool project. The hardware can easily be adapted to output via a TV (at lower resolution), and a graphical display is possible, although due to the limited Propeller ram there will not be too many colours. The bit that hasn't been done is the code to upload the terminal program to the propeller from the BIOS, because without that you don't get to see the BIOS messages. Biffboot would have to be modified for this. Alternatively, you can store this program in EEPROM connected to the Propeller, and then there is no setup from Linux required, it's just a stand-alone terminal.
A similar project to this one (less flexible, more expensive, but pre-assembled) is http://www.microvga.com/
Component List
By popular request, the BOM. I buy most of my components from BitsBox, since there's no minimum order, but you can also get any of this stuff from Farnell. I've found www.active-robots.com to be the cheapest UK supplier of Propeller chips if you want to pay by Paypal, however, if you are happy to pay with normal credit card, you can try www.active-robots.co.uk, which gave slightly cheaper prices including postage. Very odd, but never mind. You can certainly get away with smaller stripboard, but I like to leave room for later expansion.
| Quantity | Description | Where to buy |
| 1 | Stripboard 127x95 | http://www.bitsbox.co.uk/hardware.html#stripboard |
| 1 | 40-pin DIP Parallax Propeller | http://www.active-robots.com/products/parallax/parallax-propeller-chips.shtml |
| 3 | 10K resistor | http://www.bitsbox.co.uk/resistors/mfr.html |
| 2 | 100 ohm resistor | http://www.bitsbox.co.uk/resistors/mfr.html |
| 13 | 240 ohm resistor | http://www.bitsbox.co.uk/resistors/mfr.html |
| 3 | 470 ohm resistor | http://www.bitsbox.co.uk/resistors/mfr.html |
| 1 | 10MHz crystal | http://www.bitsbox.co.uk/crystals.html |
| 1 | 40-pin DIL socket | http://www.bitsbox.co.uk/semiconhw.html |
| 1 | 15-way SVGA female | http://www.bitsbox.co.uk/connects.html#dcon |
| 1 | PS/2 Keyboard connector (6-way mini DIN) | Old motherboard http://www.active-robots.com/products/parallax/breadboard-adapters.shtml http://www.toby.co.uk/content/catalogue/products.aspx?series=KMDGX-xS-BS-xx |
Note that assuming you have wire and solder the above is all you need to construct the circuit. I used crimps and housings to connect my stripboard to the Bifferboard, and SVGA, but these are optional. You may be able to get away without the 8x 240 ohm resistors on the SVGA outputs, however the Parallax Demo board had them, so I put them in.
STOP: Complete each check mark in order below! Do not connect the module until you reach the appropriate step, or you may damage your Wi-Fi Module.
With the Propeller Activity Board, you can connect the WX Wi-Fi module to the WX Socket. If you have an Activity Board WX, you can also connect an SEL socket to control what kind of data flows through the Wi-Fi and USB ports.
Parallax Propeller Ii
Propeller Activity Board Instructions
Before connecting the Wi-Fi module to the Propeller Activity Board, let's make sure the Propeller isn't running an application that might interfere with the Wi-Fi module's communication.
- Do not insert the Wi-Fi module into its socket yet.
- Set the PWR switch to 1.
- Run this program.
- Set the board PWR switch to 0.
- Make sure the corners of the module with white triangles are to the left.
- Line up the module pins with the sockets.
- Press down firmly so that the Wi-Fi module sinks into the socket.
Wiring - Set Communication Options (Activity Board WX)
The wifi library you'll be working with allows you to use jumper wires to choose which port (USB or Wi-Fi) certain data (program, terminal, Wi-Fi application) pass through.
- Choose a wiring configuration from the options below.
- Make a note of the wifi_start function. You'll need to make sure to replace whatever is in an example program you run with the start function that matches the wiring configuration you have.
All Communication through WX Wi-Fi Module
This setting runs all program, terminal, and Wi-Fi application data through the Wi-Fi module. This setting should not be used until you can see the Wi-Fi module in Simple IDE's COM port dropdown. Make sure to use the wifi_start function call shown here at the beginning of any program you run while the SEL socket is connected to 3.3 V.
Program Source Selected with Resistor
The 10 k resistor can be tied to GND for programming through USB or 3.3 V for programming through Wi-Fi. Terminal data passes through USB and Wi-Fi application data passes through the Wi-Fi module. An optional pause can be added to give time for loading the program after power-on or reset.
Program and Optionally Terminal over USB, Wi-Fi App Data Through I/O Pins
This setting is for programming through USB and Wi-Fi app data through I/O pins (P9 and P8). SimpleIDE terminal data will go through USB if you use USB_PGM_TERM, or through the Wi-Fi module if you use USB_PGM.
Wiring - Propeller Activity Board Rev A or B (non-WX)
The non-WX version of the Activity Board does not have an SEL socket. The program will have to be loaded through USB, and you can select whether terminal data goes through USB or the Wi-Fi module. Use USB_PGM_TERM to send terminal data through the USB port, or USB_PGM to send terminal data through the Wi-Fi module.