The flow control serial I/O sounds like a good addition.
that's what i said. Sal is big on "the right tool for the right job" but understands that us regular folk might perfer to stick to one or two of the more popular options. Python is what we thought would fit, he will convert his proof of concept to python if we don't select another option.
The PC side could be anything, as long as we implemement the flow control properly, which i believe he with specify.
Sal will also dig out his "massivive logging" example, which might be part of the new package.
In my opinion, J is a lot like forth. It stacks up operators (more mathematical operators in J). For example, in J, the "average" function can be defined as: ( +/ % #)
that is (sum divide tally)
It would be cool to see propforth and J working together.
LittleRobot pilot session: We broke one of our assistants.
The kid (30) we hired as teaching assistant resigned. He was bright, enthusiastic, good with kids, and had experience with other kids' robotics programs. But something did not click with the propforth program. While some of the cause may have been poor infrastructure (his old laptop could not run google video chat for remote support during lab sessions, etc), the feedback was the the materials were "too insider and filled with jargon". The intent was for the instructors to point these issues out, so that I could address them, but we never got that far. Conclusion is the material is just overwhelming for some folks.
Luckily, the other assistant is doing better. In fact, she has done all the exercises just as the kids have done (Hello Word and Blinky LED), and has had no problems. We asked her to burn the EEprom on a Quickstart; she was done in about 5 minutes. When we asked her to do the rest, she already had . Conclusion is the material MIGHT BE just fine for some folks.
The regular teachers had pointed out that some of the kids (two in particular) which are normally very quiet (and bored?) are bouncing around and loving the team programming. I don't know if this material will work on ANY kid, but is does seem to work with the hand picked group in the pilot.
- Few Read the documentaion
- Logging to microsecond with minimal drift
Documentation: Nobody Reads it? This is problematic. Its often too expensive to hire skilled professional writers and editors, so the stuff we tend to see frequentily is poor (too poor to bother reading?). So "nobody reads it" and so "nobody bothers to write it". And/or some folks just think different; the material that works for me doesn't work for somebody else, etc. Looking for ideas on how to approach this. In particular, how to train KIDS to read the material first, or at least know the material exists and determine when its worhwhile to spend the time reading.
LOGGING: I finally have a task that justifies learning about logging. When it rains, the sump pump cycles more frequently; if its going to fail, it will probably fail at the worst possible time, when its raining. I need to log when the system cycles, and predict the number of cycles until failure, and the calender time until failure. The goal is to change the part before is fails, but not sooner than necessary.
Sal brought out the "Logging To SD" package. Sal has been using the logging package for over a year, but didn't think anyone else would have a use for it. He's funny. To be clear, this is precision logging without the need for a real time clock part. This is just using the stock prop and software (and an SD card for the log file)
The time portion is microsecond (millionth of a second) since January 1, 1970. Logging works off the counter and 64 bit double math, using 128 bit intermediate values as needed. The intermediate values don't matter to us, they are handled internally.
To set up, we load some source code files to the prop, for autoboot, double math, and time handling. We also create a file bigger than we will need to hold the log. The log file can be up to the size available on the SD. On Sal's 4 Gig card, the largest file he logged was 15 meg. This was a couple days at about one record per second.
When the prop is started, propforth loads necessary definitions from SD, and begins logging. The default time comes up as Noon January 1, 1970. We manually set th clock to some know time, clear the log, and let it run.
DRIFT: There is some drift in the prop crystal. After a day or so, we check the drift, enter a correction factor (ticks per day or something) and the clock is spot on after that, as long as the temperature doesn't change. The observation is the one in the house does not drift, the one in the garage does drift. Over the courrse of a day, the garage test unit drifts out then drifts back according to temperature, I guess if it was calibrated as sunrise or sunset it would be closest. Over the course of a year, the same, maybe calibrate it at spring and at fall and over the course of the year it would average out. Sal figures we could use a termistor and dynamically correct for temperature drift, but is hasn't been necessary yet. And, the unit in the house is nuts dead on after around a year.
Time stamp collisions: There is the possibility of time stamp collisions. At microsecond resolution, Sal has not seen any yet. Even with a bunch of cogs doing stuff, he has not encountered two time stamps with the same number. There's enough microseconds so multiple loggin events don't happen at the same time, collisions are not likely. Neat-o!
Overruns: It can't log more frequently than the time it takes to write to the log. For example, if we log every 10 milliseconds, and sometimes it takes 12 milliseconds to write to the log (he didn't have the exact number), and overrun will occur. Ther will be a bunch of records every 10 milliseconds, when the 12 millisecond event happens there will be a gap of 56 SECONDS (using using a 5Mz crystal running an 80 Mz clock) till the counter rolls over. So, the rule of thumb is log less often that the write time.
Large Data: It take a long time to pull data off the prop SD, about 10 minutes for 15 meg. Recall that the prop SD is considered internal to the prop, we can't just pop it in the PC and read it like we can with a FAT formatted SD. So the rule of thmb is log less than once a second if we are going to log for an extended period of time (days or weeks).
BUFFERING: This will be part two of logging, Sal is keeping it separate for now so my head does not explode.
Records can be of any size, the example allot's 255 bytes. SD cards have a finite write speed, and limited number of write cycles, particularly the cheaper ones. So a cog is set up to buffer a whole bunch of records, and write these all at once as a single write operation. This can also be used to capture records faster, when many records are collected in a single SD write period. Nifty!
Processing: Sal processes the log data on the PC using J. If I understand correctly, the J program parsed and crunched the 15 meg
(over 16000 records?) in less than half a second. He pressed the enter key and the answer popped up. Bing! The J code looks even stranger than forth, but its "easy if one reads the documentation". At least if you're Sal .
It will take a while for me to get my head around all this, and write it up. I also has the LittleRobot pilot as a priority, so that comes first. When the logging material is ready, it will be posted as an extension, and later included in a release.
The J program on the PC calculated variance in time stamps.
The test data was the counter, the local time (curent time zone) , and the unix time (UTC).
When the three data items were collected first, then formatted, the variance was very consistent.
When each data items was collected and then formated before moving on to the next data item, there was a more interesting variance. Formatting takes longer for items with more characters. The variance was from 800 to 1200 microseconds over the 15 meg file. OK, its boring but its just an example.
J was used because it was the solution that worked. It parsed and crunched 15 meg of data (over 16000 records) in the same time as hitting a cariage return. Compare with Excel, which choked after 8000 records. Excel could not parse the data, and so could not process it. Nothing against Excel, it just could not handle this particular data set.
I'm looking for forth-source-code for _eeread and _eewrite.
They are not on StartKernel-1.f and StartKernel-2.f and DevKernel.f.
Where are they?
I'm not sure but I will make a couple guesses:
I think this might be a kernel thing, as we noticed when Loopy was looking at the serial driver. Some parts get optimized in assembler and integrated into the kernel. As more integrations and optimizations take place, the details of deeply integrated function can get lost. For example the serial driver is hard to separate from the interpreter, modifying one would break the other, unless one REALLY know what's going on (and if we have to ask, we don't). When a new kernel version is generated using the `makeforth` word it only takes the current definition, and looses the unused portions, which includes comments, since comments are ignored by the interpreter. The original source for all words was forth, and this was included with the code when it was FIRST optimized. But some of the changes are not in our version of the docs; Sal didn't always include the pre-optimized code as he does now; the notes might be only on Sal's development archive. SO, we would have to look in the version that introduced the EEprom material, that would at least be a start. I don't remember which version introduced EEprom support, it might be 3.2 or 2.7. So that's one possibility.
The other possibility is that we could find it in the build process. The propforth kernel always starts with the slow un-optimized forth-only kernel. The build and test automation builds this and runs the test suite. Then the automation works its way up to building the optimized kernels. At the point where it builds the EEprom kernel, it has used some file that has the EEprom definitions. I don't know if these would be in forth or assembler. It might be buried in those long string of base 64 code of pre-optimized assembler. I tired to look through the build process and the source modules when we were looking for the serial support, but I couldn't keep up, and could not document it properly. Since you are good at assembler, you might be able to, but you would probably need the hardware test bed set up to show that the build and test automation is running correctly.
So if you can't easily find the source, it might be easier just to ask Sal. Consider opening an issue stating what you are looking for, what your final goal is. Now that the kernel is "finished" it might be time start documenting the deep dark secrets of the kernel internals.
I need to make a new word index like this one for the latest release. I'll try and do that by the time the weekend is over if I have any downtime.
Can you also include the *.spin files in your list? It looks like COG! and COG@ are only defined in the SPIN files, it looks like _eeread and _eewrite might be the same.
The words that are only defined in spin would be the list for Sal and I to start documenting.
We it be OK to ask for a comparison between your list and the output from `words`?
Dude! You'll have to talk to the Change Management Group for stuff like that!!
(Assuming I find the program that did this - I think it's a Python script on my Windows laptop) I'll try and include the Spin stuff....and I guess, compare the two outputs. Pray for rain in Medina this weekend or it won't happen!!
I tested DRV8830(motor driver with i2C).
Motor finely rotated.
But strange phenominon occured.
When word"reboot", QuickStart board stopped.
Although pushing reset button, Cannot reset.
Solution are 2type;
1. When removed scl/sda and re-connect between TeraTerm and QS, PropForth start to operate.
2. When removed Vcc or GND line for DRV8830 and re-connect between TeraTerm and QS, PropForth start to operate.
I have no idea.
Problem about reboot is caused by pull-up-resistor for SDA/SCL.
Pull-up-resistor for QS(also other prop-board) are 10k-ohm.
Firstly, I added 10k-ohm on SDA/SCL. (sum-resistor is 5k-ohm)
Communication between QS and DRV8830 is ok. But when reboot, communication broke.
Secondly, I added 1k-ohm on SDA/SCL. (sum-resistor is 909-ohm)
Reboot is finely operate.
Actually bigger than 1k(10k-ohm > R > 1k-ohm) might be ok.
I'm looking for forth-source-code for _eeread and _eewrite.
They are not on StartKernel-1.f and StartKernel-2.f and DevKernel.f.
Where are they?
@Caskaz:
Here's the path to get to the source code for the words _eeread and _eewrite:
in v5.5/2013FEB23mygo V5.5 RC1.zip
in /mygo/V5.5/kernels/InitEEpromkernel.bat
see the file MAKE/scripts/InitEEprom.txt
see MAKE/src/optimize/fs/fsrd.f
see MAKE/src/optimize/fs/fswr.f
All this finally points to
/mygo/V5.5/kernels/MAKE/src/optimize/
at files
BootOptimizeAsmSrc-1.f
and
BootOptimizeAsmSrc-2.f
All the source is generated by being built from scratch, every build.
We removed the build automation from the top level paths as it was too confusing for beginners. Now the really interesting stuff is kind of buried in the mygo.zip. But its still all there, and is complete. In earlier releases some material would "fade away", this issue is now corrected.
We are going to post the ANDROID app GREEN.apb. This is not the final form, and is never going to be supported, but its cool enough to play with. Its just a teaser for the real app which will be later. And I need it for LittleRobot class.
GREEN is an android app that talks to Propforth over bluetooth. Basically a touch screen interface to propforth. It queries propforth for a configuration file. This file tell GREEN how to set its buttons. Green displays these buttons on the touch screen, and they send scripts to propforth.
The LOGGING MODULE being refined, I will post the preliminary code for LOGGING1 (simple) and LOGGING2 (includes QUEUES, and Fhead and Ftail, read the first and last 4k of the log file). This material is completely stable and usable as far as we can tell, but will not be "released" until PropForth 6.
Sal is doing the LOG to SD testing. Turns out that SD cards anecdotaly seem to perfom BETTER than spec. Sal is logging one record per second, in a half gig file. After six days, he's got 50 meg. He guestimates it will run upto 45 days. If it makes it that long, he'll do it again for 90 days. He checks it every day to see if it died yet. While it writes each record on the SD once, it re-wrrites the file header every time there is a write. So if anything is going to blow, it should be the file header record. We should get a pretty good number for maximum write opeerations for SD.
Sal is ready to start talking about the design for PropForth 6. PropForth 6 is different in that it is designed to run on Prop1, Prop2, or ARM. The problem with ARM is that the tool chain is unpleasant. Propforth 6 is slated to contain LOGGING and the SERAIL with FLOW CONTROL (this is just flow control implementated in such a way that it actually works consistently).
The biggest design change fo Prop 6 is the multitasking. Instead of eight separate threads, one per cog, Forth will be sliced across all cogs. This combines the advantages of forth software time slicing and hardware time slicing, and removes some of the drawbacks. As long as there are enough slices, events can be handled in a predictable manner. The cogs can be divided into pools, so the time critical stuff can have one pool, and the non critical stuff can be in a different pool. There can be as many pools as there are threads (I think). The scheme appears to scale linearly, if you add another cog, the pool increases by X amount of slices. It appears that adding physical processors works the same, just ensure a pool is on a single physical processor.
The estimate is three months for a prototype PropForth6 on prop 1. The ARM version should be ready shortly after that, depending on tool chain joy. We might get word of an Alpha or Beta around then, but I'm thinking Fall is when we will have something to play with. The Prop2 version won't be available until Prop 2 is available, of course.
The question is, can anyone use it? The Prop1 stuff (spinforth up to PF5) is simple, yet few folks work through it. The PF6 will be necessarilly more complex (not complicated, just complex), this must be taken into account when our application code is being wriitten, if we are to use this to its protential. Is this a useful direction for this effort?
My thought is, there are at least some folks that can use PF5. While the userbase grows slowly, it still grows; and the rate increases. The main problem is the documentation. AS more folks with better authoring skill add to the documentation, it becomes easier for new folks to get going. PF6 sounds awesome to me, I think it should not be "dumbed down" just because I haven't spent the time to learn the assembler, and can't write about it well. The more interesting it is, the more folks will use it. I voted that we go for it, and aim for hardware timeslicing. Sal's elegant simplicity usually prevails, it just takes effort to work through and understand. And this can happen with time, eventually we ordinary users can find reason to "get around to it", and work through the deep stuff. So Sal will continue to share this tool with us. Maybe I'm just a hoarder of what I perceive to be ultra-high tech.
Here's the path to get to the source code for the words _eeread and _eewrite:
in v5.5/2013FEB23mygo V5.5 RC1.zip
in /mygo/V5.5/kernels/InitEEpromkernel.bat
see the file MAKE/scripts/InitEEprom.txt
see MAKE/src/optimize/fs/fsrd.f
see MAKE/src/optimize/fs/fswr.f
All this finally points to
/mygo/V5.5/kernels/MAKE/src/optimize/
at files
BootOptimizeAsmSrc-1.f
and
BootOptimizeAsmSrc-2.f
All the source is generated by being built from scratch, every build.
We removed the build automation from the top level paths as it was too confusing for beginners. Now the really interesting stuff is kind of buried in the mygo.zip. But its still all there, and is complete. In earlier releases some material would "fade away", this issue is now corrected.
I couldn't find the 'mygo' version of the .zip in this thread or on the google code site.
Using all the .f files in the .zip file that is out there, I was able to build a new word index.
Interestingly, due to the changes in the build process, it's missing a lot of the core words (they are presumably buried in the 'mygo' .zip)
Anyway, here's what I have so far for a new word index.
I'll work on it more when I get a copy of the 'mygo' .zip
Once the listing utility is fully functional, I'll put it and the index list on the wiki. The current utility is written in Perl....I'm not man enough to do something like this in Forth.
I couldn't find the 'mygo' version of the .zip in this thread or on the google code site.
Ok, this is the trade off. The material was re-organized for folks could easily get to the kernels they are going to use, and the trade off was the advanced material got put lower.
Let me try to do this again, maybe my steps were off.
.
This file 2013FEB23mygo V5.5 RC1.zip is the file that used to be the entire release in the past. This contains the all the build automation and tests.
Copy 2013FEB23mygo V5.5 RC1.zip to a convenient location and exact it contents. This give you the directory
mygo
.
Find
/mygo/V5.5/kernels/MAKE/src/
Here we find all the source. There is also a directoy optimize here, so
/mygo/V5.5/kernels/MAKE/src/optimize
is the location for BootOptimizeAsmSrc-1.f and BootOptimizeAsmSrc-2.f
The directory tree looks a little weird at first, but when you follow the automation it is organized in a straightforward manner. Its not really complicated, but there is a lot of stuff that has to happen in the right order. Even so, I tend to avoid the automation once testing is complete.
Wii-nunchaku can operate.
But this is incomplete.
WORD"_eeread and _eewrite " for PF5.2/PF5.5 can't use on this code.
I have no idea.
Can someeone solve this problem?
Attached is the new index (forth_index_v_5_5.txt), the zipped source files it was created with (all the .f sources I could find in the release put into one big file) and the perl script, forth_word_source_index, that I used to create the index in case anyone wants to play at home.
The perl script has had the extension changed to .txt for the forum. Just change it back to .pl for perl.
It expects to find the source file directory here: C:\MyCode\PropForth\V5.5\SourceFiles - if you put it someplace else, just change line 10 in the script to reflect the new location (you need to escape "\" in windows paths with "\", so each "\" becomes "\\" in the perl script.
I'll load all this to the Wiki when I get a chance.
This begs to have much more done with it: a little web app where you can click on the word from the index page and display the codes snippet(s) that show how the word is defined.; a PC based Forth editor/terminal, dictionary manager; more?
The logger stopped, due to a power failure. When power came back, the logger resumed logging. Sal had to reset the time (from the default 1990, January 1, 12:00 am) but it is easy to go back and correct the time stamps. The old 2 gig SD card has not failed after two weeks and 110 meg of data. Sal off loaded the data at 80meg, it took 6 hours over bluetooth. Sal is going to change it so it creates a new file each time the day rolls over, this this should not fail since each file has a new file header. Sal now has a mission to make a card fail, so he can understand the failure mode. He guestimates it should take about a year to test this properly.
So far the variance in timestamps is 3-4 microseconds. If an application is concerned with microsecond accuracy, a temperature stablized crystal would be needed, but if we don't care about such accuracy, a stock crystal should be just fine. It just drifts in and out.
NickRobotControl
Sal really likes Nick Lordi's robot control language application for LittleRobot. "Its beautiful, very clear and concise, I can understand it in the time it takes to read it." This will be our example of well constructed forth code.
LittleRobot
We changed the BOM to use 2" pink foam for the chassis, and replaced the breadboard with Male to Female jumper wires. Boring a 1 inch hole in the pink foam leave a rough hole that the stepper motors can be press fitted into by hand. 1 inch #4 machine screws will be used to secure the steppers, but might not be necessary. All else will be fastened with velcro or duct tape or machine screws.
The LittleRobot session 1 (pilot) is drawing to a close, session 2 (a workshop) is booked, and possible sessions 3 and 4 are in the process of getting booked.
We haven't finallized the wheels. So far the options we've tried are laser cut acrylic wheels and 3D printed wheels. Laser cut wheels rely on kindness from someone with a laser cutter, and 3D printed wheels require lots of my time to run the printer. Maybe I need a big ol' box of 1/4 by 4 inch gears with 1/4 by 3/8 shaft holes from surplus.
PROPFORTH 6
Sal is building the optimized versions of PF6 now, on Prop 1, as a baseline for when Prop 2 comes out. Sal tested the synchronus serial drivers, sending 2 gig data over night, 11-12 bit times per character, about 20k chars per second. Compare to Bluetooth 4-5K char per second.
The big difference of PropForth 6 is that it treats the cogs as a pool. Propforth 5 and below has one task per thread, and since most threads are idle most of the time, a lot of processing oportunities are wasted. Propforth 6 will distribute tasks over available cogs as needed. This should allow many more than 8 tasks one a single prop (provided we don't run out of other resources like code space). On the Prop2, with four threads per cog we will have 32 threads in our pool. This gives a large enough pool so that we can do many intermittant things at once (more than 32), and deterministic execution should be minimally impacted. This is going to be COOL!
I 3d printed some wheels for the stepper motors, and they didn't require a long time to print. Or maybe we don not agree about "lot of time" definition...
If you have rubber o-rings you could have better grip. I used a soft pla for tires, but it is not soft enough.
Pictures are here: http://forums.parallax.com/showthread.php/138125-Erco-s-Figure-Eight-Challenge?p=1157894&viewfull=1#post1157894
The design is very simple, but in case you are interested I can post the model.
You can thighten the hub with a couple of screws.
Massimo
I 3d printed some wheels for the stepper motors, and they didn't require a long time to print. Or maybe we don not agree about "lot of time" definition...
Massimo
Thanks for the response. Please post the model, more options is better.
only take a bout an hour, from "get coffee" to "put in box". Each group has 12 to 30 participants. If I could just sit and tend the machine, it wouldn't be an issue (I can sit and watch the machine for hours given the chance) but every time the kid cries, or the door bell or phone rings, or other interruption, there is the likelyhood of scrapping another piece. RepRap is not always the ideal choice for volume production. This remains the fall back, but I would prefer a less labor intensive (on my part) solution.
The current printed wheels are such that #6 rubberbands fit and provide traction, its like a buck for a box of 100; OBC shipped what look like sections of bicycle inner tube with the acrylic wheels
Ideally, the participants would come up with their own wheels, but none have so far .
Comments
The flow control serial I/O sounds like a good addition.
that's what i said. Sal is big on "the right tool for the right job" but understands that us regular folk might perfer to stick to one or two of the more popular options. Python is what we thought would fit, he will convert his proof of concept to python if we don't select another option.
The PC side could be anything, as long as we implemement the flow control properly, which i believe he with specify.
Sal will also dig out his "massivive logging" example, which might be part of the new package.
that is (sum divide tally)
It would be cool to see propforth and J working together.
The kid (30) we hired as teaching assistant resigned. He was bright, enthusiastic, good with kids, and had experience with other kids' robotics programs. But something did not click with the propforth program. While some of the cause may have been poor infrastructure (his old laptop could not run google video chat for remote support during lab sessions, etc), the feedback was the the materials were "too insider and filled with jargon". The intent was for the instructors to point these issues out, so that I could address them, but we never got that far. Conclusion is the material is just overwhelming for some folks.
Luckily, the other assistant is doing better. In fact, she has done all the exercises just as the kids have done (Hello Word and Blinky LED), and has had no problems. We asked her to burn the EEprom on a Quickstart; she was done in about 5 minutes. When we asked her to do the rest, she already had
The regular teachers had pointed out that some of the kids (two in particular) which are normally very quiet (and bored?) are bouncing around and loving the team programming. I don't know if this material will work on ANY kid, but is does seem to work with the hand picked group in the pilot.
- Few Read the documentaion
- Logging to microsecond with minimal drift
Documentation: Nobody Reads it? This is problematic. Its often too expensive to hire skilled professional writers and editors, so the stuff we tend to see frequentily is poor (too poor to bother reading?). So "nobody reads it" and so "nobody bothers to write it". And/or some folks just think different; the material that works for me doesn't work for somebody else, etc. Looking for ideas on how to approach this. In particular, how to train KIDS to read the material first, or at least know the material exists and determine when its worhwhile to spend the time reading.
LOGGING: I finally have a task that justifies learning about logging. When it rains, the sump pump cycles more frequently; if its going to fail, it will probably fail at the worst possible time, when its raining. I need to log when the system cycles, and predict the number of cycles until failure, and the calender time until failure. The goal is to change the part before is fails, but not sooner than necessary.
Sal brought out the "Logging To SD" package. Sal has been using the logging package for over a year, but didn't think anyone else would have a use for it. He's funny.
The time portion is microsecond (millionth of a second) since January 1, 1970. Logging works off the counter and 64 bit double math, using 128 bit intermediate values as needed. The intermediate values don't matter to us, they are handled internally.
To set up, we load some source code files to the prop, for autoboot, double math, and time handling. We also create a file bigger than we will need to hold the log. The log file can be up to the size available on the SD. On Sal's 4 Gig card, the largest file he logged was 15 meg. This was a couple days at about one record per second.
When the prop is started, propforth loads necessary definitions from SD, and begins logging. The default time comes up as Noon January 1, 1970. We manually set th clock to some know time, clear the log, and let it run.
DRIFT: There is some drift in the prop crystal. After a day or so, we check the drift, enter a correction factor (ticks per day or something) and the clock is spot on after that, as long as the temperature doesn't change. The observation is the one in the house does not drift, the one in the garage does drift. Over the courrse of a day, the garage test unit drifts out then drifts back according to temperature, I guess if it was calibrated as sunrise or sunset it would be closest. Over the course of a year, the same, maybe calibrate it at spring and at fall and over the course of the year it would average out. Sal figures we could use a termistor and dynamically correct for temperature drift, but is hasn't been necessary yet. And, the unit in the house is nuts dead on after around a year.
Time stamp collisions: There is the possibility of time stamp collisions. At microsecond resolution, Sal has not seen any yet. Even with a bunch of cogs doing stuff, he has not encountered two time stamps with the same number. There's enough microseconds so multiple loggin events don't happen at the same time, collisions are not likely. Neat-o!
Overruns: It can't log more frequently than the time it takes to write to the log. For example, if we log every 10 milliseconds, and sometimes it takes 12 milliseconds to write to the log (he didn't have the exact number), and overrun will occur. Ther will be a bunch of records every 10 milliseconds, when the 12 millisecond event happens there will be a gap of 56 SECONDS (using using a 5Mz crystal running an 80 Mz clock) till the counter rolls over. So, the rule of thumb is log less often that the write time.
Large Data: It take a long time to pull data off the prop SD, about 10 minutes for 15 meg. Recall that the prop SD is considered internal to the prop, we can't just pop it in the PC and read it like we can with a FAT formatted SD. So the rule of thmb is log less than once a second if we are going to log for an extended period of time (days or weeks).
BUFFERING: This will be part two of logging, Sal is keeping it separate for now so my head does not explode.
Records can be of any size, the example allot's 255 bytes. SD cards have a finite write speed, and limited number of write cycles, particularly the cheaper ones. So a cog is set up to buffer a whole bunch of records, and write these all at once as a single write operation. This can also be used to capture records faster, when many records are collected in a single SD write period. Nifty!
Processing: Sal processes the log data on the PC using J. If I understand correctly, the J program parsed and crunched the 15 meg
(over 16000 records?) in less than half a second. He pressed the enter key and the answer popped up. Bing! The J code looks even stranger than forth, but its "easy if one reads the documentation". At least if you're Sal
It will take a while for me to get my head around all this, and write it up. I also has the LittleRobot pilot as a priority, so that comes first. When the logging material is ready, it will be posted as an extension, and later included in a release.
The J program on the PC calculated variance in time stamps.
The test data was the counter, the local time (curent time zone) , and the unix time (UTC).
When the three data items were collected first, then formatted, the variance was very consistent.
When each data items was collected and then formated before moving on to the next data item, there was a more interesting variance. Formatting takes longer for items with more characters. The variance was from 800 to 1200 microseconds over the 15 meg file. OK, its boring but its just an example.
J was used because it was the solution that worked. It parsed and crunched 15 meg of data (over 16000 records) in the same time as hitting a cariage return. Compare with Excel, which choked after 8000 records. Excel could not parse the data, and so could not process it. Nothing against Excel, it just could not handle this particular data set.
Neat! If I eve get time, I might look into J.
I'm looking for forth-source-code for _eeread and _eewrite.
They are not on StartKernel-1.f and StartKernel-2.f and DevKernel.f.
Where are they?
I'm not sure but I will make a couple guesses:
I think this might be a kernel thing, as we noticed when Loopy was looking at the serial driver. Some parts get optimized in assembler and integrated into the kernel. As more integrations and optimizations take place, the details of deeply integrated function can get lost. For example the serial driver is hard to separate from the interpreter, modifying one would break the other, unless one REALLY know what's going on (and if we have to ask, we don't). When a new kernel version is generated using the `makeforth` word it only takes the current definition, and looses the unused portions, which includes comments, since comments are ignored by the interpreter. The original source for all words was forth, and this was included with the code when it was FIRST optimized. But some of the changes are not in our version of the docs; Sal didn't always include the pre-optimized code as he does now; the notes might be only on Sal's development archive. SO, we would have to look in the version that introduced the EEprom material, that would at least be a start. I don't remember which version introduced EEprom support, it might be 3.2 or 2.7. So that's one possibility.
The other possibility is that we could find it in the build process. The propforth kernel always starts with the slow un-optimized forth-only kernel. The build and test automation builds this and runs the test suite. Then the automation works its way up to building the optimized kernels. At the point where it builds the EEprom kernel, it has used some file that has the EEprom definitions. I don't know if these would be in forth or assembler. It might be buried in those long string of base 64 code of pre-optimized assembler. I tired to look through the build process and the source modules when we were looking for the serial support, but I couldn't keep up, and could not document it properly. Since you are good at assembler, you might be able to, but you would probably need the hardware test bed set up to show that the build and test automation is running correctly.
So if you can't easily find the source, it might be easier just to ask Sal. Consider opening an issue stating what you are looking for, what your final goal is. Now that the kernel is "finished" it might be time start documenting the deep dark secrets of the kernel internals.
Can you also include the *.spin files in your list? It looks like COG! and COG@ are only defined in the SPIN files, it looks like _eeread and _eewrite might be the same.
The words that are only defined in spin would be the list for Sal and I to start documenting.
We it be OK to ask for a comparison between your list and the output from `words`?
(Assuming I find the program that did this - I think it's a Python script on my Windows laptop) I'll try and include the Spin stuff....and I guess, compare the two outputs. Pray for rain in Medina this weekend or it won't happen!!
I tested DRV8830(motor driver with i2C).
Motor finely rotated.
But strange phenominon occured.
When word"reboot", QuickStart board stopped.
Although pushing reset button, Cannot reset.
Solution are 2type;
1. When removed scl/sda and re-connect between TeraTerm and QS, PropForth start to operate.
2. When removed Vcc or GND line for DRV8830 and re-connect between TeraTerm and QS, PropForth start to operate.
I have no idea.
Excellent! This might be a nice upgrade for a littlerobot!
Could this be related to sharing SDA and SCL with EEPROM?
Problem about reboot is caused by pull-up-resistor for SDA/SCL.
Pull-up-resistor for QS(also other prop-board) are 10k-ohm.
Firstly, I added 10k-ohm on SDA/SCL. (sum-resistor is 5k-ohm)
Communication between QS and DRV8830 is ok. But when reboot, communication broke.
Secondly, I added 1k-ohm on SDA/SCL. (sum-resistor is 909-ohm)
Reboot is finely operate.
Actually bigger than 1k(10k-ohm > R > 1k-ohm) might be ok.
@Caskaz:
Here's the path to get to the source code for the words _eeread and _eewrite:
in v5.5/2013FEB23mygo V5.5 RC1.zip
in /mygo/V5.5/kernels/InitEEpromkernel.bat
see the file MAKE/scripts/InitEEprom.txt
see MAKE/src/optimize/fs/fsrd.f
see MAKE/src/optimize/fs/fswr.f
All this finally points to
/mygo/V5.5/kernels/MAKE/src/optimize/
at files
BootOptimizeAsmSrc-1.f
and
BootOptimizeAsmSrc-2.f
All the source is generated by being built from scratch, every build.
We removed the build automation from the top level paths as it was too confusing for beginners. Now the really interesting stuff is kind of buried in the mygo.zip. But its still all there, and is complete. In earlier releases some material would "fade away", this issue is now corrected.
ANDROID GREEN
LOGGING MODULE
SD & LOGGING
PF6
We are going to post the ANDROID app GREEN.apb. This is not the final form, and is never going to be supported, but its cool enough to play with. Its just a teaser for the real app which will be later. And I need it for LittleRobot class.
GREEN is an android app that talks to Propforth over bluetooth. Basically a touch screen interface to propforth. It queries propforth for a configuration file. This file tell GREEN how to set its buttons. Green displays these buttons on the touch screen, and they send scripts to propforth.
The LOGGING MODULE being refined, I will post the preliminary code for LOGGING1 (simple) and LOGGING2 (includes QUEUES, and Fhead and Ftail, read the first and last 4k of the log file). This material is completely stable and usable as far as we can tell, but will not be "released" until PropForth 6.
Sal is doing the LOG to SD testing. Turns out that SD cards anecdotaly seem to perfom BETTER than spec. Sal is logging one record per second, in a half gig file. After six days, he's got 50 meg. He guestimates it will run upto 45 days. If it makes it that long, he'll do it again for 90 days. He checks it every day to see if it died yet. While it writes each record on the SD once, it re-wrrites the file header every time there is a write. So if anything is going to blow, it should be the file header record. We should get a pretty good number for maximum write opeerations for SD.
Does anyone have any real numbers on SD failure?
Sal is ready to start talking about the design for PropForth 6. PropForth 6 is different in that it is designed to run on Prop1, Prop2, or ARM. The problem with ARM is that the tool chain is unpleasant. Propforth 6 is slated to contain LOGGING and the SERAIL with FLOW CONTROL (this is just flow control implementated in such a way that it actually works consistently).
The biggest design change fo Prop 6 is the multitasking. Instead of eight separate threads, one per cog, Forth will be sliced across all cogs. This combines the advantages of forth software time slicing and hardware time slicing, and removes some of the drawbacks. As long as there are enough slices, events can be handled in a predictable manner. The cogs can be divided into pools, so the time critical stuff can have one pool, and the non critical stuff can be in a different pool. There can be as many pools as there are threads (I think). The scheme appears to scale linearly, if you add another cog, the pool increases by X amount of slices. It appears that adding physical processors works the same, just ensure a pool is on a single physical processor.
The estimate is three months for a prototype PropForth6 on prop 1. The ARM version should be ready shortly after that, depending on tool chain joy. We might get word of an Alpha or Beta around then, but I'm thinking Fall is when we will have something to play with. The Prop2 version won't be available until Prop 2 is available, of course.
The question is, can anyone use it? The Prop1 stuff (spinforth up to PF5) is simple, yet few folks work through it. The PF6 will be necessarilly more complex (not complicated, just complex), this must be taken into account when our application code is being wriitten, if we are to use this to its protential. Is this a useful direction for this effort?
My thought is, there are at least some folks that can use PF5. While the userbase grows slowly, it still grows; and the rate increases. The main problem is the documentation. AS more folks with better authoring skill add to the documentation, it becomes easier for new folks to get going. PF6 sounds awesome to me, I think it should not be "dumbed down" just because I haven't spent the time to learn the assembler, and can't write about it well. The more interesting it is, the more folks will use it. I voted that we go for it, and aim for hardware timeslicing. Sal's elegant simplicity usually prevails, it just takes effort to work through and understand. And this can happen with time, eventually we ordinary users can find reason to "get around to it", and work through the deep stuff. So Sal will continue to share this tool with us. Maybe I'm just a hoarder of what I perceive to be ultra-high tech.
I couldn't find the 'mygo' version of the .zip in this thread or on the google code site.
Using all the .f files in the .zip file that is out there, I was able to build a new word index.
Interestingly, due to the changes in the build process, it's missing a lot of the core words (they are presumably buried in the 'mygo' .zip)
Anyway, here's what I have so far for a new word index.
I'll work on it more when I get a copy of the 'mygo' .zip
Once the listing utility is fully functional, I'll put it and the index list on the wiki. The current utility is written in Perl....I'm not man enough to do something like this in Forth.
Comment and feedback always welcome!!
Ok, this is the trade off. The material was re-organized for folks could easily get to the kernels they are going to use, and the trade off was the advanced material got put lower.
Let me try to do this again, maybe my steps were off.
Everything is in the download. http://code.google.com/p/propforth/downloads/detail?name=PropForth-V5.5-20130317.zip
Download and extract. The root level directory in this archive is
The advanced material is in the misc directory In this directory is a file .
This file 2013FEB23mygo V5.5 RC1.zip is the file that used to be the entire release in the past. This contains the all the build automation and tests.
Copy 2013FEB23mygo V5.5 RC1.zip to a convenient location and exact it contents. This give you the directory .
Find Here we find all the source. There is also a directoy optimize here, so is the location for BootOptimizeAsmSrc-1.f and BootOptimizeAsmSrc-2.f
The directory tree looks a little weird at first, but when you follow the automation it is organized in a straightforward manner. Its not really complicated, but there is a lot of stuff that has to happen in the right order. Even so, I tend to avoid the automation once testing is complete.
Wii-nunchaku can operate.
But this is incomplete.
WORD"_eeread and _eewrite " for PF5.2/PF5.5 can't use on this code.
I have no idea.
Can someeone solve this problem?
Attached is the new index (forth_index_v_5_5.txt), the zipped source files it was created with (all the .f sources I could find in the release put into one big file) and the perl script, forth_word_source_index, that I used to create the index in case anyone wants to play at home.
The perl script has had the extension changed to .txt for the forum. Just change it back to .pl for perl.
It expects to find the source file directory here: C:\MyCode\PropForth\V5.5\SourceFiles - if you put it someplace else, just change line 10 in the script to reflect the new location (you need to escape "\" in windows paths with "\", so each "\" becomes "\\" in the perl script.
I'll load all this to the Wiki when I get a chance.
This begs to have much more done with it: a little web app where you can click on the word from the index page and display the codes snippet(s) that show how the word is defined.; a PC based Forth editor/terminal, dictionary manager; more?
forth_index_v_5_5.txt
forth_word_source_index.txt
Forthv55_SourceFiles.zip
This is a good start, thanks for your effort
COG@ is defined in StartKernel-1.f but isn't a regular colon definition.
I had exercise about WORD"serial".
I got BeagleBoneBlack(BBB)'s log by using "serial".
If merely getting BBB's log, Not need to use propeller.
Only needing PropPlug and USB-cable.
{ PropForth 5.5 2013/05/26 11:43:42 BeagleBoneBlack Propeller J1-1(GND) --- GND J1-4(RxD) --- P0(TxD) J1-5(TxD) --- P1(RxD) } : term over cognchan min ." Hit CTL-P to exit term, CTL-Q exit nest1 CTL-R exit nest2 ... CTL-exit nest9~h0D~h0A" >r >r cogid 0 r> r> (iolink) begin key dup h10 = if drop -1 else dup h11 h19 between if 1- then emit 0 then until cogid iounlink ; : _snet 4 cogreset h10 delms \ pin 0 rx, pin 1 tx d115200/4 = d28800 c" 0 1 d28800 serial" 4 cogx h100 delms 1 4 sersetflags 1 7 sersetflags ; : resnet _snet h10 delms h4 0 term 0 7 sersetflags ;Logger
The logger stopped, due to a power failure. When power came back, the logger resumed logging. Sal had to reset the time (from the default 1990, January 1, 12:00 am) but it is easy to go back and correct the time stamps. The old 2 gig SD card has not failed after two weeks and 110 meg of data. Sal off loaded the data at 80meg, it took 6 hours over bluetooth. Sal is going to change it so it creates a new file each time the day rolls over, this this should not fail since each file has a new file header. Sal now has a mission to make a card fail, so he can understand the failure mode. He guestimates it should take about a year to test this properly.
So far the variance in timestamps is 3-4 microseconds. If an application is concerned with microsecond accuracy, a temperature stablized crystal would be needed, but if we don't care about such accuracy, a stock crystal should be just fine. It just drifts in and out.
NickRobotControl
Sal really likes Nick Lordi's robot control language application for LittleRobot. "Its beautiful, very clear and concise, I can understand it in the time it takes to read it." This will be our example of well constructed forth code.
LittleRobot
We changed the BOM to use 2" pink foam for the chassis, and replaced the breadboard with Male to Female jumper wires. Boring a 1 inch hole in the pink foam leave a rough hole that the stepper motors can be press fitted into by hand. 1 inch #4 machine screws will be used to secure the steppers, but might not be necessary. All else will be fastened with velcro or duct tape or machine screws.
The LittleRobot session 1 (pilot) is drawing to a close, session 2 (a workshop) is booked, and possible sessions 3 and 4 are in the process of getting booked.
We haven't finallized the wheels. So far the options we've tried are laser cut acrylic wheels and 3D printed wheels. Laser cut wheels rely on kindness from someone with a laser cutter, and 3D printed wheels require lots of my time to run the printer. Maybe I need a big ol' box of 1/4 by 4 inch gears with 1/4 by 3/8 shaft holes from surplus.
PROPFORTH 6
Sal is building the optimized versions of PF6 now, on Prop 1, as a baseline for when Prop 2 comes out. Sal tested the synchronus serial drivers, sending 2 gig data over night, 11-12 bit times per character, about 20k chars per second. Compare to Bluetooth 4-5K char per second.
The big difference of PropForth 6 is that it treats the cogs as a pool. Propforth 5 and below has one task per thread, and since most threads are idle most of the time, a lot of processing oportunities are wasted. Propforth 6 will distribute tasks over available cogs as needed. This should allow many more than 8 tasks one a single prop (provided we don't run out of other resources like code space). On the Prop2, with four threads per cog we will have 32 threads in our pool. This gives a large enough pool so that we can do many intermittant things at once (more than 32), and deterministic execution should be minimally impacted. This is going to be COOL!
If you have rubber o-rings you could have better grip. I used a soft pla for tires, but it is not soft enough.
Pictures are here:
http://forums.parallax.com/showthread.php/138125-Erco-s-Figure-Eight-Challenge?p=1157894&viewfull=1#post1157894
The design is very simple, but in case you are interested I can post the model.
You can thighten the hub with a couple of screws.
Massimo
Thanks for the response. Please post the model, more options is better.
One set of wheels from
http://code.google.com/p/propforth/downloads/detail?name=LittleRobot.scad
only take a bout an hour, from "get coffee" to "put in box". Each group has 12 to 30 participants. If I could just sit and tend the machine, it wouldn't be an issue (I can sit and watch the machine for hours given the chance) but every time the kid cries, or the door bell or phone rings, or other interruption, there is the likelyhood of scrapping another piece. RepRap is not always the ideal choice for volume production. This remains the fall back, but I would prefer a less labor intensive (on my part) solution.
The current printed wheels are such that #6 rubberbands fit and provide traction, its like a buck for a box of 100; OBC shipped what look like sections of bicycle inner tube with the acrylic wheels
Ideally, the participants would come up with their own wheels, but none have so far .