I don't know if this counts, but propforth has plans to use the spineret to serve HTML5 web pages as the development GUI.
Are you using the spineret as a debug interface to another Propeller board that is running the application you're debugging or is the application running on the spineret itself?
This sounds pretty cool! And, because you're connected by ethernet, you don't even have to be near the machine you're debugging! I can sit in my comfortable chair with my MacBook on my lap and debug my Propeller board over on my desk or in my lab. Maybe I need to try PropForth!
We don't expect the HTML development interface till V5.x in August , so it would be better to wait till then if one is not already a forth fan. Currently Sal has spinerets all over and does remote development on them every day with just a netbook over ethernet using telnet, so that part already works.
But concerning programming directly on the propeller: After propforth.spin is loaded into eeprom, all you need is a serial terminal/emulator. All the propforth users program directly on the propeller from the forth prompt. The PC only provides terminal and storage services.
Are you using the spineret as a debug interface to another Propeller board that is running the application you're debugging or is the application running on the spineret itself?
Both. When more resources are needed than are available on a spineret, Sal uses the multi-prop functionality to add more pins and cogs. Adding a prop works out to 6 more cogs and 32 more pins, since one cog on each prop is consumed by the synchronous serial communications channel. But (so far) there's no difference to the user whether a given cog is 0-7 or 8-15.
Does PropForth support access to an SD card filesystem? Can it run Forth code from external memory or must everything fit in the 32k of hub memory?
The SD support is targeted to the 4.5 release. BUT it is NOT specified to be FAT compatible, the design is install the SD into the prop SD slot and leave it there; the SD memory is to be used in-place as in the ipood or iphone. This is so the hooks to the SD can be included in the default kernel and remain small.
FAT for propforth SD may be continued by the original developer (caskaz) but we don't know if anybody will need it (although it may be nice to have). Current investigation indicates that accessing the SD via the propforth interface will be nearly as fast as accessing the SD via FAT mechanisms, so all that FAT overhead can be eliminated while retaining the end fuctionality.
In the 5.x releases, the plan is to move the bulk of the dictionary to SD. This way, the prop resident protion can be minimal (and tiny) and each SD resident fucntion can be loaded as needed and "forgotten" when complete. This eliminates the need for automatic memory management and the associated overhead. OF course, the developer has to know enough to "craft" the aplication into chunck that fit into the prop appropriately, and function according to application timing constraints. But everybody does this today, the targeted scheme simply provides an option to swap between many (upto SD size) applications that fit in 32k. This is similar to the scheme initially presented by Chuck Moore as "colorFORTH".
So the answer is: Yes, today but not released; yes, but still in development and not to be released till v5.x in August; and yes, the biggest chunk of finctionality that can be handled at one "applcation chunk" must be less than 32k, actually less than 28k due to overhead for the forth kernel.
Sorry if I'm subverting the thread towards forh, I'll stop if this is not appropriate to the discussion. I just wanted to know if anybody could share progress on the HTML5 interface idea.
Prof_Braino:
I have never taken the time to learn forth, you may have given me the incentive.
On the SD side, is this component going to be well documented, and easy to replace? Not every one prefers SD (especially with CF, and pATA device prices falling).
TSorry if I'm subverting the thread towards forh, I'll stop if this is not appropriate to the discussion. I just wanted to know if anybody could share progress on the HTML5 interface idea.
Well, I started the thread and I asked all of the Forth questions so I guess it's okay! :-)
Thanks for the information. I've always thought Forth was an interesting language and it seems it might be the best choice as an on-board language for the Propeller at the moment. I should dig out my copies of Starting Forth and Thinking Forth to remind myself of how to use it!
Prof_Braino:
I have never taken the time to learn forth, you may have given me the incentive.
On the SD side, is this component going to be well documented, and easy to replace? Not every one prefers SD (especially with CF, and pATA device prices falling).
I use forth because I found it to be the easiest, but thats just me.
I do documentation for the kernel, but I usually don't get much feedback for improvements so its propbably not as good as one might want. I am tasked with doing th tutorials on the SD when it gets nearer the release end of development. Please ask all questions, I can get answers from the other team members as needed. If you want to use any other devices, usually the others will help since we all like to play with more toys.
Comments
We don't expect the HTML development interface till V5.x in August , so it would be better to wait till then if one is not already a forth fan. Currently Sal has spinerets all over and does remote development on them every day with just a netbook over ethernet using telnet, so that part already works.
But concerning programming directly on the propeller: After propforth.spin is loaded into eeprom, all you need is a serial terminal/emulator. All the propforth users program directly on the propeller from the forth prompt. The PC only provides terminal and storage services.
Both. When more resources are needed than are available on a spineret, Sal uses the multi-prop functionality to add more pins and cogs. Adding a prop works out to 6 more cogs and 32 more pins, since one cog on each prop is consumed by the synchronous serial communications channel. But (so far) there's no difference to the user whether a given cog is 0-7 or 8-15.
The SD support is targeted to the 4.5 release. BUT it is NOT specified to be FAT compatible, the design is install the SD into the prop SD slot and leave it there; the SD memory is to be used in-place as in the ipood or iphone. This is so the hooks to the SD can be included in the default kernel and remain small.
FAT for propforth SD may be continued by the original developer (caskaz) but we don't know if anybody will need it (although it may be nice to have). Current investigation indicates that accessing the SD via the propforth interface will be nearly as fast as accessing the SD via FAT mechanisms, so all that FAT overhead can be eliminated while retaining the end fuctionality.
In the 5.x releases, the plan is to move the bulk of the dictionary to SD. This way, the prop resident protion can be minimal (and tiny) and each SD resident fucntion can be loaded as needed and "forgotten" when complete. This eliminates the need for automatic memory management and the associated overhead. OF course, the developer has to know enough to "craft" the aplication into chunck that fit into the prop appropriately, and function according to application timing constraints. But everybody does this today, the targeted scheme simply provides an option to swap between many (upto SD size) applications that fit in 32k. This is similar to the scheme initially presented by Chuck Moore as "colorFORTH".
So the answer is: Yes, today but not released; yes, but still in development and not to be released till v5.x in August; and yes, the biggest chunk of finctionality that can be handled at one "applcation chunk" must be less than 32k, actually less than 28k due to overhead for the forth kernel.
Sorry if I'm subverting the thread towards forh, I'll stop if this is not appropriate to the discussion. I just wanted to know if anybody could share progress on the HTML5 interface idea.
I have never taken the time to learn forth, you may have given me the incentive.
On the SD side, is this component going to be well documented, and easy to replace? Not every one prefers SD (especially with CF, and pATA device prices falling).
Well, I started the thread and I asked all of the Forth questions so I guess it's okay! :-)
Thanks for the information. I've always thought Forth was an interesting language and it seems it might be the best choice as an on-board language for the Propeller at the moment. I should dig out my copies of Starting Forth and Thinking Forth to remind myself of how to use it!
I use forth because I found it to be the easiest, but thats just me.
I do documentation for the kernel, but I usually don't get much feedback for improvements so its propbably not as good as one might want. I am tasked with doing th tutorials on the SD when it gets nearer the release end of development. Please ask all questions, I can get answers from the other team members as needed. If you want to use any other devices, usually the others will help since we all like to play with more toys.