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. Loadp2: a loader for the Parallax Propeller 2. Written by Dave Hein Modified by Eric R. Loadp2 is used to load programs to the memory of a Parallax Propeller 2 ('P2') chip over a serial connection.
Just bought a couple of propeller chips, to investigate how I might connect one to the Bifferboard. I'll add notes here.
The idea
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: Parallax Propeller Softwareall : test.binary ![]() 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: Parallax Propeller Projectsall : propeller_demo.binarypropeller_demo.binary: propeller_demo.spin 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. Parallax Propeller Reading From A Serial Port NumberDecided 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. Parallax Propeller Reading From A Serial PortalConclusionSo 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. Parallax Propeller Print
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.
I've been trying for a couple days now to figure out how to read anything useful off the RS 232 on the Propeller Professional Development Board. I have messed around with FullDuplex and all that from the Fundamentals book to no avail.
My goal is to get a signal from my Spaceball 5000 (It is a 3D motion controller similar to http://www.3dconnexion.com/·) so I can hook the signal probably first to my oscilloscope to hack it. Once I know what binary stuff I get when I manipulate the Spaceball I can try to get it to be read by the Propeller and use it to move servos or god knows what. I also have multimeters that can connect to my computer and make real handy spreadsheet data etc. This would also be great to be able to use on Propeller. The problem is I have no idea how to even get a signal. I realise RX will be sending data to the Prop, and that my devices probably need a clock type signal through CTS. I can get this to communicate fine to my laptop through that debug window. I get the idea of pushing buttons to control the debug or input numbers to have it converted and that sort of stuff. The problem is using the MAX3232E thing to interface at all between the Prop and my devices plugged to the RS 232. Does anyone have any links or advice? I am very new to Propeller so please explain in detail if you can. This Spaceball, as well as the Multimeters, do have Drivers that must be installed for Windows to properly interact with the devices. I am going off the assumption that these devices are simple things that send out pulses indicating their status after getting a 'Send me Data' signal, which probably goes through CTS. I assume any power, as far as VSS VDD, is provided by the jack I've been talking about in the bottom left corner of the PPDB. Thanks for any help. Please remember I am very new to this specific Language and Chip. I can program TI calculators a bit in Basic, that is the extent of my programming knowledge, besides monkey see monkey do in BS2. As far as the electronics part the toughest thing I've done is make a spark gap with a 555 and ignition coil without any directions. Just to give you an idea of my programming and electronics knowledge (or lack thereof). Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |