No need to apologize, I was just trying describe my first experience with PropForth. For something as new, to the Propeller world, as this, the experience has to be as painless as possible. I think for some people, they give up as soon as the UI appears, keep at it, you have a good product, at that price point.
Today's Call:
The task remaining for 5.3 is updating all the little things. These are all the updates and tweaks to the documentation and examples. There are a bunch.
Sal has cut over to the new automated build procedure. The old "manual" build procedure will not be covered in the documentation, as it is no long used. The capability is still there, if somebody wants to use it, that person will be the guinea pig for that documentation.
More interesting and more useful than the manual build is using the automated procedure to build and test new kernels. Sal plans on covering each of the new kernels and how they are used, and how to create custom kernels. This ability is VERY powerful, most folks don't how to use it or do it. (Me included).
The paged assembler technique is targeted for thorough coverage. Sal has pointed out that the propforth kernel is very small, smaller than any other forth version he has created for various micro controllers. With paged assembler and an SD card we can have virtually unlimited optimizations and routines. We have a very large amount of the prop's memory available for applications. WE should be able to run from scripts off of SD and achive applications of any size. The I/O channels should allw processor power to be scaled according to the application. Very interesting applications should be possible now. The progress on the Little Robot project indicates we might be able to see some results soon.
After we are fully cut over to the automated system and start in on the documentation, we also have the task of bringing forward the previous library of extensions. We discussed whether or not to keep the Hi-Res VGA in Jupiter ACE from Propforth 3.2. The use-case discussed is having for example a Demoboard or C3 running Hi-Res VGA Jupiter ACE, and use this as a terminal to access an array of MCS props. This case was deemed useful. This was my initial goal when I purchased my first prop demo board in 2008, I'm glad we're finally going to achieve this. See? It's only taken 5 years. Like a stream cutting through a mountain, it just takes patience.
Now that the bulk of the development work on Propforth 5.3 is done, there should be no further development on Propforth, we should now concentrate on creating applications. EXCEPT Sal got another idea after looking again at the specs for the Prop 2. So there seems to be ONE MORE new development release in store for propforth.
Preliminary Concept: Propforth 6 will be designed to take advantage of the abilities of the Prop 2 micro controller.
The first plan is to expand on the common interface for the I/O, and create a generic channel, so all IO will be built on this generic channel.
The second plan involves software multitasking. Forth is famous for software multitasking, allowing multitasking on nearly any single hardware thread processor. On the prop 1 software multitasking was implemented and removed, as it cost memory and did not meet any need; we usually have plenty of cogs available. But there are several functions in a cog that operate independently, like counter, timer, freq, etc. On the Prop 2 we will have more memory and can better afford additional stacks for software multitasking. So the plan is to implement software multitasking to allow those functions to happen simultaneously in realtime, with some ability for deterministic execution. We're looking at up to 8 software task threads in a single cog. The developer will still have to recognize which tasks requires a dedicated cog; but for those that tend to be less time critical and have spare time, there will be an ability to take advantage of several parallel functions simultaneously on a single cog. Very cool!
With the Prop 2 faster clock speed and more memory, many things are different.
The faster clock speed means serial could be over a megabit, and MCS could be 5 to 10 times faster. The electrical circuits might not be as simple as now and will require some tweaking, but it looks very promising.
The fast EEPROM (1 cycle) has very big effect: We can put optimized kernel routines in fast memory, and leave the bulk of the RAM available for user applications.
We'll finish up 5.3, and start implementing PF 6 on prop 1 to prepare. The same code should work on either, the Prop2 stuff will just be a little slower on Prop1
This FFloat(FloatMath.spin) convert only integer because spin convert fraction(1.65, etc) inside it.
But PropForth have only integer.
I want to convert fraction(1.65, etc) to float-point-form.
I don't know how to convert.
Do you have any ideas?
Sal has that float.f in the misc directory, did you see that? That and the doublemath.f should handle most of what we usually see, but it might not be the fastest solution.
There's also the scaled integer, that's my favorite as its easier to get more accurate.
What exactly are you trying to do? There might be a nice way to get what you want, with out the pain of software float support.
Hi.
I wrote POV's code by using QuickStart board on PropForth4.6.
POV_1.0 is for PropForth5.2.
And POV_1.1 modified a little bit.
Left photo(ZYWXYZ..) is POV_1.0.
Right(IHJK..) is POV_1.1.
Watching mirror-letters because shaking from right to left and from left to right.
To prevent this, next plan is LED-on only one direction.
The final downloadable archive is being prepared for v5.3.
The Little Robot project is continuing to progress. The mechanical design for the chassis is still the critical path. I have some couplers for connecting the steeper shafts to the wheels in test.
I read up on the Trademark symbol (tm). I believe it declares that I am using the Little Robot name to identify this particular unit as coming from the particular source. Anybody else can make something similar, but only this one is the little Robot. Anybody has additional insight to this? I think I just like putting in the (TM).
I started looking at Jamie Mantzel's spider tank robot.
His bot also has 2 motors and four AA batteries. But The Mantzel bot lacks ultrasonic range finder and other sensors, and a capability for processing complex data streams. I think a prop and propforth are called for. I think I can see a Mantzel chassis in the future for the LittleRobot.....
This use DC-motor? Not servo motor?
One leg has 2 motors? Or whole 2 motors?
The entire robot has only two DC motors. Its VERY clever. One motor powers all six legs, when the motor is turning, the spider is walking. The second motor only control which direction it the front. The robot's "face" is always the front, when the face changes changes direction, that is the new "front".
This is along the lines of Mark Tilden's [http://www.beam-wiki.org/wiki/Nervous_net_as_the_lowest_layer_in_a_subsumptive_design subsumption architecture]. When the motor is turning, the robot walks, it needs no intervention from the processor. This allows the processor to be used for more interesting purposes or to be absent. Its a cool idea, and propforth possibly fits well.
If you see the Hexbug "spider" it is a copy of this design (but Hexbug did not give credit to the inventor). The Hexbug is $25 here, so its still way over priced. They can be found at Toy 'R Us here, they might have them also by you.
Hi
I wrote Wii_Nunchuku at PropForth4.6
I rewrite it for PropForth5.2. Only hex-number(a -> A, b -> B, c -> C, d -> D, e -> E, f -> F)
It's Wii_Nunchuck_0.2.
I checked WORD"test".
Its output datas from Nunchuck.
But error occured.
Prop0 Cog6 ok
test
CON:Prop0 Cog6 RESET - last status: 7 LOCK TIMEOUT
Prop0 Cog6 RESET - last status: 7 LOCK TIMEOUT
Prop0 Cog6 ok
I checked WORD"_eeread" and "_eewrite" by decompV2A.fth, because I cannot find out code-sources in PropForthDevKernel.f and PropForthStartKernel.f and etc.
Prop0 Cog6 ok
decomp _eeread
: _eeread
lxasm 35A8_4112
Prop0 Cog6 ok
decomp _eewrite
: _eewrite
lxasm 3638_3F12
These are different from PropForth4.6.
I loaded PropForth4.6's "_eewrite" to WiiNunchuck_0.2.
Error has gone. But datas from Nunchuck are nonsense.
I loaded PropForth4.6's "_eeread" to WiiNunchuck_0.2 too.
Datas from Nunchuck are correct.
I think I mistake how to use PropForth5.2's "_eewrite".
Does anyone know correct using "_eewrite"?
I modified Wii_nunchaku.
I rename _eewrite and _eereadof PropForth4.6, because _eewrite and _eereadof PropForth5.2 cannot use on Wii_nunchaku.
I have no idea why they cannot use.
The only adjustments I made to these instructions were to send PropForth_hiresvga-demoboard.spin to the EEPROM with F11 (replacing BASIC for the time being) and using Hyperterm. Instead of copy/pasting the file, I used the "Send Text File" under the Transfer menu to send the file, hiresvga20100912-0943 fix-demoboard.f.
Pretty slick!
Are there major differences between this version (3.5) and the current 5.0 download?
send PropForth_hiresvga-demoboard.spin to the EEPROM with F11 (replacing BASIC for the time being) and using Hyperterm.
Instead of copy/pasting the file, I used the "Send Text File" under the Transfer menu to send the file, hiresvga20100912-0943 fix-demoboard.f.
Thanks!
Are there major differences between this version (3.5) and the current 5.0 download?
The forth words and the way they are used is mostly the save. The FORMAT FOR CONSTANTS has changed/is changing; constatnts now require a prefix letter d for decimal, h for hex, and x for 64 bit encoding, to decouple the number base of the source from the changeable number base of the cog running forth.
Along with that, the interfaces are being standardized, its much easier to interface from one task to another, but this is kind of deep and will be a whole section of the docs. From the user point of view there is nothing we have to do except use it.
Also, everything has been / is being optimized for speed and small memory footprint.
The JupiterACE in 5.3 (not released) will be must smaller and faster, but any code you write for 3.5 should work with minimal changes (as described above).
The goal will be a Jupiter ACE running on a demoboard, talking to an array of propchip of arbitrary size, doing arbitrary prop applications, communicating over MCS/Go channels/CSP channels.
We had one glitch in testing, the SNET test for Spineret/wiznet5100 failed. It turns out that the standard test bed Spinneret MUST have a version of Propforth 5.x installed. Although the test automagically loads the current version under test, the new baud rate setting of 230400 makes it incompatible with the 57600 baud from the pre-v5.x versions. We never implemented auto baud detection, this is the price we pay. However the code is still stable, and I'll upgrade the spineret firmware to PropForthDevKernel.spin and rerun the tests. We should be good to go after it completes successfully.
The next release will include driver source code for servo, steppers, BMP085. Sal is starting in on the hires video support for JupiterACE, this should be the last bit.
We're reworking the release archive and documentation. The plan is to cut over from using the previous version to generate the new kernel, to using the new kernel to generate itself. To the user, everything should look the same from the outside, but internally we have to shuffle some stuff around. Also, we are going to make another stab at proper tutorials. We think we want to start with a set of standard diagnostics (command line, logic analyzer, and possibly debugger) and examples of how to use them. WE also want to present the standard "elemental" activities, set a pin high or low, read a pin state high or low; output a frequency, read a frequency; output PWM, read PWM; and show how to produce/detect these events with the standard diagnostics. These sections will be added to propforth.htm
Is there a version of PropForth which can qualify as a Tiny Forth version?
I believe "tiny" is just a redundant adjective when describing forth in general. An exception would be something like FPC which is a PC based forth which has about 3000 zillion functions for every possible thing the guys could think of. Which was really cool, but most of the stuff never gets used, so its kind of a waste. And it was too much for me to keep track.
In the case of propforth, the memory foot print keeps getting smaller and resources available to the user for applications keeps increasing. So "tiny" would apply to each kernel compared to the last. Propforth 5.3 will have the smallest memory foot print and most resources available for user applications so far compared to the previous releases. Also, it will be noticeably faster due to optimization of critical functions. The "paged assembler" functions will permit very small optimized functions to be brought in and out of memory on the fly, and is easier to use than previous assembler optimization implementation.
So, the short answer is 5.0 for now, and will be 5.3 when it comes out.
Sunday's Call:
We're starting to talk about client software on android devices.
For example, we talked about putting propforth's software LOGIC ANALYZER UI on android.
Android devices tend to have fairly nice displays, at least compared to the old VGA monitors we had earmarked for prop projects. The question remains on what is the best way to distribute these android apps to be used with propforth. I'm thinking we may be limited to rooted devices, but I'm no android expert. If anybody wants to help with the android parts, please PM me. There are lots of Cortex A8 devices coming out that look like they will be excellent hand held terminals. Currently the tabeo, meep, and nabi can be locally had, I'm thinking after xmas these will be coming down below $100 and with better features.
We're liking the bluetooth modules to interface to the devices.
So the model may be android+bluetooth to propforth+bluetooth.
WE discussed spinneret vs Raspberry Pi. Wiznet or spinneret can be had for $20 to $50. Raspberry Pi can be had for $35 and is WAY better for slightly more power.
From the prop standpoint, bluetooth use much fewer resources and less power. While spineret/wiznet/ethernet will still be present in V5.3, we don't know where it will go moving forward. There doesn't seem to be much a use case for it anymore.
I just learned about marking a cog as "in use" in propfroth.
Turns out Propforth.htm section 9.1.305 has "all the information we need". Unfortunately, it doesn't have any documentation on what the section actually means, so I opened an issue for it.
Turns out, that when the comiler is looking fro a free cog to use, it looks in the state table. To Mark a Cog as USED, turn off Bit 2. If bit 2 is off, compiler doesn;'t try to use it. That explains a lot right there, but I think it needs a little more. Sal will add some words on this to section 6 next release.
My task for the Little Robot(tm) demo is write the getting started guide. I will write the instructions to exercise the Little Robot(tm) functionality, and Sal will write the code that makes it do whatever that is. This may be the first project I've participated in where we do things in the proper order.
WE also started talking about Turtle Graphics and SCRATCH. Previously, we had looked into using 12blocks to talk to propforth (and generate forth code), and even contacted Hanno. There were no technical reasons why it wouldn't work, but that effort was overcome by events. Now it looks like we may a have a chance to pursue this as part of the v5.3 demo development.
This week I'm presenting the Little Robot Demo to a local school. I have two prototypes built, they look really Mad Max. I don't think they will dance by Friday, but they will serve their purpose by simply sitting there and looking cute.
For the Android interface, would a Roving Networks WiFy module be an option?
It is a little bit more expensive, and requires a configuration step, but you can directly connect using a telnet client with no rooting, and it could be possible to use the HTTP features to create a web page interface, maybe..
For the Android interface, would a Roving Networks WiFy module be an option?
Thanks for the suggestion! We were talking about WiFi options. These are still on the list, but lower down. The bluetooth addresses the need at the moment and is lower power. When the bots go outside and be need the longer range, and have more power available, we will be looking into these. The hope is that by the time we are ready for the next step, the prices will serendipitously plummet, and we can save a few bucks over buying early. I still have boxes of parts that I bought "because they are cool" but did not have a project for, and they remain in the boxes. Management has declared purchases are limited to the thing I am going to immediately use.
But those look wicked! Must... resist... cool ... toys...!
Comments
Ray
The task remaining for 5.3 is updating all the little things. These are all the updates and tweaks to the documentation and examples. There are a bunch.
Sal has cut over to the new automated build procedure. The old "manual" build procedure will not be covered in the documentation, as it is no long used. The capability is still there, if somebody wants to use it, that person will be the guinea pig for that documentation.
More interesting and more useful than the manual build is using the automated procedure to build and test new kernels. Sal plans on covering each of the new kernels and how they are used, and how to create custom kernels. This ability is VERY powerful, most folks don't how to use it or do it. (Me included).
The paged assembler technique is targeted for thorough coverage. Sal has pointed out that the propforth kernel is very small, smaller than any other forth version he has created for various micro controllers. With paged assembler and an SD card we can have virtually unlimited optimizations and routines. We have a very large amount of the prop's memory available for applications. WE should be able to run from scripts off of SD and achive applications of any size. The I/O channels should allw processor power to be scaled according to the application. Very interesting applications should be possible now. The progress on the Little Robot project indicates we might be able to see some results soon.
After we are fully cut over to the automated system and start in on the documentation, we also have the task of bringing forward the previous library of extensions. We discussed whether or not to keep the Hi-Res VGA in Jupiter ACE from Propforth 3.2. The use-case discussed is having for example a Demoboard or C3 running Hi-Res VGA Jupiter ACE, and use this as a terminal to access an array of MCS props. This case was deemed useful. This was my initial goal when I purchased my first prop demo board in 2008, I'm glad we're finally going to achieve this. See? It's only taken 5 years. Like a stream cutting through a mountain, it just takes patience.
Now that the bulk of the development work on Propforth 5.3 is done, there should be no further development on Propforth, we should now concentrate on creating applications. EXCEPT Sal got another idea after looking again at the specs for the Prop 2. So there seems to be ONE MORE new development release in store for propforth.
Preliminary Concept: Propforth 6 will be designed to take advantage of the abilities of the Prop 2 micro controller.
The first plan is to expand on the common interface for the I/O, and create a generic channel, so all IO will be built on this generic channel.
The second plan involves software multitasking. Forth is famous for software multitasking, allowing multitasking on nearly any single hardware thread processor. On the prop 1 software multitasking was implemented and removed, as it cost memory and did not meet any need; we usually have plenty of cogs available. But there are several functions in a cog that operate independently, like counter, timer, freq, etc. On the Prop 2 we will have more memory and can better afford additional stacks for software multitasking. So the plan is to implement software multitasking to allow those functions to happen simultaneously in realtime, with some ability for deterministic execution. We're looking at up to 8 software task threads in a single cog. The developer will still have to recognize which tasks requires a dedicated cog; but for those that tend to be less time critical and have spare time, there will be an ability to take advantage of several parallel functions simultaneously on a single cog. Very cool!
With the Prop 2 faster clock speed and more memory, many things are different.
The faster clock speed means serial could be over a megabit, and MCS could be 5 to 10 times faster. The electrical circuits might not be as simple as now and will require some tweaking, but it looks very promising.
The fast EEPROM (1 cycle) has very big effect: We can put optimized kernel routines in fast memory, and leave the bulk of the RAM available for user applications.
We'll finish up 5.3, and start implementing PF 6 on prop 1 to prepare. The same code should work on either, the Prop2 stuff will just be a little slower on Prop1
http://obex.parallax.com/objects/53/
This FFloat(FloatMath.spin) convert only integer because spin convert fraction(1.65, etc) inside it.
But PropForth have only integer.
I want to convert fraction(1.65, etc) to float-point-form.
I don't know how to convert.
Do you have any ideas?
http://code.google.com/p/propforth/wiki/RPiGoPropforth
If you can give me feedback as to what need fixin' I would appreciate it.
It kind of bombs out at the end using 2012-08-16-wheezy-raspbian.zip
Like I said, its a draft...
Sal has that float.f in the misc directory, did you see that? That and the doublemath.f should handle most of what we usually see, but it might not be the fastest solution.
There's also the scaled integer, that's my favorite as its easier to get more accurate.
What exactly are you trying to do? There might be a nice way to get what you want, with out the pain of software float support.
If I can ever find a couple hours of quiet time, I'll sit down and try this. It looks like well detailed instructions so far.
I'm interested in trying Adafruit's wheezy distro, they've added a bunch of interesting things including support for wifi dongles.
That certainly needs GO talking to a PropForth cluster.
Nice addition to the cause!!
I tested freescale's pressure sensor(MPL115A1)
http://akizukidenshi.com/catalog/g/gI-06078/
To pro_braino.
Where is misc directory in PropForth5.2 .1Beta folder?
I wrote POV's code by using QuickStart board on PropForth4.6.
POV_1.0 is for PropForth5.2.
And POV_1.1 modified a little bit.
Left photo(ZYWXYZ..) is POV_1.0.
Right(IHJK..) is POV_1.1.
Watching mirror-letters because shaking from right to left and from left to right.
To prevent this, next plan is LED-on only one direction.
The final downloadable archive is being prepared for v5.3.
The Little Robot project is continuing to progress. The mechanical design for the chassis is still the critical path. I have some couplers for connecting the steeper shafts to the wheels in test.
I read up on the Trademark symbol (tm). I believe it declares that I am using the Little Robot name to identify this particular unit as coming from the particular source. Anybody else can make something similar, but only this one is the little Robot. Anybody has additional insight to this? I think I just like putting in the (TM).
I started looking at Jamie Mantzel's spider tank robot.
http://www.youtube.com/watch?v=t_AqXCw1SYs
His bot also has 2 motors and four AA batteries. But The Mantzel bot lacks ultrasonic range finder and other sensors, and a capability for processing complex data streams. I think a prop and propforth are called for. I think I can see a Mantzel chassis in the future for the LittleRobot.....
http://www.youtube.com/watch?v=qs-7Muu54-A&feature=plcp
This robot is very interesting.
This use DC-motor? Not servo motor?
One leg has 2 motors?
Or whole 2 motors?
The entire robot has only two DC motors. Its VERY clever. One motor powers all six legs, when the motor is turning, the spider is walking. The second motor only control which direction it the front. The robot's "face" is always the front, when the face changes changes direction, that is the new "front".
This is along the lines of Mark Tilden's [http://www.beam-wiki.org/wiki/Nervous_net_as_the_lowest_layer_in_a_subsumptive_design subsumption architecture]. When the motor is turning, the robot walks, it needs no intervention from the processor. This allows the processor to be used for more interesting purposes or to be absent. Its a cool idea, and propforth possibly fits well.
If you see the Hexbug "spider" it is a copy of this design (but Hexbug did not give credit to the inventor). The Hexbug is $25 here, so its still way over priced. They can be found at Toy 'R Us here, they might have them also by you.
http://www.toysrus.com/product/index.jsp?productId=12003616
1 Loading 2_wire_LCD_sr(8bit)_1.1.f
2 Loading BigFont_1.1.f
3 Loading LCD_demo_1.1.f
Sorry, there isn't 74HC174's power-line in curcuit diagram.
I connect 74HC174's power to +3.3V.
I wrote Wii_Nunchuku at PropForth4.6
I rewrite it for PropForth5.2. Only hex-number(a -> A, b -> B, c -> C, d -> D, e -> E, f -> F)
It's Wii_Nunchuck_0.2.
I checked WORD"test".
Its output datas from Nunchuck.
But error occured.
I checked WORD"_eeread" and "_eewrite" by decompV2A.fth, because I cannot find out code-sources in PropForthDevKernel.f and PropForthStartKernel.f and etc.
These are different from PropForth4.6.
I loaded PropForth4.6's "_eewrite" to WiiNunchuck_0.2.
Error has gone. But datas from Nunchuck are nonsense.
I loaded PropForth4.6's "_eeread" to WiiNunchuck_0.2 too.
Datas from Nunchuck are correct.
I think I mistake how to use PropForth5.2's "_eewrite".
Does anyone know correct using "_eewrite"?
I updated encoder_0.4.
Using 2_wire_LCD_sr(8bit)_1.1
I rename _eewrite and _eereadof PropForth4.6, because _eewrite and _eereadof PropForth5.2 cannot use on Wii_nunchaku.
I have no idea why they cannot use.
Using 2_wire_LCD_sr(8bit)_1.2
1. Download propforth 3.5e http://code.google.com/p/propforth/downloads/detail?name=PropForth3.5e-20101019.zip&can=2&q=
Unzip the archive
2. Find PropForth_hiresvga-demoboard.spin
Load this onto demoboard with proptool
NOTE: vga_hires_text.spin must be present, he uses this! <********
OK, it looks right, I reburn my demo board which has been sitting here happily running JupiterACE 3.5e since 2010-10-07
3. Connect to the prop with teraterm
57600 baud (man, we were slow in the old days!)
New line Recive CR+LR (nowadays we are just CR)
Verify that the propforth command prompt is displayed.
Type Type
You should see something that looks like the commands are doing something. (Technical explanation)
4. Open in a text editor (NOT hiresvga.f, sorry, this is the general case)
Hightlight the whole file, copy and paste into teraterm.
It sits for a minute, then the source code scrolls by as it interprets.
ends with
5. execute the word saveforth
a bunch of dots parade across the screen
6. Plug it into the monitor.....
connect PS2 keyboard
apply power
7. It works!
Type ALT+TAB to switch between screens
Cog3 is running on the Top half
Cog4 is running on the bottom half
Cog6 is running on the USB/serial port
from cog4 or cog6 type
to send a command to another cog's input stream
The only adjustments I made to these instructions were to send PropForth_hiresvga-demoboard.spin to the EEPROM with F11 (replacing BASIC for the time being) and using Hyperterm. Instead of copy/pasting the file, I used the "Send Text File" under the Transfer menu to send the file, hiresvga20100912-0943 fix-demoboard.f.
Pretty slick!
Are there major differences between this version (3.5) and the current 5.0 download?
Jeff
This don't has access-holes for touch-pad, because I don't use them.
>Very Nice.
Thanks!
The forth words and the way they are used is mostly the save. The FORMAT FOR CONSTANTS has changed/is changing; constatnts now require a prefix letter d for decimal, h for hex, and x for 64 bit encoding, to decouple the number base of the source from the changeable number base of the cog running forth.
Along with that, the interfaces are being standardized, its much easier to interface from one task to another, but this is kind of deep and will be a whole section of the docs. From the user point of view there is nothing we have to do except use it.
Also, everything has been / is being optimized for speed and small memory footprint.
The JupiterACE in 5.3 (not released) will be must smaller and faster, but any code you write for 3.5 should work with minimal changes (as described above).
The goal will be a Jupiter ACE running on a demoboard, talking to an array of propchip of arbitrary size, doing arbitrary prop applications, communicating over MCS/Go channels/CSP channels.
I changed mounting arrangement(screws/nuts).
Screws from bottom side. Nuts are surface on case.
If used touchpad, only removing top-plate.
We had one glitch in testing, the SNET test for Spineret/wiznet5100 failed. It turns out that the standard test bed Spinneret MUST have a version of Propforth 5.x installed. Although the test automagically loads the current version under test, the new baud rate setting of 230400 makes it incompatible with the 57600 baud from the pre-v5.x versions. We never implemented auto baud detection, this is the price we pay. However the code is still stable, and I'll upgrade the spineret firmware to PropForthDevKernel.spin and rerun the tests. We should be good to go after it completes successfully.
The next release will include driver source code for servo, steppers, BMP085. Sal is starting in on the hires video support for JupiterACE, this should be the last bit.
We're reworking the release archive and documentation. The plan is to cut over from using the previous version to generate the new kernel, to using the new kernel to generate itself. To the user, everything should look the same from the outside, but internally we have to shuffle some stuff around. Also, we are going to make another stab at proper tutorials. We think we want to start with a set of standard diagnostics (command line, logic analyzer, and possibly debugger) and examples of how to use them. WE also want to present the standard "elemental" activities, set a pin high or low, read a pin state high or low; output a frequency, read a frequency; output PWM, read PWM; and show how to produce/detect these events with the standard diagnostics. These sections will be added to propforth.htm
Back to testing!
I believe "tiny" is just a redundant adjective when describing forth in general. An exception would be something like FPC which is a PC based forth which has about 3000 zillion functions for every possible thing the guys could think of. Which was really cool, but most of the stuff never gets used, so its kind of a waste. And it was too much for me to keep track.
In the case of propforth, the memory foot print keeps getting smaller and resources available to the user for applications keeps increasing. So "tiny" would apply to each kernel compared to the last. Propforth 5.3 will have the smallest memory foot print and most resources available for user applications so far compared to the previous releases. Also, it will be noticeably faster due to optimization of critical functions. The "paged assembler" functions will permit very small optimized functions to be brought in and out of memory on the fly, and is easier to use than previous assembler optimization implementation.
So, the short answer is 5.0 for now, and will be 5.3 when it comes out.
We're starting to talk about client software on android devices.
For example, we talked about putting propforth's software LOGIC ANALYZER UI on android.
Android devices tend to have fairly nice displays, at least compared to the old VGA monitors we had earmarked for prop projects. The question remains on what is the best way to distribute these android apps to be used with propforth. I'm thinking we may be limited to rooted devices, but I'm no android expert. If anybody wants to help with the android parts, please PM me. There are lots of Cortex A8 devices coming out that look like they will be excellent hand held terminals. Currently the tabeo, meep, and nabi can be locally had, I'm thinking after xmas these will be coming down below $100 and with better features.
We're liking the bluetooth modules to interface to the devices.
So the model may be android+bluetooth to propforth+bluetooth.
WE discussed spinneret vs Raspberry Pi. Wiznet or spinneret can be had for $20 to $50. Raspberry Pi can be had for $35 and is WAY better for slightly more power.
From the prop standpoint, bluetooth use much fewer resources and less power. While spineret/wiznet/ethernet will still be present in V5.3, we don't know where it will go moving forward. There doesn't seem to be much a use case for it anymore.
I just learned about marking a cog as "in use" in propfroth.
Turns out Propforth.htm section 9.1.305 has "all the information we need". Unfortunately, it doesn't have any documentation on what the section actually means, so I opened an issue for it.
Turns out, that when the comiler is looking fro a free cog to use, it looks in the state table. To Mark a Cog as USED, turn off Bit 2. If bit 2 is off, compiler doesn;'t try to use it. That explains a lot right there, but I think it needs a little more. Sal will add some words on this to section 6 next release.
My task for the Little Robot(tm) demo is write the getting started guide. I will write the instructions to exercise the Little Robot(tm) functionality, and Sal will write the code that makes it do whatever that is. This may be the first project I've participated in where we do things in the proper order.
WE also started talking about Turtle Graphics and SCRATCH. Previously, we had looked into using 12blocks to talk to propforth (and generate forth code), and even contacted Hanno. There were no technical reasons why it wouldn't work, but that effort was overcome by events. Now it looks like we may a have a chance to pursue this as part of the v5.3 demo development.
This week I'm presenting the Little Robot Demo to a local school. I have two prototypes built, they look really Mad Max. I don't think they will dance by Friday, but they will serve their purpose by simply sitting there and looking cute.
It is a little bit more expensive, and requires a configuration step, but you can directly connect using a telnet client with no rooting, and it could be possible to use the HTTP features to create a web page interface, maybe..
Massimo
Thanks for the suggestion! We were talking about WiFi options. These are still on the list, but lower down. The bluetooth addresses the need at the moment and is lower power. When the bots go outside and be need the longer range, and have more power available, we will be looking into these. The hope is that by the time we are ready for the next step, the prices will serendipitously plummet, and we can save a few bucks over buying early. I still have boxes of parts that I bought "because they are cool" but did not have a project for, and they remain in the boxes. Management has declared purchases are limited to the thing I am going to immediately use.
But those look wicked! Must... resist... cool ... toys...!
http://forums.parallax.com/showthread.php?139378-Remote-propeller-control-with-WiFi-module...-at-this-point-I-have-to-learn-Forth