I've had the same issue as Dave. I discovered that the BST version is also command-line executable, but Bean's post #30 above is the very first I've seen of any command-line parameters being mentioned. It would be nice if there were some central location for all of this necessary info.
Now that's an intriguing concept. The latency between chips would be the hurdle I'd think.
Interesting : This would need some form of Chain loader, so a single EE could load many Props... The slave loader link, would also be the slave communication link, once run was achieved.
I'm pretty sure there is an obex object for a chain loader, so you only need one eeprom. Cluso99 explored this with his triblade but I don't think we ever explored the software side fully.
So ok, keep things simple. Three prop chips so that gives Bean all his pins he needs. One eeprom. Chain load. Only one propeller chip has the actual code (spin, basic, whatever). The other two props are running little programs in one cog in pasm. These programs are monitoring a two wire common bus. Master says "here is a 2k binary blob for propeller x, load it into your local ram from the serial bus, then load it into cog x and run it".
Or even simpler, Master might say to Slave 1, "Turn pin x high".
So with 3 propellers you would have 7 cogs per propeller or 21 cogs.
The ram is also accessible, the pasm program running in each prop can handle simple commands on the serial bus like "write long x to address y". So you can offload arrays and strings to the other propellers and then the Master has more room for code.
You could also offload whole functions, like driving a VGA screen, and free up lots of memory.
Maybe it is not so hard after all. All it needs is the bootloader code (which I think is done) and some comms code running in pasm (which I think is also done) and some pasm code to handle really simple things like reading and writing longs and doing a cognew and setting pins.
From the program running in the Master, that might come down to some very simple routines - set pin x on prop y to n. Or load a 2k .cog program from SD card and run it in cog x on prop y. (cog code is going to need to be precompiled and moved to an SD card as there is not room for 21 x2k worth of cog code in the master program).
I'm looking at my schematic right now thinking which is going to be easier - 373 latches, 8255 chips or multiple propeller chips...
Maybe it is not so hard after all. All it needs is the bootloader code (which I think is done) and some comms code running in pasm (which I think is also done) and some pasm code to handle really simple things like reading and writing longs and doing a cognew and setting pins. ....
I'm looking at my schematic right now thinking which is going to be easier - 373 latches, 8255 chips or multiple propeller chips...
Most flexible might be to allow a SOT23 teensy-cheap EEPROM per Prop, with just enough code to make it boot like a 8255
(or similar IO variant).
That means you have the option of everything starting 'normally' and you can then download smarter code, selectively to more of your COGs.
Secret is to keep the local loader as small and as cheap and standard, as you can.
I think the 2 byte address format, kicks in at 24C32? - which does come in SOT23 and matches 1 COG.
24C32 & 24C64 work for booting but PropTool cannot program them meaning that you have to download a combo program that executes and programs the eeprom. If you inadvertantly do a download with program eeprom, the 24Cxx gets corrupted.
I just tried to get PropBASIC to work with Geany, but PropBASIC is complaining about a ".", can not figure that one out. Geany is an open source IDE that allows for plug ins, if somebody can get that plug in setup correctly, it could save a step by not having to create a batch file to run the .pbasic file. Of course it would not be the same as having it within SimpleIDE, but it could be better than command line batch files.
Ray,
Do you have a "." in any of the folder names ?
Also the filename MUST include the COMPLETE path to the file. And be enclosed in quotes.
Can you try running it from a command prompt ? See if that works...
I got Geany to produce a valid xxxx.spin file, so, this reduces some of the steps. The big step is that you now have to start up the Prop Tool and run your new xxxx.spin file. I guess it is a little better than dealing with Notepad and a batch file to get too a new xxxx.spin file. Maybe some expert will step up and produce a way of including the Open Spin compiler to eliminate the Prop Tool step, and make this a one step programming experience, if that is possible.
I got Geany to produce a valid xxxx.spin file, so, this reduces some of the steps. The big step is that you now have to start up the Prop Tool and run your new xxxx.spin file. ...
You're almost there ....
The attachment below shows what I've done with propeller-gcc. The same can be done with PropBasic and BSTC. Just replace the propeller-gcc entries with PropBasic commands, and replace propeller-load with BSTC commands.
The project properties dialog can be started from Build -> Set Build Commands
Well, I gave it a good try, could not figure out how to load to a port where the board is connected. Maybe bean will come up with a solution, otherwise, I guess Spin and propGCC are good enough.
I'm pretty sure there is an obex object for a chain loader, so you only need one eeprom. Cluso99 explored this with his triblade but I don't think we ever explored the software side fully.
So ok, keep things simple. Three prop chips so that gives Bean all his pins he needs. One eeprom. Chain load. Only one propeller chip has the actual code (spin, basic, whatever). The other two props are running little programs in one cog in pasm. These programs are monitoring a two wire common bus. Master says "here is a 2k binary blob for propeller x, load it into your local ram from the serial bus, then load it into cog x and run it".
Or even simpler, Master might say to Slave 1, "Turn pin x high".
So with 3 propellers you would have 7 cogs per propeller or 21 cogs.
The ram is also accessible, the pasm program running in each prop can handle simple commands on the serial bus like "write long x to address y". So you can offload arrays and strings to the other propellers and then the Master has more room for code.
You could also offload whole functions, like driving a VGA screen, and free up lots of memory.
Maybe it is not so hard after all. All it needs is the bootloader code (which I think is done) and some comms code running in pasm (which I think is also done) and some pasm code to handle really simple things like reading and writing longs and doing a cognew and setting pins.
From the program running in the Master, that might come down to some very simple routines - set pin x on prop y to n. Or load a 2k .cog program from SD card and run it in cog x on prop y. (cog code is going to need to be precompiled and moved to an SD card as there is not room for 21 x2k worth of cog code in the master program).
I'm looking at my schematic right now thinking which is going to be easier - 373 latches, 8255 chips or multiple propeller chips...
Before you do a lot of work with the '373 take a look at the '573. Same functionality but the pinout greatly simplifies pcb layout. Same is true for the '540 and '574.
Well, I gave it a good try, could not figure out how to load to a port where the board is connected. Maybe bean will come up with a solution, otherwise, I guess Spin and propGCC are good enough.
Ray
I'm just leaving for the day. I'll attempt it tomorrow.
Well, I gave it a good try, could not figure out how to load to a port where the board is connected. Maybe bean will come up with a solution, otherwise, I guess Spin and propGCC are good enough.
Ray
Sorry for continuing this sub-thread, but just a little more info may be all you need ....
All the parameters for PropBasic are listed, so I guess that's not a problem. Entering bstc without any arguments in a command window, it will tell you everything you need to know to make it work.
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Program Usage :- bstc (Options) Filename[.spin]
-a - Create Propeller object archive zipfile
-b - Write .binary file
-c - Write .dat file for C-Compiler (Drops a <filename.dat> file)
-d <device> - Device to load to (Default : )
-D <define> - Define a pre-processor symbol (may be used multiple times)
-e - Write .eeprom file
-f - Double download baud rate
-h - Display this help information
-l - Generate listfile
-L <Lib Path> - Add a library path or file holding library path(s) to the searchpath (may be used multiple times)
-o <filename> - Output [.list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin)
-O <options> - Optimise Binary (HIGHLY EXPERIMENTAL!!!!!)
a - Enable all optmisations (Be careful! No, really)
b - Bigger constants (should be slightly faster at the expense of code size)
c - Fold Constants
g - Generic "safe" size optimisations for smaller/faster code, however not what the Parallax compiler will generate
r - Remove unused Spin Methods
u - Fold Unary "-" Operations on Constants if it will make the code smaller
x - Non-Parallax compatible extensions
-p[012] - Program Chip on device (-d)
0 - Load Ram and run
1 - Load EEProm and shutdown
2 - Load EEProm and run
-s - Intersperse source in listfile (use with -l)
-w[012] - Error/Warning level - 0 - Errors only / 1 - Error/Warning / 2 - Error/Warning/Information (Default 0)
-v - Get program version information
Sorry for continuing this sub-thread, but just a little more info may be all you need ....
All the parameters for PropBasic are listed, so I guess that's not a problem. Entering bstc without any arguments in a command window, it will tell you everything you need to know to make it work.
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Program Usage :- bstc (Options) Filename[.spin]
-a - Create Propeller object archive zipfile
-b - Write .binary file
-c - Write .dat file for C-Compiler (Drops a <filename.dat> file)
-d <device> - Device to load to (Default : )
-D <define> - Define a pre-processor symbol (may be used multiple times)
-e - Write .eeprom file
-f - Double download baud rate
-h - Display this help information
-l - Generate listfile
-L <Lib Path> - Add a library path or file holding library path(s) to the searchpath (may be used multiple times)
-o <filename> - Output [.list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin)
-O <options> - Optimise Binary (HIGHLY EXPERIMENTAL!!!!!)
a - Enable all optmisations (Be careful! No, really)
b - Bigger constants (should be slightly faster at the expense of code size)
c - Fold Constants
g - Generic "safe" size optimisations for smaller/faster code, however not what the Parallax compiler will generate
r - Remove unused Spin Methods
u - Fold Unary "-" Operations on Constants if it will make the code smaller
x - Non-Parallax compatible extensions
-p[012] - Program Chip on device (-d)
0 - Load Ram and run
1 - Load EEProm and shutdown
2 - Load EEProm and run
-s - Intersperse source in listfile (use with -l)
-w[012] - Error/Warning level - 0 - Errors only / 1 - Error/Warning / 2 - Error/Warning/Information (Default 0)
-v - Get program version information
If you're going to make PropBasic work with another IDE maybe it would be better to use Roy's Spin compiler rather than bstc?
I am just trying to help out bean, or maybe get him motivated to give Geany a try, that way he will have full control on how PropBASIC is used. I only chose Geany because I worked with it when I was programming with freeBASIC, which had a plugin, so everything was ready to go. As for Roy's Spin compiler, bean can make that decision, I will be just happy if I can get BSTC to work.
I am just trying to help out bean, or maybe get him motivated to give Geany a try, that way he will have full control on how PropBASIC is used. I only chose Geany because I worked with it when I was programming with freeBASIC, which had a plugin, so everything was ready to go. As for Roy's Spin compiler, bean can make that decision, I will be just happy if I can get BSTC to work.
Ray
No, that's not what I meant. I meant that you could use Roy's Spin compiler from Geany instead of bstc. That way you wouldn't be dependent on a compiler (bstc) that has no support. Using Geany is a fine idea. I think Steve even suggested it to me at one point. Besides, if you use Roy's compiler then Heater can run it on his RaspberryPi! :-)
No, that's not what I meant. I meant that you could use Roy's Spin compiler from Geany instead of bstc. That way you wouldn't be dependent on a compiler (bstc) that has no support. Using Geany is a fine idea. I think Steve even suggested it to me at one point. Besides, if you use Roy's compiler then Heater can run it on his RaspberryPi! :-)
The problem with Roy's compiler is that it does not have serial port support. I'm not sure if he want's to add that or not. We just use propeller-load to load a spin binary when necessary.
It is possible to write a batch file for Geany that does everything with one command, I just don't know the steps.
24C32 & 24C64 work for booting but PropTool cannot program them meaning that you have to download a combo program that executes and programs the eeprom. If you inadvertantly do a download with program eeprom, the 24Cxx gets corrupted.
Is this just a wrap issue ? - if the download always sends 32KB, then only the last 4/8K would remain.
A patch for this would be to place the tiny code last in an otherwise 0FFH filled 32KB image ?
I pretty much have PropBasic working in geany, but I can't figure out how to make geany save the file before running the execute program.
Does anyone know how to do this ? Or if it is even possible ?
Thanks,
Bean
P.S. Nevermind, geany DOES save the file before call the execute program.
Is this just a wrap issue ? - if the download always sends 32KB, then only the last 4/8K would remain.
A patch for this would be to place the tiny code last in an otherwise 0FFH filled 32KB image ?
No. The first block in the 24Cxx gets overwritten and corrupted IIRC. I have posted a solution and code. Try searching for a thread 24C32 or 24C64.
Well, I gave it a good try, could not figure out how to load to a port where the board is connected. Maybe bean will come up with a solution, otherwise, I guess Spin and propGCC are good enough.
Ray
Unzip this file to the directory c:\propbasic
In geany set the execute command (Build->Set Build Commands->Execute) to
go "%d\%e"
Set the execute directory to
c:\propbasic
Put or create a *.pbas file in the c:\propbasic directory from geany.
When you press the Execute button it should compile and load the file.
Comments welcome...
Bean
P.S. The files are already in a propbasic directory in the zip file. Make sure they don't go under c:\propbasic\propbasic.
bean, I just tested out your version, and it works, the LED started to flash. The original version of PropBASIC, that I downloaded from the BST site. was like .14, what version are you at right now, and do you have the docs to reflect that? And you probably realize that in the C world we are working with CMM, XMM, XMMC, I guess LMM is nice but ...
I would like to ask a couple of things:
Could you start a new discussion? The thread title is quite misleading and propbasic deserves a dedicated and clearly identifiable title.
Moreover considering bst is not mandatory anymore could homespun be an alternative as a compiler?
But would still like to get PropBasic supported the "official" Parallax IDE sometime.
Bean
+1 (or +FF if I may?) for having PropBasic in the official Px-IDE
Whilst writing and to give another option... I have been using the Viewport IDE for last couple years and found it works well with PropBasic. I don't use the built-in Viewport debugging code as find that less helpful as the user code-size grows, but in recent versions Hanno (Viewport author) added the capability to compile without Viewport debug code support, (SHIFT+Fx), so it now works really well as an IDE which will compile to PropBasic and upload to Propeller Ram or Eeprom automatically.
If you have not tried Viewport in a while, it might be worth installing the latest Beta version, available from the Hannoware Viewport forum.
I am still trying to figure out why Ken's response to bean was, to go ask jazzed, about adding PropBASIC to SimpleIDE. Anyway, if enough people here keep making an inquiry into why PropBASIC has not gotten a yes or no answer, to be added to SimpleIDE, then why not? I think bean got hung out to dry on this one.
Isn't SimpleIDE is supposed to be a simple IDE for propgcc in the style of the simplicity of the Arduino IDE. It's already burdened down with Spin and a billion request for features.
I am still trying to figure out why Ken's response to bean was, to go ask jazzed, about adding PropBASIC to SimpleIDE. Anyway, if enough people here keep making an inquiry into why PropBASIC has not gotten a yes or no answer, to be added to SimpleIDE, then why not? I think bean got hung out to dry on this one.
Ray
I'm afraid I started this mess by misremembering something that Steve told me a while ago about SimpleIDE. I had thought that he had added a way to easily add new languages to SimpleIDE and my suggestion was really that Bean could himself make use of that facility to add support for PropBasic. It turns out that the generic language support is not present in SimpleIDE and it isn't trivial to add it at this point so that option is not currently open. As Steve said, SimpleIDE is undergoing changes at the moment and until those are completed it isn't practical to add any new language support to it. Once SimpleIDE is in production we can lobby Parallax to fund the generic language feature that will allow other languages including PropBasic to be added.
Comments
-Phil
I'm pretty sure there is an obex object for a chain loader, so you only need one eeprom. Cluso99 explored this with his triblade but I don't think we ever explored the software side fully.
So ok, keep things simple. Three prop chips so that gives Bean all his pins he needs. One eeprom. Chain load. Only one propeller chip has the actual code (spin, basic, whatever). The other two props are running little programs in one cog in pasm. These programs are monitoring a two wire common bus. Master says "here is a 2k binary blob for propeller x, load it into your local ram from the serial bus, then load it into cog x and run it".
Or even simpler, Master might say to Slave 1, "Turn pin x high".
So with 3 propellers you would have 7 cogs per propeller or 21 cogs.
The ram is also accessible, the pasm program running in each prop can handle simple commands on the serial bus like "write long x to address y". So you can offload arrays and strings to the other propellers and then the Master has more room for code.
You could also offload whole functions, like driving a VGA screen, and free up lots of memory.
Maybe it is not so hard after all. All it needs is the bootloader code (which I think is done) and some comms code running in pasm (which I think is also done) and some pasm code to handle really simple things like reading and writing longs and doing a cognew and setting pins.
From the program running in the Master, that might come down to some very simple routines - set pin x on prop y to n. Or load a 2k .cog program from SD card and run it in cog x on prop y. (cog code is going to need to be precompiled and moved to an SD card as there is not room for 21 x2k worth of cog code in the master program).
I'm looking at my schematic right now thinking which is going to be easier - 373 latches, 8255 chips or multiple propeller chips...
Most flexible might be to allow a SOT23 teensy-cheap EEPROM per Prop, with just enough code to make it boot like a 8255
(or similar IO variant).
That means you have the option of everything starting 'normally' and you can then download smarter code, selectively to more of your COGs.
Secret is to keep the local loader as small and as cheap and standard, as you can.
I think the 2 byte address format, kicks in at 24C32? - which does come in SOT23 and matches 1 COG.
Ray
Do you have a "." in any of the folder names ?
Also the filename MUST include the COMPLETE path to the file. And be enclosed in quotes.
Can you try running it from a command prompt ? See if that works...
Dave,
Here is the latest version of the .exe
Bean
Ray
You're almost there ....
The attachment below shows what I've done with propeller-gcc. The same can be done with PropBasic and BSTC. Just replace the propeller-gcc entries with PropBasic commands, and replace propeller-load with BSTC commands.
The project properties dialog can be started from Build -> Set Build Commands
Ray
Before you do a lot of work with the '373 take a look at the '573. Same functionality but the pinout greatly simplifies pcb layout. Same is true for the '540 and '574.
I'm just leaving for the day. I'll attempt it tomorrow.
Bean
Sorry for continuing this sub-thread, but just a little more info may be all you need ....
All the parameters for PropBasic are listed, so I guess that's not a problem. Entering bstc without any arguments in a command window, it will tell you everything you need to know to make it work.
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved Compiled for i386 Linux at 08:17:46 on 2009/07/20 Program Usage :- bstc (Options) Filename[.spin] -a - Create Propeller object archive zipfile -b - Write .binary file -c - Write .dat file for C-Compiler (Drops a <filename.dat> file) -d <device> - Device to load to (Default : ) -D <define> - Define a pre-processor symbol (may be used multiple times) -e - Write .eeprom file -f - Double download baud rate -h - Display this help information -l - Generate listfile -L <Lib Path> - Add a library path or file holding library path(s) to the searchpath (may be used multiple times) -o <filename> - Output [.list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin) -O <options> - Optimise Binary (HIGHLY EXPERIMENTAL!!!!!) a - Enable all optmisations (Be careful! No, really) b - Bigger constants (should be slightly faster at the expense of code size) c - Fold Constants g - Generic "safe" size optimisations for smaller/faster code, however not what the Parallax compiler will generate r - Remove unused Spin Methods u - Fold Unary "-" Operations on Constants if it will make the code smaller x - Non-Parallax compatible extensions -p[012] - Program Chip on device (-d) 0 - Load Ram and run 1 - Load EEProm and shutdown 2 - Load EEProm and run -s - Intersperse source in listfile (use with -l) -w[012] - Error/Warning level - 0 - Errors only / 1 - Error/Warning / 2 - Error/Warning/Information (Default 0) -v - Get program version informationRay
The problem with Roy's compiler is that it does not have serial port support. I'm not sure if he want's to add that or not. We just use propeller-load to load a spin binary when necessary.
It is possible to write a batch file for Geany that does everything with one command, I just don't know the steps.
Is this just a wrap issue ? - if the download always sends 32KB, then only the last 4/8K would remain.
A patch for this would be to place the tiny code last in an otherwise 0FFH filled 32KB image ?
Does anyone know how to do this ? Or if it is even possible ?
Thanks,
Bean
P.S. Nevermind, geany DOES save the file before call the execute program.
No. The first block in the 24Cxx gets overwritten and corrupted IIRC. I have posted a solution and code. Try searching for a thread 24C32 or 24C64.
Unzip this file to the directory c:\propbasic
In geany set the execute command (Build->Set Build Commands->Execute) to
go "%d\%e"
Set the execute directory to
c:\propbasic
Put or create a *.pbas file in the c:\propbasic directory from geany.
When you press the Execute button it should compile and load the file.
Comments welcome...
Bean
P.S. The files are already in a propbasic directory in the zip file. Make sure they don't go under c:\propbasic\propbasic.
Good job! I used /Q instead of /P.
So you're good for now?
Use the attached propeller-load (Windows) and this go.bat
Propelller-load is available for linux and mac also.
Hope to see PropBASIC become alive again.
Ray
Could you start a new discussion? The thread title is quite misleading and propbasic deserves a dedicated and clearly identifiable title.
Moreover considering bst is not mandatory anymore could homespun be an alternative as a compiler?
Massimo
The problem with using /Q is that if there is an error you will not know what it is or where it is...
Yeah, good for now. But would still like to get PropBasic supported the "official" Parallax IDE sometime.
Bean
+1 (or +FF if I may?) for having PropBasic in the official Px-IDE
Whilst writing and to give another option... I have been using the Viewport IDE for last couple years and found it works well with PropBasic. I don't use the built-in Viewport debugging code as find that less helpful as the user code-size grows, but in recent versions Hanno (Viewport author) added the capability to compile without Viewport debug code support, (SHIFT+Fx), so it now works really well as an IDE which will compile to PropBasic and upload to Propeller Ram or Eeprom automatically.
If you have not tried Viewport in a while, it might be worth installing the latest Beta version, available from the Hannoware Viewport forum.
Ray