I have received the Propeller Quickstart Board
Intalled the propforth 5.0 on it, and it running!
Impressed version!
Two questions about it for now:
1. Where do I store the forth RAM or EEPROM
2. When I install some words, and turn the propeller off what to do, so when I plug in again the new words are available without loading again?
The word "saveforth" writes the current visible definition for each word to upper 32K of 64K EEPROM.
IF using the SD version, the model is to boot the kerenl, and load definitions from SD. The saveforth will work with SD in a later version, but for now don't using it as it sometimes messes with the way the reset and onreset words are used.
Please post any questions about the documentation. We can add anything that is lacking, or revise any parts that are unclear. We want lots of feedback to make it better.
I managed to spend a little bit more time on the decompiler and have uploaded V2.1 which does a pretty good job of pulling apart the guts of each definition in such as way that without any editing you can copy and paste the source back in again.
Changelog:
Updated V2 to include:
- Proper ." and c" constructs
- Adding any immediate and exec attributes to end of definition
- Improving indentation and formatting
- Prefixed literal numbers with h as hex for anything greater than 9
- Decompiles constants and variables to source code form
In fact, the aim is to as far as it is possible to present all output in a ready to paste source code form.
Easter egg: what happens if you tell it to decompall <something> or nothing ????
Escape key stops decompilation at the end of a word and the space key pauses/resumes
To do: Check and fix formatting of cog assembly code related words although this is not important at present.
The 5.3 (pre) release continues to appear stable. There are minor details with the new regression test automation that are being ironed out. Most of it has to do with the way the automation parameters interrelate, we will try to get these ironed out and documented before release.
Sal is sending me HC05 and HC06 bluetooth modules, we are going to see how we want to include these in the release. Probably as an extension/configuration option, since not all folks will have these. I should have these in hand next week.
We talked about Pete's decompiler. Sal thought nobody was using the decompiler since 3.x (he doesn't anymore) so left it out (due to test time) in favor of focus on kernel development; the automation will allow bring this and all the other existing extensions up to the current version. We will be using Peter's input when we re-include the decompiler, and maybe Peter will be able to help with the documentation and instructions.
Sal reminded me that the timing changes kuroneko pointed out in version 4 caused a change between the assembler version v1.0 and v1.2 material, so some of the older material will have errors when used with the new material. We will attempt to nail down what is weird by design and what are errors to be corrected with Peter and Caskaz etc when we get closer to release.
We are looking towards an example application to show off MCS/Go-channels (previously refereed to as CSP-channels) capabilities. We're looking at some kind of moving robot. I'm looking at something with Inertial Navigation abilities. Sal mentioned "balloon drop" experiments from the ham radio guys; maybe we will send a bot up on a balloon and make it fly home. Another option is a autonomous biped. The target is something overwhelmingly cool that a lot of folks can try, we're open to suggestions.
Why is char and [char] not implemented in propforth?
Sal's "rule of thumb" for the kernel is "minimum necessary and sufficient to get the job done". Since RAM is at premium, most forth functions are NOT included in the kernel beyond the basics. All we want is read memory, write memory, and jump to a routine; then some support for the dictionary; then the interpreter; then some development words; then it starts getting out of hand and we run out of memory. So we stop adding to the kernel when we can recompile, we have a whole bunch of memory open to us.
THAT being said, the kernel is very small, if you need the char words, you can (a) implement them yourself using the C@ C! words, or (b) just use the C@ C! words. We can help and certainly would add the results to the library.
AND, the extensions can loaded from SD, or the entire application can be executed as a series of scripts run from the SD, so the application can be as large as you SD card. One just has to get used to thinking in terms of scripts loaded from SD, which can be a little weird at first, but usually has been doable.
What do you have in mind? What is your application and how does it need these words, what is the exact function you are looking to achieve? We might be ale to come up with a solution that does not cost too much memory footprint.
I was working on a ANSI escape sequence to communicate with my VT100 terminal program on my IMac.
As working with the ansi forth I alway use the words in a word like " [char] [" .......
Thats the reason for my question.
I will need the VT100 for interfacing. I have a lot of arduino add on boards, and will them use with the propellor chip.
I will buy a Propeller ASC+ board so I can try to get these running with the propeller. SYNERGY!!!!
I know that there is a ansi escape file, but have some trouble with some words!, As I can see it was written for the prop forth 4.0.
Jan, not having a particular operator in another language would be a reason to cry poor but that is never the case with Forth as you should know. Isn't it a dead simple definition to code on one small line and use it exactly as you would like? Rather than a construct such as "char [" for instance I have even extended the number processing (not yet in PropForth) which as you know is where the buck stops after the dictionary is searched and a word is not found. I have added prefixes such as ' and ^ to be used like this:
^C ...............the preceding ^ denotes that this this is a "control C" and should be encoded as a literal 03. ........ Example: fkey? and ^C = if exit then
'[' ...........Where the ' as prefix of an undefined word implies that the following character be taken as an ASCII literal and encoded as literal h5B . .......Example: '[' emit
However without too much ado you can create a "char" definition, but I will let you think about that for five seconds before you ask for help
I was working on a ANSI escape sequence to communicate with my VT100 terminal program on my IMac.
As working with the ansi forth I alway use the words in a word like " [char] [" .......
Thats the reason for my question.
Oh THAT char! The ANSI TERMINAL CODES are already on the wiki pages. They should be up to date for v5.0
Please give those a look. They are loaded as an extension are not part of the default kernels.
I'm on phone or i'd send link
Edit- edit - the previously linked version was out of date and has been deprecated
Of course, that version was for 4.0, and since then we made a change.
Starting at v5.0 HEX numbers can be designated by the prefix "h_"
This is due to each cog and task having its own BASE variable, the cog loading the text could be set to a different BASE (hex, deimal, binary octal, anything) than the cog interpreting the text, and it made us crazy. So we decided just assume everything is decimal, and prefix hex values with "h_", and prefix 63 bit values with "x_"
Try this version it should work a little better. At least it worked with teraterm
Oh THAT char! The ANSI TERMINAL CODES are already on the wiki pages. They should be up to date for v5.0
Please give those a look. They are loaded as an extension are not part of the default kernels.
Propforth 5.03 has been downloaded 103 times since May 6th release
Average is still above 1 download per day, although it had sustained 3.5 downloads per day at peak.
The development team has 11 listed contributors, although there at least four folks awaiting in the wings that might be joining soon.
Next release should be 5.3 in a couple weeks and include the test automation, which should lead quicker release of custom kernels, and all the previous extensions being brought up to v5.x compatibility.
This is an excellent time to download the archive and start in on the propforth.html user guide. We think we are moving out of the kernel development phase and into the application development phase.
When multiple terminals are open and commands are executed the results are send to the console for logging. The since the cogs are running at slightly different times compared to the PC, the results from each terminal session may arrive at the PC in a different order each time. This causes a complication, as our check is whether or not the current run logfile is identical to the previous run's logfile. Anything not identical must be checked manually for errors. Having to manually check something that is correct just not in the same order, defeats the point of automated testing.
We're trying to figure a nice way to deal with this. Making the automating smart enough to recognize the parts are correct although in a different order is a bunch of work, and would have to be maintained. Sal is looking for other ways to make the concurrent tests behave, such as adjusting certain timing. I ask on another thread if the community at large can offer insight to concurrent test automation.
I received the $6.44 Bluetooth modules, one each of HC05 and HC06. They require 5 wires to program (3.3v, GND, control, Rx Tx), and four wires for normal operation (3.3v, GND, Rx Tx). There can be hung off pins 30 and 31, or we can change the prop Tx and RX lines in the spin code and use any other pins. They are very easy to set up, but I don't have a Bluetooth terminal on the android phone yet (I would appreciate if someone can suggest a good android app for a Bluetooth terminal program). Set up on the PC was faily easy, although the PC display Bluetooth comports 15, 16, and 17, when comport 16 is the one that works. Might be something with the way the WXP handed the drivers.
The last issue with 5.3 release is not anything to do with the propforth kernel. The final issue being worked is determining how to handle concurrency testing. We require that all "correct" tests produce identical results each time the test is executed on the same code. Otherwise the user has to manually check the results, which defeats the purpose of automation. So far there are two cases where this has not been possible, in the case of time stamps (which obviously always advance), and in the case of undefined pin states (which always flop around between tests) in the logic analyzer tests.
In the concurrency tests, particularly when the a cog is reset due to a stack over or under flow, a message is sent to the "console" (cog 6) since the cog under test is reset and can't display the message. The design decision was to make this a "best attempt" message, sometimes the reset happens before the message gets out. This message is defined as a"debug" message rather than a diagnostic, so we only care about this during this specific test anyway.
The choice was to either (a) re-design the kernel to allow the console message to be a diagnostic message that ALWAYS gets out (and slow down the system and increase kernel footprint), or (b) leave it as a "manually check" test. We decided to leave it as "manually check" to keep things fast and small. We will just run the test a number of times, and the user can check that the message was displayed at least once. The concurrency tests will be grouped with the other "manually check" tests, so the price is small, and at least they are all in one place.
The propforth 5.3 kernel itself has proven to be very stable so far. Sal's "laser diode on a servo" test rig has been running pretty much 24/7 for around 90 days (except when he kicks the power strip and has to plug it back in again). The red dot moves from the tape mark on the middle of the ceiling to the tape mark on middle of the wall, and back again. It looks like the motion is exactly repeatable every time. [Note: Demonstrate 90 days stability is required prior to release, Sal's rule.] Hurray for small victories!
Test Automation rocks. The entire rebuild-regression-check cycle takes about 3 hours total now, when including the start up and manual checking. This is down from a couple weeks with lots of babysitting the tests during execution. The current test process now looks like:
write the code, drivers application, etc.
write the tests that exercise the required functions
Run the tests that exercise the functions, until sure that the results are correct and repeatable.
Add the new tests to the regression suite
run the regression suite
In about three hours, we should know if there are any bugs in the system or not. If no bugs are found, there still may be bugs, but all system functions have executed correctly; so there's a good chance that no one will care about bugs that can't be detected. Of course everyone will still report all bugs they find, and we will attempt to add new tests for those.
The test automation process should be straight forward enough for regular users to apply to their own development projects. Any user regression tests can also be submitted to the main (Sal's) regression test set which will be included in the download archive.
Today's call:
Sal's continuing stability tests. All the variances are limited to three files (of around 25) that need operator verification, all others will be an exact match when no errors are found.
Possible error: In a set of ten runs the automation detected a spurious character. There was one case where a space character came out as an underscore. We don't know if this a bug or a gamma ray or something else. The bits should be 100 0000 but were 1011111, could external interference cause this? Maybe somebody kicked the wire....
Sal's is also testing the logging. He's adding a sensor, writing a driver, and logging the readings to an SD at around once per second. The data consumes practically nothing of the SD card, so he's adding more sensors and higher logging rates.
We've gotten confirmation that our Raspberry Pi orders have been accepted, we are looking to use RPi as the simplest linux system in our development/test bed. Once we get the test automation running on linux we can check for differences between Windows and linux.
We're still working on a demo to show off the capabilities of the next release. Our design parameters are that the hardware must be simple enough that anyone can try it, but allow for an insane amount of processing and sensors. It should end up cheaper than the cheapest and more powerful than the most powerful (it should do the same functions at 1/10th the cost). Obviously we might fall short of these goals, but it will be fun to see how close we get. So far, the Model 1 has the potential to provide both low cost and processing power. We want to keep the parts under $20. So we're starting with a small, cheap mobile unit that can be expanded. We think 1 to 3 props via MCS plus blue tooth to a smartphone or PC fits this (we would count the cost of the smart phone or PC in the project cost). So far we have a couple stepper motors, an ultrasonic sensor, and maybe a servo added to our prop + eeprom + regulator + crystal. The rest of the bot can be printed on a 3D printer, or carved from wood or molded from play-dough at the user's preference.
V5.3 is almost ready to send out. Most issues have been addressed. If no new issues present themselves we may see the release next week. Everything seems stable so the likelihood is good.
Sal is bringing forward the various extensions and packages, and adding appropriate tests. At some point will may divide the release into Kernel and Extensions parts; for now it looks like everything will continue to be in one downloadable archive.
We're working towards the demo that will show off the abilities of v5.3. We're still looking at a "cheapest possible" mobile platform as a starting option. The cost we're considering is JUST the parts one has to order, we're assuming each person already has a favorite micro controller, and each person can 3D print or harvest the wheels, chassis, etc. I still like the "ball-bot" or "football-bot" design. Looks like we'll be starting with 1 senor and 1 communications option. The design should allow upgrades and improvements, for faster motors bigger batteries, more sensors, etc, constrained only by the individual's budget.
Hi.
I made pulse-monitor for dog.
I wanted to get pulse when dog walking.
But this infrared light reflector cannot get steady pulse for walking dog.
It can get pulse when dog keep still.
I tried to get pulse from dog's leg. Not dog-ear, she dislike touching ear.
But leg's blood vessel is deep than humans fingertip's capillary vessel.
Its signal is weak and its area is narrow.
So it miss to get pulse when dog moving.
(This can monitor steadily human-pulse.)
I think to try monitoring heart-rate for dog.
Maybe I think code is almost usable.
I think it need to make amp-curcuit for heart-rate.
I see some words that are affected to the I2C, the eeprom words,
but are not sure if I can use these!
Is there pehaps an example how to connect the realtime clock?
But there are zillions. Best might be a recent tutorial from a university. Really, the best way is start simple, blink and LED, send and recieve serial, try to run the tutorial/regression tests included in the download. These last show proper use of every known function in propforth.
Ask many simple questions on this thread or start new ones in the forum, most everybody is nice and will try to help.
Since the start of the test automation release, there have been NO bugs in the kernel. All issues have been with the automation itself, and these have been resolved. We may get something next week. The only thing that has remained an open questin was a spurious character in the IP test for spinneret. Actually it was two spurious characters in the course of many test runs, so there may be a bug in the IP code that we cannot repeat on demand. However, Sal says his test bench is a total mess and the spurious character may well have been generated by EM interference. Sal is going to bite the bullet and clean up the area and see if the issue still happens before Friday.
Thanks to the automation, Sal is adding more cutom kernel options. There's now an IP kernel, and and EEPROM IP kernel. These have already been implemented, have passed testing, and are added to the standard package. Just need to remove/rearrange the old stuff, this should be simple.
However, the release docs may take some time. There's two aspects -
1) "threshold" documentation - enough for somebody to understand "what was done"
2) educating folks on "what it is"
It boils down to "who is the target audience?" Is the audience limited to advanced users like Peter and Kaz? Or is there another audience that includes Braino's kids, their classmates, and the parents? The docs have to be written for the specific audience(s).
Documentation for the next release: The thought is now to include an example for using the cheap stepper motor in the ball bot. Starting with the data sheets for the P8X32A and the ULM2003 (this is the chip that comes with the $3.00 stepper), we plan to walk through and document the iterations of defining the functions, designing the program, designing the tests, implementing the code in high level forth, debugging the tests, implementing acceleration ramping, and optimizing the code in assembler. A single afternoon's play. One end to end example should cover just about everything, but will this be sufficient to teach someone to use v5.3? Let the experiment begin!
Ball bot demo: Still sticking to the "minimum necessary and sufficient" for a "lowest cost" project idea, to make it accessible to more folks. So far we only need
- Prop
- regulator - 3.3v
- EEPROM
- 10k resistor pack for pull ups
- crystal
- capacitor
- Blue tooth
- Steppers
- ultrasonic
And the price is still below $20 for the parts. The decision is to NOT add SD at this time (MUST...RESIST...ADDING...FEATURES....). However, the 10k resistor pack is already there, so SD can be added as any time using http://code.google.com/p/propforth/wiki/PropToSDconnection
Talked about Brian's find http://forums.parallax.com/showthread.php?141653-Getting-More-From-Your-EEPROM-Slot http://www.mouser.com/ProductDetail/Atmel/AT24C1024B-PU25/?qs=j6lVIf5KywDc%2bnjW4IKuatbmz45vTZgV
I was already to design it into the ball bot, Sal stopped and looked at the numbers.
Turns out there is a trade off to consider here. The AT24C1024 costs under $3.00 while and SD costs about $4 and up. So if the absolute MAX memory that will ever be needed is under 128k and low cost is critical, then the AT24C1024 is the way to go. BUT the cost per bit is is orders of magnitude cheaper for SD, and SD throughput is about an order of magnitude faster. Also, the prop isn't fast enough to choke SD class 4, and probably SD class 2 is fine unless the SD kernel gets optimized (no plans/need at this time). So for the ball bot, we can go for whatever EEPROM is cheapest and easiest. Since the next phase of the project includes logging and environment modeling, much more than 128k will be needed. When we want more memory, the data indicates SD.
Talked about Raspberry Pi: RPi is to be the reference linux installation for regression testing. Sal got his Raspberry Pi, installed Raspian wheezy, downloaded and compiled GO (about 45 minutes) using plain standard Linux instructions. RPi's running headless (no monitor, using secure shell [ssh] and working from a command line on a window on his regular PC) since an HDMI cable costs more than the Pi. There's still some issues, like how to find out the RPi's DNS assigned IP address so we can start headless from an image, but this will get worked out shortly.
Prof: re the R-Pi, I have found the MK802 on eBay comes with cables etc and is wireless and has a base (USB style dongle), all for about $65. Make sure you get the 1GB 1.5GHz version for the few extra $ over the 512MB 1GHz version. I have not bought or tried this, but it seems to me to be even better value than the RPi, given its specs - unless you need I/O !
I am interested in your minimum specs prop. I presume the bluetooth is for downloading???
I found the Tamiya Double Gearbox an interesting find. Add 2 wheels (maybe some way to use plastic lids?) and a ball. Add a 2 or 3 x AA battery compartment ($1 on eBay). I built a simple pcb that fits on top using a driver chip and a cheap ATTiny just to run the motors (have not had time to load/test the pcb). Makes an extremely cheap way to get into this thing. Later, add a prop to get more functions.
Thanks, but price is too high, and it doesn't fit the spec of "must be as popular and ubiquitous as R-Pi".
I am interested in your minimum specs prop. I presume the bluetooth is for downloading???
PF uses blue tooth HC05/HC06 as cable replacement. If the voltage goes too low (whem 4 AA runs out) the BT association can get lost, otherwise its same as cable. So PC can download, we are using a GO application to load the prop via propellant (I think). Whatever it is it works great.
I found the Tamiya Double Gearbox an interesting find. Add 2 wheels (maybe some way to use plastic lids?) and a ball. Add a 2 or 3 x AA battery compartment ($1 on eBay). I built a simple pcb that fits on top using a driver chip and a cheap ATTiny just to run the motors (have not had time to load/test the pcb). Makes an extremely cheap way to get into this thing. Later, add a prop to get more functions.
We're doing similar with the cheap steppers, but anything will work. The DC motors could be run directly from the prop(s), if a configuration is popular it would be easy to port to it, just adding new drivers. The goal is something everybody can afford, we are just going with this particular set of parts as a starting point.
We also plan to add more props and sensors etc once we find a hardware set that catches on. The plan is to work up to a copter etc if the community interest is there. But one step at a time for now.
Comments
I have received the Propeller Quickstart Board
Intalled the propforth 5.0 on it, and it running!
Impressed version!
Two questions about it for now:
1. Where do I store the forth RAM or EEPROM
2. When I install some words, and turn the propeller off what to do, so when I plug in again the new words are available without loading again?
Thanks for anny help.
Jan Kromhout
Hellevoetsluis-NL
Cheers,
Jan
The word "saveforth" writes the current visible definition for each word to upper 32K of 64K EEPROM.
IF using the SD version, the model is to boot the kerenl, and load definitions from SD. The saveforth will work with SD in a later version, but for now don't using it as it sometimes messes with the way the reset and onreset words are used.
Please post any questions about the documentation. We can add anything that is lacking, or revise any parts that are unclear. We want lots of feedback to make it better.
Cheers!
Changelog:
Why is char and [char] not implemented in propforth?
Cheers
The 5.3 (pre) release continues to appear stable. There are minor details with the new regression test automation that are being ironed out. Most of it has to do with the way the automation parameters interrelate, we will try to get these ironed out and documented before release.
Sal is sending me HC05 and HC06 bluetooth modules, we are going to see how we want to include these in the release. Probably as an extension/configuration option, since not all folks will have these. I should have these in hand next week.
We talked about Pete's decompiler. Sal thought nobody was using the decompiler since 3.x (he doesn't anymore) so left it out (due to test time) in favor of focus on kernel development; the automation will allow bring this and all the other existing extensions up to the current version. We will be using Peter's input when we re-include the decompiler, and maybe Peter will be able to help with the documentation and instructions.
Sal reminded me that the timing changes kuroneko pointed out in version 4 caused a change between the assembler version v1.0 and v1.2 material, so some of the older material will have errors when used with the new material. We will attempt to nail down what is weird by design and what are errors to be corrected with Peter and Caskaz etc when we get closer to release.
We are looking towards an example application to show off MCS/Go-channels (previously refereed to as CSP-channels) capabilities. We're looking at some kind of moving robot. I'm looking at something with Inertial Navigation abilities. Sal mentioned "balloon drop" experiments from the ham radio guys; maybe we will send a bot up on a balloon and make it fly home. Another option is a autonomous biped. The target is something overwhelmingly cool that a lot of folks can try, we're open to suggestions.
Sal's "rule of thumb" for the kernel is "minimum necessary and sufficient to get the job done". Since RAM is at premium, most forth functions are NOT included in the kernel beyond the basics. All we want is read memory, write memory, and jump to a routine; then some support for the dictionary; then the interpreter; then some development words; then it starts getting out of hand and we run out of memory. So we stop adding to the kernel when we can recompile, we have a whole bunch of memory open to us.
THAT being said, the kernel is very small, if you need the char words, you can (a) implement them yourself using the C@ C! words, or (b) just use the C@ C! words. We can help and certainly would add the results to the library.
AND, the extensions can loaded from SD, or the entire application can be executed as a series of scripts run from the SD, so the application can be as large as you SD card. One just has to get used to thinking in terms of scripts loaded from SD, which can be a little weird at first, but usually has been doable.
What do you have in mind? What is your application and how does it need these words, what is the exact function you are looking to achieve? We might be ale to come up with a solution that does not cost too much memory footprint.
As working with the ansi forth I alway use the words in a word like " [char] [" .......
Thats the reason for my question.
I will need the VT100 for interfacing. I have a lot of arduino add on boards, and will them use with the propellor chip.
I will buy a Propeller ASC+ board so I can try to get these running with the propeller. SYNERGY!!!!
I know that there is a ansi escape file, but have some trouble with some words!, As I can see it was written for the prop forth 4.0.
Cheers,
Jan
^C ...............the preceding ^ denotes that this this is a "control C" and should be encoded as a literal 03. ........ Example: fkey? and ^C = if exit then
'[' ...........Where the ' as prefix of an undefined word implies that the following character be taken as an ASCII literal and encoded as literal h5B . .......Example: '[' emit
However without too much ado you can create a "char" definition, but I will let you think about that for five seconds before you ask for help
Oh THAT char! The ANSI TERMINAL CODES are already on the wiki pages. They should be up to date for v5.0
Please give those a look. They are loaded as an extension are not part of the default kernels.
I'm on phone or i'd send link
Edit- edit - the previously linked version was out of date and has been deprecated
Starting at v5.0 HEX numbers can be designated by the prefix "h_"
This is due to each cog and task having its own BASE variable, the cog loading the text could be set to a different BASE (hex, deimal, binary octal, anything) than the cog interpreting the text, and it made us crazy. So we decided just assume everything is decimal, and prefix hex values with "h_", and prefix 63 bit values with "x_"
Try this version it should work a little better. At least it worked with teraterm
http://code.google.com/p/propforth/downloads/detail?name=ANSI%20Escape%20Sequences20120704-1652.f&can=2&q=
Average is still above 1 download per day, although it had sustained 3.5 downloads per day at peak.
The development team has 11 listed contributors, although there at least four folks awaiting in the wings that might be joining soon.
Next release should be 5.3 in a couple weeks and include the test automation, which should lead quicker release of custom kernels, and all the previous extensions being brought up to v5.x compatibility.
This is an excellent time to download the archive and start in on the propforth.html user guide. We think we are moving out of the kernel development phase and into the application development phase.
The main issue in 5.3 is concurrent testing.
When multiple terminals are open and commands are executed the results are send to the console for logging. The since the cogs are running at slightly different times compared to the PC, the results from each terminal session may arrive at the PC in a different order each time. This causes a complication, as our check is whether or not the current run logfile is identical to the previous run's logfile. Anything not identical must be checked manually for errors. Having to manually check something that is correct just not in the same order, defeats the point of automated testing.
We're trying to figure a nice way to deal with this. Making the automating smart enough to recognize the parts are correct although in a different order is a bunch of work, and would have to be maintained. Sal is looking for other ways to make the concurrent tests behave, such as adjusting certain timing. I ask on another thread if the community at large can offer insight to concurrent test automation.
I received the $6.44 Bluetooth modules, one each of HC05 and HC06. They require 5 wires to program (3.3v, GND, control, Rx Tx), and four wires for normal operation (3.3v, GND, Rx Tx). There can be hung off pins 30 and 31, or we can change the prop Tx and RX lines in the spin code and use any other pins. They are very easy to set up, but I don't have a Bluetooth terminal on the android phone yet (I would appreciate if someone can suggest a good android app for a Bluetooth terminal program). Set up on the PC was faily easy, although the PC display Bluetooth comports 15, 16, and 17, when comport 16 is the one that works. Might be something with the way the WXP handed the drivers.
The last issue with 5.3 release is not anything to do with the propforth kernel. The final issue being worked is determining how to handle concurrency testing. We require that all "correct" tests produce identical results each time the test is executed on the same code. Otherwise the user has to manually check the results, which defeats the purpose of automation. So far there are two cases where this has not been possible, in the case of time stamps (which obviously always advance), and in the case of undefined pin states (which always flop around between tests) in the logic analyzer tests.
In the concurrency tests, particularly when the a cog is reset due to a stack over or under flow, a message is sent to the "console" (cog 6) since the cog under test is reset and can't display the message. The design decision was to make this a "best attempt" message, sometimes the reset happens before the message gets out. This message is defined as a"debug" message rather than a diagnostic, so we only care about this during this specific test anyway.
The choice was to either (a) re-design the kernel to allow the console message to be a diagnostic message that ALWAYS gets out (and slow down the system and increase kernel footprint), or (b) leave it as a "manually check" test. We decided to leave it as "manually check" to keep things fast and small. We will just run the test a number of times, and the user can check that the message was displayed at least once. The concurrency tests will be grouped with the other "manually check" tests, so the price is small, and at least they are all in one place.
The propforth 5.3 kernel itself has proven to be very stable so far. Sal's "laser diode on a servo" test rig has been running pretty much 24/7 for around 90 days (except when he kicks the power strip and has to plug it back in again). The red dot moves from the tape mark on the middle of the ceiling to the tape mark on middle of the wall, and back again. It looks like the motion is exactly repeatable every time. [Note: Demonstrate 90 days stability is required prior to release, Sal's rule.] Hurray for small victories!
Test Automation rocks. The entire rebuild-regression-check cycle takes about 3 hours total now, when including the start up and manual checking. This is down from a couple weeks with lots of babysitting the tests during execution. The current test process now looks like:
In about three hours, we should know if there are any bugs in the system or not. If no bugs are found, there still may be bugs, but all system functions have executed correctly; so there's a good chance that no one will care about bugs that can't be detected.
The test automation process should be straight forward enough for regular users to apply to their own development projects. Any user regression tests can also be submitted to the main (Sal's) regression test set which will be included in the download archive.
I find that SENA BTerm (Pro) in combination with A.I.type keyboardPlus works in communicating
with PropForth using an Android tablet.
NickL
Are you using the same HC05 and HC06 modules?
Sal's continuing stability tests. All the variances are limited to three files (of around 25) that need operator verification, all others will be an exact match when no errors are found.
Possible error: In a set of ten runs the automation detected a spurious character. There was one case where a space character came out as an underscore. We don't know if this a bug or a gamma ray or something else. The bits should be 100 0000 but were 1011111, could external interference cause this? Maybe somebody kicked the wire....
Sal's is also testing the logging. He's adding a sensor, writing a driver, and logging the readings to an SD at around once per second. The data consumes practically nothing of the SD card, so he's adding more sensors and higher logging rates.
We've gotten confirmation that our Raspberry Pi orders have been accepted, we are looking to use RPi as the simplest linux system in our development/test bed. Once we get the test automation running on linux we can check for differences between Windows and linux.
We're still working on a demo to show off the capabilities of the next release. Our design parameters are that the hardware must be simple enough that anyone can try it, but allow for an insane amount of processing and sensors. It should end up cheaper than the cheapest and more powerful than the most powerful (it should do the same functions at 1/10th the cost). Obviously we might fall short of these goals, but it will be fun to see how close we get. So far, the Model 1 has the potential to provide both low cost and processing power. We want to keep the parts under $20. So we're starting with a small, cheap mobile unit that can be expanded. We think 1 to 3 props via MCS plus blue tooth to a smartphone or PC fits this (we would count the cost of the smart phone or PC in the project cost). So far we have a couple stepper motors, an ultrasonic sensor, and maybe a servo added to our prop + eeprom + regulator + crystal. The rest of the bot can be printed on a 3D printer, or carved from wood or molded from play-dough at the user's preference.
V5.3 is almost ready to send out. Most issues have been addressed. If no new issues present themselves we may see the release next week. Everything seems stable so the likelihood is good.
Sal is bringing forward the various extensions and packages, and adding appropriate tests. At some point will may divide the release into Kernel and Extensions parts; for now it looks like everything will continue to be in one downloadable archive.
We're working towards the demo that will show off the abilities of v5.3. We're still looking at a "cheapest possible" mobile platform as a starting option. The cost we're considering is JUST the parts one has to order, we're assuming each person already has a favorite micro controller, and each person can 3D print or harvest the wheels, chassis, etc. I still like the "ball-bot" or "football-bot" design. Looks like we'll be starting with 1 senor and 1 communications option. The design should allow upgrades and improvements, for faster motors bigger batteries, more sensors, etc, constrained only by the individual's budget.
I made pulse-monitor for dog.
I wanted to get pulse when dog walking.
But this infrared light reflector cannot get steady pulse for walking dog.
It can get pulse when dog keep still.
I tried to get pulse from dog's leg. Not dog-ear, she dislike touching ear.
But leg's blood vessel is deep than humans fingertip's capillary vessel.
Its signal is weak and its area is narrow.
So it miss to get pulse when dog moving.
(This can monitor steadily human-pulse.)
I think to try monitoring heart-rate for dog.
Maybe I think code is almost usable.
I think it need to make amp-curcuit for heart-rate.
LCD:T18003T01 controller:ST7735R
Photo reflector:ITR8307/TR8
rtc:DS1337
ope-amp:LMC6482
Is there an I2C interface for Propforth?
I see some words that are affected to the I2C, the eeprom words,
but are not sure if I can use these!
Is there pehaps an example how to connect the realtime clock?
Thanks again for any help.
Cheers
Jan Kromhout
Hellevoetsluis-NL
Please check DPM_2_rtc.f inside DPM_v2.2.zip.
It use i2c-interface- rtc(DS1337).
Edit any text file on any editor on the PC.
Forth definitions are in the form of:
Where WORD-NAME is the new function you wish to define, and "word" is any for word you wish to call.
Forth definitions start with colon : and end with semi-colon ;
Forth scripts are just the words you wish to call
Remember to put values on the stack before cal the word that needs them.
This is my basic list. The Leo Brode books are the traditional starting point.
http://code.google.com/p/propforth/wiki/FORTHGeneralRefeneces
But there are zillions. Best might be a recent tutorial from a university. Really, the best way is start simple, blink and LED, send and recieve serial, try to run the tutorial/regression tests included in the download. These last show proper use of every known function in propforth.
Ask many simple questions on this thread or start new ones in the forum, most everybody is nice and will try to help.
Realtime clock code is in spineret tests
..\Propforth-v5.x-yyymmdd\kernels\doc\tutorials\ tutorial-6.1 RTC.txt
Nick made some notes from 4.5 in the downloads and on the wiki, these should mostly still apply
http://code.google.com/p/propforth/downloads/detail?name=C3SPI.rtf&can=2&q=
http://code.google.com/p/propforth/downloads/detail?name=PF_SPI.rtf&can=2&q=
Ask specific questions here. Everybody will try to help.
I use OMRON model HR-100C. It reads heart rate on human while running etc.
Don't know how you might use it with a dog; Shaving the fur on her ribs?
The thread is at http://forums.parallax.com/showthread.php?141653-Getting-More-From-Your-EEPROM-Slot
Since the start of the test automation release, there have been NO bugs in the kernel. All issues have been with the automation itself, and these have been resolved. We may get something next week. The only thing that has remained an open questin was a spurious character in the IP test for spinneret. Actually it was two spurious characters in the course of many test runs, so there may be a bug in the IP code that we cannot repeat on demand. However, Sal says his test bench is a total mess and the spurious character may well have been generated by EM interference. Sal is going to bite the bullet and clean up the area and see if the issue still happens before Friday.
Thanks to the automation, Sal is adding more cutom kernel options. There's now an IP kernel, and and EEPROM IP kernel. These have already been implemented, have passed testing, and are added to the standard package. Just need to remove/rearrange the old stuff, this should be simple.
However, the release docs may take some time. There's two aspects -
1) "threshold" documentation - enough for somebody to understand "what was done"
2) educating folks on "what it is"
It boils down to "who is the target audience?" Is the audience limited to advanced users like Peter and Kaz? Or is there another audience that includes Braino's kids, their classmates, and the parents? The docs have to be written for the specific audience(s).
Documentation for the next release: The thought is now to include an example for using the cheap stepper motor in the ball bot. Starting with the data sheets for the P8X32A and the ULM2003 (this is the chip that comes with the $3.00 stepper), we plan to walk through and document the iterations of defining the functions, designing the program, designing the tests, implementing the code in high level forth, debugging the tests, implementing acceleration ramping, and optimizing the code in assembler. A single afternoon's play. One end to end example should cover just about everything, but will this be sufficient to teach someone to use v5.3? Let the experiment begin!
Ball bot demo: Still sticking to the "minimum necessary and sufficient" for a "lowest cost" project idea, to make it accessible to more folks. So far we only need
- Prop
- regulator - 3.3v
- EEPROM
- 10k resistor pack for pull ups
- crystal
- capacitor
- Blue tooth
- Steppers
- ultrasonic
And the price is still below $20 for the parts. The decision is to NOT add SD at this time (MUST...RESIST...ADDING...FEATURES....). However, the 10k resistor pack is already there, so SD can be added as any time using
http://code.google.com/p/propforth/wiki/PropToSDconnection
Talked about Brian's find
http://forums.parallax.com/showthread.php?141653-Getting-More-From-Your-EEPROM-Slot
http://www.mouser.com/ProductDetail/Atmel/AT24C1024B-PU25/?qs=j6lVIf5KywDc%2bnjW4IKuatbmz45vTZgV
I was already to design it into the ball bot, Sal stopped and looked at the numbers.
Turns out there is a trade off to consider here. The AT24C1024 costs under $3.00 while and SD costs about $4 and up. So if the absolute MAX memory that will ever be needed is under 128k and low cost is critical, then the AT24C1024 is the way to go. BUT the cost per bit is is orders of magnitude cheaper for SD, and SD throughput is about an order of magnitude faster. Also, the prop isn't fast enough to choke SD class 4, and probably SD class 2 is fine unless the SD kernel gets optimized (no plans/need at this time). So for the ball bot, we can go for whatever EEPROM is cheapest and easiest. Since the next phase of the project includes logging and environment modeling, much more than 128k will be needed. When we want more memory, the data indicates SD.
Talked about Raspberry Pi: RPi is to be the reference linux installation for regression testing. Sal got his Raspberry Pi, installed Raspian wheezy, downloaded and compiled GO (about 45 minutes) using plain standard Linux instructions. RPi's running headless (no monitor, using secure shell [ssh] and working from a command line on a window on his regular PC) since an HDMI cable costs more than the Pi. There's still some issues, like how to find out the RPi's DNS assigned IP address so we can start headless from an image, but this will get worked out shortly.
I am interested in your minimum specs prop. I presume the bluetooth is for downloading???
I found the Tamiya Double Gearbox an interesting find. Add 2 wheels (maybe some way to use plastic lids?) and a ball. Add a 2 or 3 x AA battery compartment ($1 on eBay). I built a simple pcb that fits on top using a driver chip and a cheap ATTiny just to run the motors (have not had time to load/test the pcb). Makes an extremely cheap way to get into this thing. Later, add a prop to get more functions.
Thanks, but price is too high, and it doesn't fit the spec of "must be as popular and ubiquitous as R-Pi".
PF uses blue tooth HC05/HC06 as cable replacement. If the voltage goes too low (whem 4 AA runs out) the BT association can get lost, otherwise its same as cable. So PC can download, we are using a GO application to load the prop via propellant (I think). Whatever it is it works great.
We're doing similar with the cheap steppers, but anything will work. The DC motors could be run directly from the prop(s), if a configuration is popular it would be easy to port to it, just adding new drivers. The goal is something everybody can afford, we are just going with this particular set of parts as a starting point.
We also plan to add more props and sensors etc once we find a hardware set that catches on. The plan is to work up to a copter etc if the community interest is there. But one step at a time for now.