Please find attached the stl I used for the wheels.
Pla is quite rigid, so even if your participants are probably quite rough you can reduce the total amount of material to be used speeding up the print.
I am having trouble with installed the EEPROM file system of v5.5 on a Propeller Demo Board.
It does install the .spin image in /current release which works fine.
Then I cut and paste the entire EEprop_boot.f and that seems to install as I get a report with fsls which includes boot.f
But when I try to reboot in anyway, I am shut out. The USB to serial will not communicate with the Propeller Demo Board, powering down or pushing the reset button does nothing.
I have tried the 'reboot <enter> ESC' procedure, but no luck.
If I do not load the EEprop_boot.f , the system works fine.
~~~~~
In need the EEprom file system for 'onboot' and also to store a large data file.
~~~~~
Has anyone else had trouble with v5.5?
I may be able to play with this tonight: if circumstances allow ; if I can stay awake; if I don't zone out in front of the TV; if the Lord's willin' and the crick don't rise!
EDIT: I did some playing. This is all on a QuickStart board.
The first time I tried it: load fresh, cut/paste EEprom_boot.f into terminal, reset, hang.
Then I started deconstructing EEprom_boot.f and had it hang with one sequence, then I was never able to reproduce it. I played around with the words that caused the hang and never got it to hang again.
The sequences:
hA state orC!
and
hA state andnC!
are cool, they turn the interpreter echo, error reporting and such control bits on and off using the 'state' variable:
\ state ( -- addr) access as a char
\ bit 0 - 0 - interpret mode / 1 - forth compile mode
\ bit 1 - 0 - prompts and errors on / 1 - prompts and errors off
\ bit 2 - 0 - Other / 1 - PropForth cog
\ bit 3 - 0 - accept echos chars on / 1 - accept echos chars off
\ bit 4 - 0 - accept echos line off / 1 - accept echos line on
\ bit 5 - 7 - free
You could comment them out if you are still having problems, then you'd see everything the boot.f file did and may be better able to pinpoint the problem, but I digress......
I finally ended up with this for EEprom_boot.f, which seems to work just fine. I added the 'cog?' command in there just to have the boot.f file actually do something.
fl
fsclear
fswrite boot.f
hA state orC! version W@ .cstr cr cr cr
\ findEETOP ( -- n1 ) the top of the eeprom + 1
: findEETOP
\
\ search 32k block increments until we get a fail
\
0
h100000 h8000
do
i t0 2 eereadpage
if
leave
else
i h7FFE + t0 3 eereadpage
if
leave
else
drop i h8000 +
then
then
h8000 +loop
;
c" boot.f - Finding top of eeprom, " .cstr findEETOP ' fstop 2+ alignl L! forget findEETOP c" Top of eeprom at: " .cstr fstop . cr cr
cog?
c" boot.f - DONE PropForth Loaded~h0D~h0D" .cstr hA state andnC!
...
as far as I've experienced, it works as advertised. (plus we learned about a new feature in the interpreter! )
@Mindrobots
Thanks ever so much, I will try adding the 'cog?' that you suggest.
And so, you were having it hang as well.... I have been trying to install this for several days and am stymied.
If might help to know what 'boot.f' should look like internally. And another thing I don't understand is if one can evoke 'boot.f' as a command.. such as 'boot'.
Every time I use reboot, the Propeller requires a complete reload to get it running again. Does this my the v5.5 /current release for PropForth EEPROM needs a change in the .zip file?
Mine just hung the one time, now I can't recreate the hang. (maybe some bad, invisible character in the file that disappeared when editing?)
Try my EEprom_boot.f from post #95. You should just be able to cut/paste it into a FRESHLY loaded PropForth.
Once you are up and running You can do
fsread boot.f
to see the text it contains, you can do this for any file on the EEProm file system
You can do:
fsload to actually load the file and run it through the interpreter. The one in post #95 runs fine this way.
This is how you can extend your Forth. You can load .f files that define words, execute them and then forget them. Little PropForth batch jobs!!
fsls - to list the files on the EEPROM
fsdrop - to get rid of the last file you created
fsclear - to wipe it clean
fstop - puts the top address on the stack (do 'fstop .' to see the top address)
fsbot - puts bottom (starting address) on the stack
Actually, a pretty powerful tool to extend things.
I just thought of one thing - I am running mine a 115200 so I can connect it more places. You could be dropping a character when you do the cut/paste if you are running faster. I rarely see that but one missing character and EEprom_boot.f could create garbage.
....... uuuuuhhhhhhh .... Propeller Demo Board only has a 32K EEPROM .... you can install EEPROM.f but there's no place to put the files ... or did I miss something?????
....... uuuuuhhhhhhh .... Propeller Demo Board only has a 32K EEPROM .... you can install EEPROM.f but there's no place to put the files ... or did I miss something?????
Good catch, Brian!
I read right past the board Loopy was using.
I can go load up a Demo board, bet it won't work!!
Thanks, I seemed to have mixed up eeprom specs of my Propeller Demo Boards with my Propeller Proto Boards.
I am switching over to a Propeller Proto Board for the 64K eeprom.
It all seems clear now. The eeprom_boot.f file does set up the file system on the 32k board, but it just overwrites the .spin image that is required to reboot.
Thanks.
The goal is to simply emulate the QuickStart eeprom space as I do not own a QuickStart board. So no need to use an SDcard.
On of these days, I am going to upgrade the eeprom on the Demo board.. just for convenience sake.
[QUOTE=Loopy Byteloose;1187791 as I do not own a QuickStart board. .. just for convenience sake.[/QUOTE]
Can I just send you a Quickstart? I have a bunch just to give away to folks that are curious, interested, helpful etc.
You do so much that you should at least have the proper equipment. It REALLY helps to have identical hardware, it removes a whole class of "bugs".
Please PM me your mailing address.
NOTE: The protoboard does have electrical differences form the quickstart that will cause the two to behave differently depending on the circuit under investigation. IE the quick start only has the 3.3v regulator and can be powered from USB, this has cause changes from the protoboard version and quickstart version on Sal's and my experiments. Sal finally just got quickstart to stop my stream of "bug" questions.
I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
Code before.
a_next
a_debugonoff
if_never jmpret a_dum_ret, # a_dum ' when debug is loaded this address will be patched
rdword tregone,IP ' the next word
test tregone, fMask wz
if_z add IP, #2 ' if the one of the hi bits is not set, it is an assembler word, inc IP
if_z jmp tregone
rdword tregone, IP ' otherwise it is a forth word
mov tregfive, IP
add tregfive, #2
mov IP, tregone
call #a_rsPush
jmp #a_next
Code after.
a_next
a_debugonoff
if_never jmpret a_dum_ret, # a_dum ' when debug is loaded this address will be patched
rdword tregone,IP ' the next word
test tregone, fMask wz
if_z add IP, #2 ' if the one of the hi bits is not set, it is an assembler word, inc IP
if_z jmp tregone
'fjernet instr !PBP 'rdword tregone, IP ' otherwise it is a forth word
mov tregfive, IP
add tregfive, #2
mov IP, tregone
call #a_rsPush
jmp #a_next
a__maskin
and stTOS, ina wz
muxnz stTOS, fLongMask
jmp # a_next
'nop, der ikke betyder noget, men skal v
Some things are about personal preference. I have my own and try to respect other people's. And then there is the problem of international shipping costs.
Since I reside half way around the world I am reluctant to have people bother with shipping me gifts as it is more costly than they expect when they offer to send. In many cases it is more than the cost of the item. It other cases, items just can't be easily sent due to weight or import/export restrictions... like lithium batteries.
And I do actually have more Propellers than I have actually ever used. Costs have risen. Even the USPS now sends everything international by air, even books.
More variety just tends to transfer to being more clutter at this point. Being a pre-QuickStart user, I have my 8 LED display, and other items that plug into the ProtoBoard. And you many not be aware that I authored a spreadsheet that lists the i/o variations for all the earlier Propeller Boards -- the Demo Board, the Hydra, the ProtoBoard, and a few more.
I just forgot to check the size of the eeprom on the DemoBoard.
For coding purposes the Propeller ProtoBoard and the QuickStart Board on not that different -- both have the 64k eeprom. Sure the QuickStart has 8 built in LEDs, has 8 touch switches, and can run directly from USB, but I am just working with the other i/o.
I really do prefer the ProtoBoard with a complete VGA interface, and keyboard and mouse interfaces. And, I am very wary of devices that try to power everything from a USB port. So much of the Propeller ProtoBoard real usefulness is in providing VGA video with conventional interfaces. And the ProtoBoards in a 5 pack makes the shipping problem easier.
I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
Thanks for the hint. I'll open an "enhancement" issue report, so Sal can take a look at it.
I can't really tell from looking at the code what is impacted by the change. Needing a nop when you don't expect one is a warning that something is not quite right. To check if anything got broken, the test automation needs to be run. Are you able to run the automation?
But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
Looks like the dictionary has been generated for the before code. As it is just a dump it doesn't get updated automatically for your after changes. That said, the nop - if used - should appear before a__maskin but an updated dictionary would be the right solution.
I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
.
The nop is because the memory map has not been updated via a rebuild from scratch, so the nop can go away at the next full build.
The full build process is not properly documented, must do build process steps, the kernel being used is different from the kernel being generated. So we just have to keep the sysmbol in order, update symgen. The full build process will be automated in PF6.
Sal says, yes, that instruction is redundant. it will be removed in PF6, he's working on it now. .... more in a minute. still in the call.
it makes the kernel one long shorter, and one instruction faster. a_next is run all the time, making it fast is a really good idea.
Congratulations! This has been in here for a long time, and nobody else noticed it. Thanks a bunch!
Not only is it one instruction shorter, but that instruction takes 8 clockcycles, and it has to wait 12 clockcycles, before it kan be executet while it has to wait for the next hub windue. So it will make the routine 20 clock pulses shorter.
So you ask: Are you able to run the automation? No, I can not find my way around in the documentation.
Not only is it one instruction shorter, but that instruction takes 8 clockcycles, and it has to wait 12 clockcycles, before it kan be executet while it has to wait for the next hub windue. So it will make the routine 20 clock pulses shorter.
If anybody asks, tell them braino says "FRIDA ROCKS!"
So you ask: Are you able to run the automation? No, I can not find my way around in the documentation.
The automation is the only way to make changes to the kernel and test that nothing got broken; as testing everything by hand would take months or years. It wasn't so difficult at first, but has gotten out of hand. I guess it time to fix this.
If you are interested, PM me with your email, I can walk you through the process. I would use your feedback to clarify and document the current process.
PF6 is going to be significantly more complex than PF5, the estimate is an order of maginitude. There is a specific requirement for real background processing and multitasking. There will be the same set of kernels, with some additions. We don't know if anyone besides Sal and Nick will be able to use this ability, but Sal definitely will, and its his tool. We can still use PF6 the same as previous version and on the Prop 1; but using the new multitasking features to their fullest may be beyond new user's abilities. That's ok, just don't expect to master crafting application multitasking on a microprocessor in one day.
All the targeted functionality has been implemented in code in one form or another in Sal's projects, adding the completed code to the kerenl is not so much an issue. The majority of the effort will be testing. In this case we will perform what Sal calls "server style testing", where the focus is not so much "did it pass", but rather "did it run under full load 24/7 for months with no glitches". We will have something to test in a couple months. AFter release, the server style testing will continue, and will use the logging package extesnsion that we posted recently.
Sal looked at frida's suggestion from issue 194. It appears that the instruction in question is in fact redundant, and should be removed. The nop can (will) go away after the kernel is rebuilt from scratch, with a new symgen file created in the build proess. Since a_next is called very often, this will have a significant speed benefit, and we reduce the memory footprint by one long. Thanks again frida! This change will be added to PF6. This issue has triggered forther scrutiny of that section of code. Kuroneko has found two make that three more changes to speed things up. Code review is usually impossible to get started, let alone get through; here is an example of the benefit it brings. Thanks all!
Issue 192 was in fact a bug. The UNDEFINED WORD condition calls "clear keys" to clear the input stream, and it erroneously leaves a value on the stack. This is fixed in PF6.
The build process will be easier next round, maybe we will get some documentation.
The SR04 is giving me problems, I don't know if I have bad modules of the voltage is wrong (alkaline batteries vs USB), but changing to a long distance (greater than 1 meter) seems to time out and the SR04 measurement stops changing. We'll do testing this week, Sal's works, maybe I have loose wires?
I sorted out detail in the bot.f program in the extensions directory, the changes are in the LittleRobot thread. Hopefully we will refine other offerings in the extensions directory as well, some of those are a bit rough. I'll have to post any changes to the non-kernel files from the download on the wiki.
None of the changes we have found impact kernel functionality, so we still don't need another release for the PF5 series.
Awesome! Thanks caskaz. I want to use a Propeller to resurrect an old 1-wire weather station (the original from Dallas Semiconductor) that will allow the Prop to present the WX data to a small vga screen instead of the original requirement of having a dedicated PC. I trust it will run with PF 5.5?
I have PF5.5 up and running and have looked at the 1-wire code. How would I output data to a TV_text display, much like TV_Text.spin does? Are there dictionary words already created that support this output?
Thanks! I'm looking forward to learning PF and putting it to use!
How would I output data to a TV_text display, much like TV_Text.spin does?
In the extensions directory, there is vga.f, that's as far as we took it. We tested the TV out put in 3.2, but the text was too clunky to be useful, and their was not much room for graphics. The thinking was that any modern TV has VGA input anyway, and an older TV would be a giant power hog. Of course, its still perfectly possible to implement TV in your project if you wish.
Now that the kernel is optimized it may be easier to make something useful, but it is not on Sal's list at this time.
See section 7 of the propforth manual in the doc directory to get started in assembler. You should be able to borrow the algorithm from TV_text.spin
It has been pointed out that the materials were getting harder for new folks instead of easier. As our knowledge increases, I loose touch with what new folks DON'T know.
The questions that need to be answered are "What's the Goal?" and "Where do I Start?". I've been told that once these are answered, the materials can be found.
I updated the Google code PropForth landing page to links to these pages:
Sal is happy with the results of LittleRobot so far.
Story: Kid spent $500 on a bot, but couldn't get the software to work. It was Arduino, there's tons of stuff, but much of it is proprietary. There are so many hardware configs, and nothing is the same. Kind of a mess, from the kid's point of view. There is a real need for an open source software to drive a bot.
So, this give us our approach for LittleRobot. The $20 key parts and $50 kit price goals have been met. Can we make the hardware and software acessible?
SR04 - Sal has found no issue with SR04 that would account for the error I see, which is the SR04 stops responding after a long measurement (greater than 1.5 meters). Today we realized Sal BOT 1 config did NOT use quickstart, and quickstart pins 16 and 17 have LEDs and drivers. These should not affect anything as far as we can tell. But I'm going to move to different piins and see if anything changes. Otherwise maybe I have a bad batch of SR04.
PROPFORTH 6 Beta test: Sal is looking for folks to Beta test the Propforth 6 multitasking. Here, multitasking is different from just running different apps in separate cogs as infinite loops. The processing opportunities are spread over the available processors/threads. I kind of get the concept, but not really; so we'd like to find folks that really understand true multitasking to participate. He's looking for 2 to 5 people, and he will corespond directly with the folks, rather than through the forums. Please PM me if you are interested trying this out and providing input. Anybody know how to describe a program as a bunch of parallel things?
Comments
Pla is quite rigid, so even if your participants are probably quite rough you can reduce the total amount of material to be used speeding up the print.
Massimo
Posted!
http://code.google.com/p/propforth/downloads/detail?name=Wheels-max72-20130527.zip
Thanks!
It does install the .spin image in /current release which works fine.
Then I cut and paste the entire EEprop_boot.f and that seems to install as I get a report with fsls which includes boot.f
But when I try to reboot in anyway, I am shut out. The USB to serial will not communicate with the Propeller Demo Board, powering down or pushing the reset button does nothing.
I have tried the 'reboot <enter> ESC' procedure, but no luck.
If I do not load the EEprop_boot.f , the system works fine.
~~~~~
In need the EEprom file system for 'onboot' and also to store a large data file.
~~~~~
Has anyone else had trouble with v5.5?
I may be able to play with this tonight: if circumstances allow ; if I can stay awake; if I don't zone out in front of the TV; if the Lord's willin' and the crick don't rise!
EDIT: I did some playing. This is all on a QuickStart board.
The first time I tried it: load fresh, cut/paste EEprom_boot.f into terminal, reset, hang.
Then I started deconstructing EEprom_boot.f and had it hang with one sequence, then I was never able to reproduce it. I played around with the words that caused the hang and never got it to hang again.
The sequences:
and
are cool, they turn the interpreter echo, error reporting and such control bits on and off using the 'state' variable:
You could comment them out if you are still having problems, then you'd see everything the boot.f file did and may be better able to pinpoint the problem, but I digress......
I finally ended up with this for EEprom_boot.f, which seems to work just fine. I added the 'cog?' command in there just to have the boot.f file actually do something.
fl fsclear fswrite boot.f hA state orC! version W@ .cstr cr cr cr \ findEETOP ( -- n1 ) the top of the eeprom + 1 : findEETOP \ \ search 32k block increments until we get a fail \ 0 h100000 h8000 do i t0 2 eereadpage if leave else i h7FFE + t0 3 eereadpage if leave else drop i h8000 + then then h8000 +loop ; c" boot.f - Finding top of eeprom, " .cstr findEETOP ' fstop 2+ alignl L! forget findEETOP c" Top of eeprom at: " .cstr fstop . cr cr cog? c" boot.f - DONE PropForth Loaded~h0D~h0D" .cstr hA state andnC! ...as far as I've experienced, it works as advertised. (plus we learned about a new feature in the interpreter!
Thanks ever so much, I will try adding the 'cog?' that you suggest.
And so, you were having it hang as well.... I have been trying to install this for several days and am stymied.
If might help to know what 'boot.f' should look like internally. And another thing I don't understand is if one can evoke 'boot.f' as a command.. such as 'boot'.
Every time I use reboot, the Propeller requires a complete reload to get it running again. Does this my the v5.5 /current release for PropForth EEPROM needs a change in the .zip file?
Try my EEprom_boot.f from post #95. You should just be able to cut/paste it into a FRESHLY loaded PropForth.
Once you are up and running You can do
fsread boot.f
to see the text it contains, you can do this for any file on the EEProm file system
You can do:
fsload to actually load the file and run it through the interpreter. The one in post #95 runs fine this way.
This is how you can extend your Forth. You can load .f files that define words, execute them and then forget them. Little PropForth batch jobs!!
fsls - to list the files on the EEPROM
fsdrop - to get rid of the last file you created
fsclear - to wipe it clean
fstop - puts the top address on the stack (do 'fstop .' to see the top address)
fsbot - puts bottom (starting address) on the stack
Actually, a pretty powerful tool to extend things.
I just thought of one thing - I am running mine a 115200 so I can connect it more places. You could be dropping a character when you do the cut/paste if you are running faster. I rarely see that but one missing character and EEprom_boot.f could create garbage.
Play more, see what you get, report back.
It's NAP time!!!
Good catch, Brian!
I read right past the board Loopy was using.
I can go load up a Demo board, bet it won't work!!
As stated, EEprom kernel will load on Demo board but a stock unit with 32K EEprom will not have any place for files.
On the Demoboard its recommended to use the SD kernel and do the SD-adapter-as-slot trick from
http://code.google.com/p/propforth/wiki/PropToSDconnection
and
http://code.google.com/p/propforth/wiki/SDsetupREVISITED
No function about A1M4/A1M3/A1M2/A1M1/A2M4/A2M3/A2M2.
I am switching over to a Propeller Proto Board for the 64K eeprom.
It all seems clear now. The eeprom_boot.f file does set up the file system on the 32k board, but it just overwrites the .spin image that is required to reboot.
Thanks.
The goal is to simply emulate the QuickStart eeprom space as I do not own a QuickStart board. So no need to use an SDcard.
On of these days, I am going to upgrade the eeprom on the Demo board.. just for convenience sake.
WOW! Caskaz, your code looks great! I can completely tell what it's doing just by reading it.
Now my goal is to improve my coding so it reaches this level.
Can I just send you a Quickstart? I have a bunch just to give away to folks that are curious, interested, helpful etc.
You do so much that you should at least have the proper equipment. It REALLY helps to have identical hardware, it removes a whole class of "bugs".
Please PM me your mailing address.
NOTE: The protoboard does have electrical differences form the quickstart that will cause the two to behave differently depending on the circuit under investigation. IE the quick start only has the 3.3v regulator and can be powered from USB, this has cause changes from the protoboard version and quickstart version on Sal's and my experiments. Sal finally just got quickstart to stop my stream of "bug" questions.
I have made a change in "a_next" which provides 30% faster throughput of Forth high level words.
But there is something I do not understand, I need to insert a "nop", instead of the instruction I have removed?
Code before.
a_next
a_debugonoff
if_never jmpret a_dum_ret, # a_dum ' when debug is loaded this address will be patched
rdword tregone,IP ' the next word
test tregone, fMask wz
if_z add IP, #2 ' if the one of the hi bits is not set, it is an assembler word, inc IP
if_z jmp tregone
rdword tregone, IP ' otherwise it is a forth word
mov tregfive, IP
add tregfive, #2
mov IP, tregone
call #a_rsPush
jmp #a_next
Code after.
a_next
a_debugonoff
if_never jmpret a_dum_ret, # a_dum ' when debug is loaded this address will be patched
rdword tregone,IP ' the next word
test tregone, fMask wz
if_z add IP, #2 ' if the one of the hi bits is not set, it is an assembler word, inc IP
if_z jmp tregone
'fjernet instr !PBP 'rdword tregone, IP ' otherwise it is a forth word
mov tregfive, IP
add tregfive, #2
mov IP, tregone
call #a_rsPush
jmp #a_next
a__maskin
and stTOS, ina wz
muxnz stTOS, fLongMask
jmp # a_next
'nop, der ikke betyder noget, men skal v
Since I reside half way around the world I am reluctant to have people bother with shipping me gifts as it is more costly than they expect when they offer to send. In many cases it is more than the cost of the item. It other cases, items just can't be easily sent due to weight or import/export restrictions... like lithium batteries.
And I do actually have more Propellers than I have actually ever used. Costs have risen. Even the USPS now sends everything international by air, even books.
More variety just tends to transfer to being more clutter at this point. Being a pre-QuickStart user, I have my 8 LED display, and other items that plug into the ProtoBoard. And you many not be aware that I authored a spreadsheet that lists the i/o variations for all the earlier Propeller Boards -- the Demo Board, the Hydra, the ProtoBoard, and a few more.
I just forgot to check the size of the eeprom on the DemoBoard.
For coding purposes the Propeller ProtoBoard and the QuickStart Board on not that different -- both have the 64k eeprom. Sure the QuickStart has 8 built in LEDs, has 8 touch switches, and can run directly from USB, but I am just working with the other i/o.
I really do prefer the ProtoBoard with a complete VGA interface, and keyboard and mouse interfaces. And, I am very wary of devices that try to power everything from a USB port. So much of the Propeller ProtoBoard real usefulness is in providing VGA video with conventional interfaces. And the ProtoBoards in a 5 pack makes the shipping problem easier.
Thanks for the generous thoughts.
Thanks for the hint. I'll open an "enhancement" issue report, so Sal can take a look at it.
I can't really tell from looking at the code what is impacted by the change. Needing a nop when you don't expect one is a warning that something is not quite right. To check if anything got broken, the test automation needs to be run. Are you able to run the automation?
The nop is because the memory map has not been updated via a rebuild from scratch, so the nop can go away at the next full build.
The full build process is not properly documented, must do build process steps, the kernel being used is different from the kernel being generated. So we just have to keep the sysmbol in order, update symgen. The full build process will be automated in PF6.
Sal says, yes, that instruction is redundant. it will be removed in PF6, he's working on it now. .... more in a minute. still in the call.
it makes the kernel one long shorter, and one instruction faster. a_next is run all the time, making it fast is a really good idea.
Congratulations! This has been in here for a long time, and nobody else noticed it. Thanks a bunch!
So you ask: Are you able to run the automation? No, I can not find my way around in the documentation.
If anybody asks, tell them braino says "FRIDA ROCKS!"
The automation is the only way to make changes to the kernel and test that nothing got broken; as testing everything by hand would take months or years. It wasn't so difficult at first, but has gotten out of hand. I guess it time to fix this.
If you are interested, PM me with your email, I can walk you through the process. I would use your feedback to clarify and document the current process.
This offer is open to any readers of this thread.
PF6 is going to be significantly more complex than PF5, the estimate is an order of maginitude. There is a specific requirement for real background processing and multitasking. There will be the same set of kernels, with some additions. We don't know if anyone besides Sal and Nick will be able to use this ability, but Sal definitely will, and its his tool. We can still use PF6 the same as previous version and on the Prop 1; but using the new multitasking features to their fullest may be beyond new user's abilities. That's ok, just don't expect to master crafting application multitasking on a microprocessor in one day.
All the targeted functionality has been implemented in code in one form or another in Sal's projects, adding the completed code to the kerenl is not so much an issue. The majority of the effort will be testing. In this case we will perform what Sal calls "server style testing", where the focus is not so much "did it pass", but rather "did it run under full load 24/7 for months with no glitches". We will have something to test in a couple months. AFter release, the server style testing will continue, and will use the logging package extesnsion that we posted recently.
Sal looked at frida's suggestion from issue 194. It appears that the instruction in question is in fact redundant, and should be removed. The nop can (will) go away after the kernel is rebuilt from scratch, with a new symgen file created in the build proess. Since a_next is called very often, this will have a significant speed benefit, and we reduce the memory footprint by one long. Thanks again frida! This change will be added to PF6. This issue has triggered forther scrutiny of that section of code. Kuroneko has found two make that three more changes to speed things up. Code review is usually impossible to get started, let alone get through; here is an example of the benefit it brings. Thanks all!
Issue 192 was in fact a bug. The UNDEFINED WORD condition calls "clear keys" to clear the input stream, and it erroneously leaves a value on the stack. This is fixed in PF6.
The build process will be easier next round, maybe we will get some documentation.
The SR04 is giving me problems, I don't know if I have bad modules of the voltage is wrong (alkaline batteries vs USB), but changing to a long distance (greater than 1 meter) seems to time out and the SR04 measurement stops changing. We'll do testing this week, Sal's works, maybe I have loose wires?
I sorted out detail in the bot.f program in the extensions directory, the changes are in the LittleRobot thread. Hopefully we will refine other offerings in the extensions directory as well, some of those are a bit rough. I'll have to post any changes to the non-kernel files from the download on the wiki.
None of the changes we have found impact kernel functionality, so we still don't need another release for the PF5 series.
I wrote code for 1-wire-devices.
#205 below;
http://forums.parallax.com/showthread.php/138399-Propforth-5.0-is-available-for-download/page11
Thanks! I'm looking forward to learning PF and putting it to use!
In the extensions directory, there is vga.f, that's as far as we took it. We tested the TV out put in 3.2, but the text was too clunky to be useful, and their was not much room for graphics. The thinking was that any modern TV has VGA input anyway, and an older TV would be a giant power hog. Of course, its still perfectly possible to implement TV in your project if you wish.
Now that the kernel is optimized it may be easier to make something useful, but it is not on Sal's list at this time.
See section 7 of the propforth manual in the doc directory to get started in assembler. You should be able to borrow the algorithm from TV_text.spin
The questions that need to be answered are "What's the Goal?" and "Where do I Start?". I've been told that once these are answered, the materials can be found.
I updated the Google code PropForth landing page to links to these pages:
http://code.google.com/p/propforth/wiki/GettingStartedWithPropForth
http://code.google.com/p/propforth/wiki/GettingStartedLittleRobot
Could folks look at these and see if they could be simplified further, or better made to answer getting started? Thanks!
Sal is happy with the results of LittleRobot so far.
Story: Kid spent $500 on a bot, but couldn't get the software to work. It was Arduino, there's tons of stuff, but much of it is proprietary. There are so many hardware configs, and nothing is the same. Kind of a mess, from the kid's point of view. There is a real need for an open source software to drive a bot.
So, this give us our approach for LittleRobot. The $20 key parts and $50 kit price goals have been met. Can we make the hardware and software acessible?
SR04 - Sal has found no issue with SR04 that would account for the error I see, which is the SR04 stops responding after a long measurement (greater than 1.5 meters). Today we realized Sal BOT 1 config did NOT use quickstart, and quickstart pins 16 and 17 have LEDs and drivers. These should not affect anything as far as we can tell. But I'm going to move to different piins and see if anything changes. Otherwise maybe I have a bad batch of SR04.
PROPFORTH 6 Beta test: Sal is looking for folks to Beta test the Propforth 6 multitasking. Here, multitasking is different from just running different apps in separate cogs as infinite loops. The processing opportunities are spread over the available processors/threads. I kind of get the concept, but not really; so we'd like to find folks that really understand true multitasking to participate. He's looking for 2 to 5 people, and he will corespond directly with the folks, rather than through the forums. Please PM me if you are interested trying this out and providing input. Anybody know how to describe a program as a bunch of parallel things?