Multiprop IDE
Dr_Acula
Posts: 5,484
I've been experimenting with the abstract idea of a propeller with as many cogs and pins as required. In order to develop for such a platform, one needs a custom IDE where one can have multiple spin files open at the same time, and have a download system as simple as possible. See screenshot.
Multiple propellers can be programmed via one serial port and with one single keypress.
Behind the scenes:
1) Compile and download a comms program to the master propeller. This is written in Spin and uses the XMODEM protocol. (XMLOAD.Spin)
2) Establish an xmodem link, send the file size and the pins the slave propeller is connected to, and then receive in 128 byte blocks and send these out to the slave propeller.
3) Repeat for as many slaves as are connected (each slave uses 3 or 4 propeller pins)
4) Download the main program to the master propeller.
I have recently upgraded from an XP to a Windows 8 machine and this is a good opportunity to start from scratch. I think you can run Windows 8 in Virtualbox on other operating systems.
1) Download vb.net 2010. Don't get the 2012 version - it will won't run on older versions of windows.
2) Open the .sln file in the Multipropvb.zip file.
3) Open the MultipropFiles zip and put those in a directory. This zip includes Brads Spin Tool command line compiler/downloader
4) Browse the file tree view. Click a .spin file and it will load into whichever tab is visible.
5) Click the blue triangle to download and run the whole package.
This is still very experimental. I'm learning about Windows8 as I go. There are some clever things - zipping up a directory is now part of the operating system. So is screen capture. It seemed to know about my USB to serial adapter as well.
I have some boards being made that have 10 way headers and there is a socket for programming a slave propeller, so slave boards just need a prop chip, two bypass caps, 10uF filter capacitor, xtal (optional) and a 10 way header socket.
Fun times ahead!
Multiple propellers can be programmed via one serial port and with one single keypress.
Behind the scenes:
1) Compile and download a comms program to the master propeller. This is written in Spin and uses the XMODEM protocol. (XMLOAD.Spin)
2) Establish an xmodem link, send the file size and the pins the slave propeller is connected to, and then receive in 128 byte blocks and send these out to the slave propeller.
3) Repeat for as many slaves as are connected (each slave uses 3 or 4 propeller pins)
4) Download the main program to the master propeller.
I have recently upgraded from an XP to a Windows 8 machine and this is a good opportunity to start from scratch. I think you can run Windows 8 in Virtualbox on other operating systems.
1) Download vb.net 2010. Don't get the 2012 version - it will won't run on older versions of windows.
2) Open the .sln file in the Multipropvb.zip file.
3) Open the MultipropFiles zip and put those in a directory. This zip includes Brads Spin Tool command line compiler/downloader
4) Browse the file tree view. Click a .spin file and it will load into whichever tab is visible.
5) Click the blue triangle to download and run the whole package.
This is still very experimental. I'm learning about Windows8 as I go. There are some clever things - zipping up a directory is now part of the operating system. So is screen capture. It seemed to know about my USB to serial adapter as well.
I have some boards being made that have 10 way headers and there is a socket for programming a slave propeller, so slave boards just need a prop chip, two bypass caps, 10uF filter capacitor, xtal (optional) and a 10 way header socket.
Fun times ahead!
Comments
Really, I have considered the way other compilers handle multi-processing and multi-compiling, etc.
The easiest way for the Prop to handle the front-end is to assume the number of concurrent processors or COGs is 8.
The first COG is special, and a flag will be set when this is encountered.
This first COG will handle run-time scheduling for up to 255 COGs.
Good News Everyone!
PayPal did their stuff and I am the owner of a bright and shiny Edition of Dragon 12 Professional.
I am gonna finish my thoughts on the architecture and design details with Dragon doing the heavy lifting of speech recognition.
(i lost the use of my Right hand, my writing hand, 3 years ago. That really sucks!)
Regards,
sm
Got stuck.
Gave up.
Went home.
sm
No, Slaves = propeller chips.
The propeller chip has been able to program other propeller chips right from the beginning, thanks to some nifty code Chip wrote. But no propeller IDE has really been able to use this feature to its full potential. I think it is because originally, there were no SD drivers, so where could you get a second propeller program from? In Chip's original code, it was wrapped up as part of the program, but the problem is that with 32k of ram, now you had to split that between each propeller. Two propellers, 16k each, three = less etc.
Then along came the SD drivers, but you had to get the code onto an SD card, and then off the SD card to the second propeller. That means you need an SD card.
This code handles the download and the transfer to the slave propellers as one continuous process, which means you don't need an intermediate step to store the slave programs.
Would need the prop tool source code. I think the authors of BST and Homespun had access to some code that is not in the public domain. BST is a command line compiler and downloader, so all you really need is the IDE part. The prop tool is unique though with the little drop down arrows that link the start and end of indentation. It would be cool if this could be incorporated in the prop tool
On this, or on the prop tool rewrite?
OK the bulb is starting to flicker... you are proposing that the SD opens up ways to get the .bin file onto distributed Props? That sounds great.
As I understand it, a multi-prop setup requires dedicated programming lines from the master (or some form of hardware multi-plexing) unless each Prop is going to get its own ID burned in. It seems like a pretty simple thing for the Propeller Tool to accept a PropLoader configuration parameter that defines which pins to use for programming the target and to package the PropLoader with the target file at the expense of only about 150 longs of memory.
This would open up multi-prop programming to everybody for almost zero effort on Parallax's part.
Regards,
sm
PS
Got stuck.
Gave up.
Went home.
Does not apply to the multi-prop download strategy... I have been using LabView and Propellent to do this for some time. However, trying to crack organizational inertia to try new things is a different story.
Actually there are two things I have got working.
1) Loading a second propeller from a binary file on an SD card
2) Loading a second propeller from a file on an PC and the file goes 'through' the first propeller.
Re which pins to use, I've been using a plug system that groups pins in either groups of 2 or 4. So for progamming a second propeller that takes a minimum of 3 pins (Tx, Rx, Reset). So you could do this with 3 pins. I haven't written the code yet, but with 4 pins what I think you could do is then reuse the pins for a SPI clocked interface. This will be faster than an unclocked RS232 style interface. But of course, this is the propeller, and because this is all defined in software rather than hardware, you can use all sorts of comms protocols.
Re multiplexing, I started this project with the idea of doing away with all the support chips. I like the 74xx and 40xx series of chips, and in a nerdy sort of way, can tell you what most of the numbers mean, but with this project, the challenge is to do away with those chips. So rather than multiplex, use 3 prop pins on the master to talk to a slave. Another 3 to talk to the next slave. So for a typical propeller, one could have 8 or 9 slaves. But each of those slaves can have 8 or 9 slaves as well. So that is 64-81 chips. And so on. In practice, each slave propeller would need some pins free to do things, and some to talk to other propellers. But even if each propeller devoted 6 pins to talk to 2 slave propellers, that gives lots of free pins, and still means you can grow the network into any number of propeller chips. Devote one cog to handling the communications, and because the propeller has many cogs, the whole communications layer could be transparent to whatever spin program you want to run on each propeller. You could define a virtual memory, megabytes in size, and send a simple message to the network cog to say ' write this long to address nnnnn' and it sends it off to the appropriate propeller.
None of this is a particularly new concept, particularly the idea of multiple propellers. But what is new here is an easier way to program the propellers, as you can have all those propeller chip programs sitting in one IDE, and you can download them all with one keystroke, and that makes debugging a whole lot easier.
Sounds really good. I would love to try out what you come up with.
Happy Easter.
sm
Total time to download the xmodem program, send the slave program to the master with xmodem and then to the slave, and then download the master program is 6 seconds.
CON ' send BigMemSlave to the slave propeller _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ sio: "FullDuplexSerial" text: "tv_text" delay: "Timing" ' for millisecond delays PUB Main text.start(16) ' Start TV driver on pin 16,17,18,19 text.clearscreen ' clear the screen text.str(string("Start Serial comms to slave prop")) sio.start(2,1,0,115200)',Rx pin, Tx pin,mode, baudrate repeat delay.pause1ms(100) ' delay 0.1s sio.tx(65) ' send out A if sio.rxcheck ' if a result in the buffer, display it result :=sio.rx text.out(result) PUB CRLF text.out(13) ' carriage return text.out(10) ' line feedSlave program
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ sio: "FullDuplexSerial" PUB Main ' start serial port with pins opposite to the master sio.start(31,30,0,115200) ' Rx, Tx, Mode,baud rate repeat if sio.rxcheck result := sio.rx sio.tx(result) ' echo it back outI need to think about a simple comms protocol eg start of message, instruction, data, end of message.
Something also I'd like in an IDE is autocomplete - if you include an object and then type the object's name and then the . it should come up with a drop down menu of all the methods, like in the .net editor.
Superb effort!
I have been using this in earnest for a few hours, and one thing I am finding is that it is easier to edit in the proptool than in the vb.net richtextbox. Just a personal choice I guess, but those little arrows in the proptool really are an important part of the Spin language.
I think I might try to wrap up the multiprop compiler into a command line program rather than an IDE. Then it could be combined with BSTC and run as a batch file. The proptool can have the master and all the slave programs open at the same time - just need to remember to save them all rather than just one, when doing a recompile. Then run a single batch file.
Any idea how we can gain access to source?
sm
PropTool source is not available. It is being re-written by ??? who has the source (his name escapes me atm)