We should have a test automation alpha together by next week. So far, the automation consistently recreates exact duplicates for each kernel for each run, so the automation only needs to check for differences. RTC and IP testing still need to be implemented, these will require multiple IP and serial channels.
A full build and test cycle now is taking about 40 minutes, and requires no intervention.
Issue 154 Stack Underflow was analyzed and a fix found, this should be in next release.
When automation is complete, it will be much easier to create and test new kernel variations. We could be looking at a July release. At that point, we will bring the previous library of extensions up to version 5.
Got the alpha for v5.3 with really cool test automation. It is not necessarily limited to propforth, it should be applicable to any spin code that can output text.
This is how it works:
FORTH is an interpreter at the command line. Text coming in is numbers placed on the stack, command works that are executed, or new definitions that are compiled into the dictionary. Input can come from the command line, or from a file. So any file can contain new definitions, or a list of words to execute, and can be used as a script.
On the PC side, Sal has started the single channel GoTerm terminal program. It now has two modes that can be toggled between terminal mode and command mode. Terminal mode is the regular terminal emulator, command mode runs PC side command functions. The command mode controls sending source and binary files from the PC to the prop, and capturing test and binary files from the prop, as well as executing programs on the PC. So the PC also runs scripts,and captures the output to log files.
On the Prop side, we use the previously established "standard test bed hardware" consisting of a protoboard (or similar) a bare propchip on a breadboard connected with 5 wires and some passives (or similar) and a spinneret (or similar). There is a single USB cable to a propplug on the protoboard. (Later the multichannel version will allow more physical connections, but for now we can talk directly to all 23 cogs and have channels to spare, so its adequate for the alpha).
The automation build function uses PROPELLANT executable to compile spin programs. For example, there is a an assembler module that is the basis for all the optimized propforth kernels. This and various support modules for SD, EEPROM file system, Ethernet, etc are combined to make the various kernels. Sal reports that its almost trivial to kick out a new custom kernel (for him at least, I haven't started on the process documentation yet).
The automation has a test execution function that loads all the kernels and launches all the tests. It records the outputs and logs them to files, and compares the current output with the previous "known good" output, and flags any differences. The timestamps and independent operating frequencies are always different, and the rest (compilation binary results, test results, etc) are always identical for the same set of code. So any differences should be predicable for any set of changes, and anything else is something to check out.
Because of the command mode, we can capture any interaction between the PC (the user) and the prop, and make it into another test. This allows creation of tests for everything, and immediate regression test and evaluation after any change. So keeping the "known good" results up to date is simple and timely.
To summarize, the automation compiles the spin code, and runs it on the prop(s), and checks if the results are the same as last time. All the things that are not expected to change are regression tests, and all the things that do change can be easily identified and checked for correctness, and added to the regression part.
In the alpha, Sal created a new kernel with some arbitrary set of functions, (I think it was the IP stuff). The automation worked, the results were correct and repeatable (identical on subsequent runs). The entire test cycle has been reduced from several weeks to under 40 minutes (for a clean run that has no errors), and is initiated with a single command on the PC. We anticipate adding a test for EVERYTHING, and lots of new custom kernels, and just let the rig run over night.
This might be useful to folks that like to test to requirements with predicable results.
The first pass of shaking down the automation may take some time, afterwards we think the pace of development and quality of work will increase.
Quickstart is the least expensive, easiest option to get started. There is a less expensive option, to get a bare prop chip ($8) and a breadboard, but this assumes you have a 3.3v regulator and 64K EEPROM, etc, in you parts box; if you don't have the spare parts then I recommend the Quickstart.
The expansion boards are not necessary until there is a specific project that needs to be soldered, for example an A/D project. In the mean time, I would recommend a simple bread board, these have been suitable for all my experiments so far.
prof: Your auto testing sounds great. We had something similar many years ago when we were developing an SDLC board and 3270 emulation on an Apple //. Every bug (or non-conformance of IBM's own code) was regression tested. Even though it was fully automatic, it took days to run.
I was just trying to find out a bit more about some of the words in PropForth 5.2 so I decided to write a quick decompiler. Well it wasn't that quick, it still toook about an hour
Here's the output when I get it to decompile the word "serial"
This is the decompiler code, I haven't tried to optimize it yet and it is incomplete but sufficient for the moment.
fl
[ifdef Decompiler
forget Decompiler
]
: Decompiler ;
hex
' exit constant #exit
' litw constant #litw
' litl constant #litl
' (+loop) constant #+loop
' (loop) constant #loop
' 0branch constant #0branch
' branch constant #branch
' cq constant #cq
' dq constant #dq
: .line dup cr .word ." : " ;
: .name dup 1+ swap C@ 1F and bounds do i C@ emit loop ;
: .ext \ ( adr word -- adr )
dup #litl =
if drop 2+ alignl dup L@ space .long 2+ exit then
dup #litw =
if drop 2+ dup W@ space .word exit then
dup #loop = over #+loop = or over #0branch = or over #branch = or
if drop 2+ dup W@ over + ." >" .word exit then
dup #cq = over #dq = or
if drop space 22 emit space 2+ dup .cstr 22 emit dup C@ 1- + exit then
drop
;
: decomp \ use in the form "decomp name" or --> ' name decomp
' dup 0= if drop then \ assume parameter has been passed on stack rather than in line
hex
begin
.line
dup W@ pfa>nfa .name
dup W@ .ext
dup 2+ alignw swap W@ #exit =
fkey? drop 1B = or \ force stop on escape key
until
cr drop
;
So could we have a quick show of hands as to who is working on a project with PropForth at present?
1) CSP channels between PC and PropForth
2) Propforth socket extensions to PC based MinForth to allow transparent access to Propeller via MinForth words.
3) Multi-Prop PropForth
4) PropForth word indexer (start of PC based IDE for PropForth)
5) learning, always learning.....
6) Propforth support for various Parallax sensors (always on the platter, never gets worked on)
Probably more but I've forgotten them........for now!
Thanks for the decompiler, that should be fun to play with.
I'm just doing testing, and writing docs. I'm trying to write a tutorial that is easy enough so non-techie parents can help their kids work through it. Keeping it simple is a lot harder than it should be. I'm too preoccupied with the brainettes to get any real work going.
But if I ever get the time, I have dreams of finishing the spider and the hand I've been working on. First we have to finish the CNC, parallel stuff example, the Jupiter ACE II, and a bunch of other stuff buried under those.
@caskaz: I noticed that your worddump doesn't handle extended words such as litw etc. The word at address 2256 should be the literal word following litw, not cogpad.
Also you seem to have hardcoded the addresses for the constant instead of just using Forth to find them for you using '
I have noticed that the kernel has made sacrifices for what can run from the Forth COG in PASM because even stack words such as rot and swap are colon definitions and if they were used a bit inside a loop they would certainly slow things down. Normally these common stack operations etc are written in assembly and are quite fast. It would be nice if they were written in PASM but COGs were designed to run light and tight in their 512 longs and Sal has done a marvelous job in doing what he has done with adapting Forth for the Prop. If only Prop's had another COG that was an ARM
O Brainy one, what do I have to do to contribute to the propforth group? I also want to pick some brains too! I've got a project where I am connecting up around 16 or more Prop chips on separate modules inside a rack. Each of these modules is connected to a simple bus through isolators and only one module can talk back to the "master". The isolators also tristate the transmit line of each module so that only the one selected gets to talk plus the select signal is also fed into each Prop and also gates the module reset and receive line so that it is possible to reprogram each module one by one in the normal Prop way as well. I'm also looking at having a couple of those modules as LAN interfaces using the Wiznet chip as well as some other specialized interfaces.
Now, I've heard mentioned of these Multichannel Serial Communications, is there any more information about this? I want to see if I can use this and what I might have to do in hardware to make that possible. It may also be that this rack has an ARM processor or even a Raspberry Pi so if that's the case then GO may be the way to go and I need to learn a little bit more about that (I'm a quick study).
I have noticed that the kernel has made sacrifices for what can run from the Forth COG in PASM because even stack words such as rot and swap are colon definitions and if they were used a bit inside a loop they would certainly slow things down.
If I understand your intent:
In general, if you want something to run "in a cog" (a special function and not a word from the common forth dictionary), it would be in assembler. This is not a sacrifice, this is the design. We wouldn't be using the colon definition for 'rot', we would strip out the overhead that is slowing it down and just use the assembler sequence that does what we want. The assembly routine only needs to conform to forth when it is called and when it exits.
And one can add another processor that is an ARM (or anything else), if one implements the GO channel interface on that , as done on the PC in goterm & gomuxterm. The current path includes Cortex-M3 (I think) but non-prop work only makes it to Sal's list indirectly.
Not so much intent just an observation about core kernel words that I normally take for granted are written in assembler on other processors. The Prop implementation is "EForth'ish" in that it implements a tiny portion of the kernel in assembler and the rest in high-level but that's because of COG memory constraints with the Prop.
Is there some documentation on MSC stuff and how do I get to be one of the propforth group committers?
what do I have to do to contribute to the propforth group?
...
Multichannel Serial Communications, is there any more information about this?
Sorry dude, I thought I added you to the list months ago. Please PM me with your gmail address and I can add you to the contributors list. I think other email addresses work, but I think gmail addresses work better.
The released multichannel serial material is "completely" demonstrated in the tutorials in
\Propforth-5.xx-yyyymmdd\kernels\doc\tutorials
in files
tutorial-3.3 MCS Loopack.txt
tutorial-7.3 MCS+NoROM.txt
BUT (for now) we have to work thru the tutorials from 1.0 up to 7.3 to run those tests. The tests demonstrate the proper usage and functions of the propforth kernel functions, to the best of our knowledge.
The GO channels (CSP stuff although some folks dispute the CSP-ish-ness of the channels) is in the BETA, I can send this out to you when I add you to the list.
I've been playing a bit more with PropForth and converting some Spin projects I have done in the past just for the hell of it and to compare the results. It's also a learning exercise so I can get into the guts of PropForth. I have included a screenshot of my development environment on my laptop. This is but one screen/desktop of many but what's interesting is that if you look at the green window you will see it's a standard Linux terminal but with 5 tabs open each running a copy of Minicom talking via Bluetooth to various Prop boards.I just copy&paste from the editor in the background or type directly into the terminal to update my code and all this with nothing plugged into my laptop. How liberating! In fact if I move to the other end of the house with the laptop I can still communicate with the Props in the workshop.
BTW, I'm running LinuxMint 12&13 with Cinnamon desktop and multiple desktops/screens are devoted to things such as: Firefox (about 300 tabs in various groups open), Datasheets, Programming (this one), VirtualBox running WINXP in fullscreen, etc
With all this talk of a liberating Propeller experience, you won't be taken seriously and be banished to the ....oops, forgot which thread I was in!!
The bluetooth connectivity is very cool!! Are production copies of your bluetooth board available yet? I can see these being very handy for us stuck on Forth Island!!
Thank for the reply.
I found also the paralax demo bord.
Can I use this also for propforth?
Enaugh memmory?
Jan
Propforth will run on ANY prop chip. Any hardware can be added as extensions to the kernel. Special optimized extended kernels have been added for extra EEPROM for file system, SD for file system, and others can be added as needed.
The minimum to boot propforth is 1 EEPROM of 32k. The minimum to use EEPROM as storage is 1 EEPROM of 64K. If you need more memory, you can add RAM chips if you want to to the work (we haven't found the need yet), the easiest way is to use SD as "main memory", (in addition to using th SD as storage), but you have to structure a little differently to keep it reasonable. Demooard has 32k EEPROM so maybe your best bet is to use the SD kernel. PropForthSDFastSerialKernel.spin
Show us you application requirements and we can work out a nice way to get it done.
Thanks again.
I wont to used it for controlling a digital railroad (marklin digital)
More prosesses to run to control the railroad.
I need speed, memmory and vga output, keyboard.
So I think to start with a C3.
Wat are you thinking about this?
Modified my decompiler to build a table of forward and backward references as it decompiles but while the output is disconnected and then on the second pass it can use the table to insert "begin" and "then" etc. I will include switches in the command to allow source-mode or address formated output. The decompiler is still a mish-mash for the moment but here's what the output looks like in source mode.
decomp parse
: parse
padsize >in W@ <=
if 0 else dup _lc C! 0
begin 2dup pad>in + C@ tuck =
if drop -1 else 007E =
if dup pad>in + dup 1+ 0003 2dup xisnumber
if xnumber over C! over 0
do dup C@ over 0003 + C! 1- (loop) drop 0003 >in
W+! else 3drop
then
1+ 0
then
until
then
nip
;
decomp _fsread
: _fsread
_fsfind dup
if dup t0 0003 _fsrd t1 C@ + 2+ 1+ t0
W@ bounds
do fsps i fsps 1- and - ibound i -
min i pad 0002 ST@ _fsrd pad over .str (+loop) else
drop
then
padbl
;
... controlling a digital railroad (marklin digital)
I need speed, memory and vga output, keyboard.
So I think to start with a C3.
If you have a C3 already, that would be great and it has room for expansion.
If you don't have a C3 already, the prop demo board would be fine. It has same as C3, expect the additional RAM etc, drivers for these are not yet implemented in propforth but they are easy. But you can put an SD on an Demoboard and get very similar to C3, at least in propforth.
Went to UPEC yesterday, had a great time. Except when I demo'd the great and wonderful Regression Test automation.
The Go-channels, did not work, and the regression automation did not work.
This morning, in the lab, it worked just fine. With no changes. Turns out someone forgot the step to set up the paths in windows. AND I forgot that the wired Ethernet port was configured to the brainolab router, and not for the demo; I should have given out the WIRELESS IP address for folks to telnet to. This is an example of the "DUH" in "Doug".
The bluetooth serial cable replacement (with the $6 modules on ebay that everyone is talking about) works so well that Sal is adding it to the standard test bed configuration.
The only problem is keeping track of the various possible connections, now we get to choose from many more than previously. Sal is going to try to bbreak it into "modiule options". This means that the "standard" will now have "modules" so each user can configure if they have bluetooth, ethernet, RTC, SD, etc.
The result will be that the entire automation will be controlled from one configuration file. We will set up where we keep propforth, if we have GO where it is installed, and the various hardware for each configuration to be tested. But aside from that file, all the rest should remain the same. And propfoth will continue to run on any propchip, regardless of what other hardwares present. We hope.
Sal has found some little bugs, mostly with the script timeouts. The ALPHA had timeout hard coded in the scripts, some we too short and the test would move on and results got skipped. So Sal is putting in a periodic "keep-alive" output, maybe and old command line spinner, to show that the function didn't die (and if the spinner stops spinning, the automation can detected it and flag it right away).
I should have the bluetooth hardware and a new rev of the alpha or maybe a beta by next week or the week after.
Here's the code (UPDATED) for the enhanced decompiler that can present the code back in source code form ready for editing etc. It still includes all the hex addresses etc if you want just by setting the level of detail such as "-1 detail" to enable all.
In Forth some parts of the control structures are used by the "compiler" but not compiled so they cannot be decompiled. However the missing structure can be inferred by forward and backward references. To do this requires processing and building up a table of references on a first pass and then using this information for a second pass. The output of the first pass is suppressed while it builds it's reference table and re-enabled for the second pass. So such words as "begin" and "then" show up in the decompiled listing as they were in the original source. I may yet add some more improvements but reconstructing comments is just that little bit harder
Here's a sample of the default output:
decomp parse
: parse
padsize >in W@ <=
if 0 else dup _lc C! 0
begin 2dup pad>in + C@ tuck =
if drop -1 else 007E =
if dup pad>in + dup 1+ 0003 2dup xisnumber
if xnumber over C! over 0
do dup C@ over 0003 + C! 1- loop
drop 0003 >in W+! else 3drop then
1+ 0 then
until
then
nip
;
Hi Caskaz,
I just went and checked on a Windows machine via Bluetooth and there was no problem pasting through TeraTerm. But when I tried to send the file it spat out errors. Looks like the editor I was using decided to use line-feeds for new lines rather than the standard CRLF. Forth looks for a CR to process the line. I will update the file shortly.
line-feeds for new lines rather than the standard CRLF. Forth looks for a CR to process the line. I will update the file shortly.
BTW, just got my Raspberry Pi, finally!
Hey guys! This looks really cool. RE: reconstruction comments: This might not be a joke.
They did something with locating the original source in earlier versions of forth.
For example:
If the source code is on the SD or EEPROM, this could be indicated with a flag or variable
0= no source, 1 = EEPROM, 2 = SD, etc.
If another variable contains the pointer to file (i guess there would be a list of file pointers to choose from)
the file could be scanned for the original source. Hmmm, now its starting to get complicated, maybe it is a joke after all.
I guess it depends on how much time it available to mess with it.
Note: Sal did not opt to put source pointers in the dictionary definitions (due to space considerations).
But these could be kept in external table(s) that are rebuilt from the current source tree. Ok, now its really getting crazy, even for me.
RE: Raspberry Pi: Have you thought about trying the GO language on it? I haven't gotten mine yet, but when I looked it seemed possible.
Comments
Here, we'll write it in secret code and nobody will know:
: goforth* go forth * dup . ; ( -- n1 )
thank you, you made me start my day happy ...
Enjoy!
Mike
We should have a test automation alpha together by next week. So far, the automation consistently recreates exact duplicates for each kernel for each run, so the automation only needs to check for differences. RTC and IP testing still need to be implemented, these will require multiple IP and serial channels.
A full build and test cycle now is taking about 40 minutes, and requires no intervention.
Issue 154 Stack Underflow was analyzed and a fix found, this should be in next release.
When automation is complete, it will be much easier to create and test new kernel variations. We could be looking at a July release. At that point, we will bring the previous library of extensions up to version 5.
Got the alpha for v5.3 with really cool test automation. It is not necessarily limited to propforth, it should be applicable to any spin code that can output text.
This is how it works:
FORTH is an interpreter at the command line. Text coming in is numbers placed on the stack, command works that are executed, or new definitions that are compiled into the dictionary. Input can come from the command line, or from a file. So any file can contain new definitions, or a list of words to execute, and can be used as a script.
On the PC side, Sal has started the single channel GoTerm terminal program. It now has two modes that can be toggled between terminal mode and command mode. Terminal mode is the regular terminal emulator, command mode runs PC side command functions. The command mode controls sending source and binary files from the PC to the prop, and capturing test and binary files from the prop, as well as executing programs on the PC. So the PC also runs scripts,and captures the output to log files.
On the Prop side, we use the previously established "standard test bed hardware" consisting of a protoboard (or similar) a bare propchip on a breadboard connected with 5 wires and some passives (or similar) and a spinneret (or similar). There is a single USB cable to a propplug on the protoboard. (Later the multichannel version will allow more physical connections, but for now we can talk directly to all 23 cogs and have channels to spare, so its adequate for the alpha).
The automation build function uses PROPELLANT executable to compile spin programs. For example, there is a an assembler module that is the basis for all the optimized propforth kernels. This and various support modules for SD, EEPROM file system, Ethernet, etc are combined to make the various kernels. Sal reports that its almost trivial to kick out a new custom kernel (for him at least, I haven't started on the process documentation yet).
The automation has a test execution function that loads all the kernels and launches all the tests. It records the outputs and logs them to files, and compares the current output with the previous "known good" output, and flags any differences. The timestamps and independent operating frequencies are always different, and the rest (compilation binary results, test results, etc) are always identical for the same set of code. So any differences should be predicable for any set of changes, and anything else is something to check out.
Because of the command mode, we can capture any interaction between the PC (the user) and the prop, and make it into another test. This allows creation of tests for everything, and immediate regression test and evaluation after any change. So keeping the "known good" results up to date is simple and timely.
To summarize, the automation compiles the spin code, and runs it on the prop(s), and checks if the results are the same as last time. All the things that are not expected to change are regression tests, and all the things that do change can be easily identified and checked for correctness, and added to the regression part.
In the alpha, Sal created a new kernel with some arbitrary set of functions, (I think it was the IP stuff). The automation worked, the results were correct and repeatable (identical on subsequent runs). The entire test cycle has been reduced from several weeks to under 40 minutes (for a clean run that has no errors), and is initiated with a single command on the PC. We anticipate adding a test for EVERYTHING, and lots of new custom kernels, and just let the rig run over night.
This might be useful to folks that like to test to requirements with predicable results.
The first pass of shaking down the automation may take some time, afterwards we think the pace of development and quality of work will increase.
I am new on this forum. I am active on this moment with the amForth on the Arduino platform.
At this moment I wait for my P8X32A Quickstart board.
I'v seen on the internet a series of expansion boards for the P8X32A
Is this a good choice to start with the propeller and propForth?
Cheers
Jan Kromhout
Hellevoetsluis-NL
Quickstart is the least expensive, easiest option to get started. There is a less expensive option, to get a bare prop chip ($8) and a breadboard, but this assumes you have a 3.3v regulator and 64K EEPROM, etc, in you parts box; if you don't have the spare parts then I recommend the Quickstart.
The expansion boards are not necessary until there is a specific project that needs to be soldered, for example an A/D project. In the mean time, I would recommend a simple bread board, these have been suitable for all my experiments so far.
Also, if you have a micro SD and a microSD to regular SD adapter, you can make an SD slot by adding a couple resistors per http://code.google.com/p/propforth/wiki/PropToSDconnection.
You are just in time, the really interesting stuff is coming out in the next release, v5.3 which should be in a couple weeks.
Here's the output when I get it to decompile the word "serial"
This is the decompiler code, I haven't tried to optimize it yet and it is incomplete but sufficient for the moment.
fl [ifdef Decompiler forget Decompiler ] : Decompiler ; hex ' exit constant #exit ' litw constant #litw ' litl constant #litl ' (+loop) constant #+loop ' (loop) constant #loop ' 0branch constant #0branch ' branch constant #branch ' cq constant #cq ' dq constant #dq : .line dup cr .word ." : " ; : .name dup 1+ swap C@ 1F and bounds do i C@ emit loop ; : .ext \ ( adr word -- adr ) dup #litl = if drop 2+ alignl dup L@ space .long 2+ exit then dup #litw = if drop 2+ dup W@ space .word exit then dup #loop = over #+loop = or over #0branch = or over #branch = or if drop 2+ dup W@ over + ." >" .word exit then dup #cq = over #dq = or if drop space 22 emit space 2+ dup .cstr 22 emit dup C@ 1- + exit then drop ; : decomp \ use in the form "decomp name" or --> ' name decomp ' dup 0= if drop then \ assume parameter has been passed on stack rather than in line hex begin .line dup W@ pfa>nfa .name dup W@ .ext dup 2+ alignw swap W@ #exit = fkey? drop 1B = or \ force stop on escape key until cr drop ;So could we have a quick show of hands as to who is working on a project with PropForth at present?
1) CSP channels between PC and PropForth
2) Propforth socket extensions to PC based MinForth to allow transparent access to Propeller via MinForth words.
3) Multi-Prop PropForth
4) PropForth word indexer (start of PC based IDE for PropForth)
5) learning, always learning.....
6) Propforth support for various Parallax sensors (always on the platter, never gets worked on)
Probably more but I've forgotten them........for now!
Thanks for the decompiler, that should be fun to play with.
But if I ever get the time, I have dreams of finishing the spider and the hand I've been working on. First we have to finish the CNC, parallel stuff example, the Jupiter ACE II, and a bunch of other stuff buried under those.
I re-write wordDump from PF4.0a to PF5.0.
I will re-make this later because of imcomplete.
decomp else 2244: $C_a_branch 2246: w, 2248: 0 224A: w, 224C: dothen 224E: here 2250: W@ 2252: 2- 2254: litw 1239 2258: w>l 225A: exitAlso you seem to have hardcoded the addresses for the constant instead of just using Forth to find them for you using '
I have noticed that the kernel has made sacrifices for what can run from the Forth COG in PASM because even stack words such as rot and swap are colon definitions and if they were used a bit inside a loop they would certainly slow things down. Normally these common stack operations etc are written in assembly and are quite fast. It would be nice if they were written in PASM but COGs were designed to run light and tight in their 512 longs and Sal has done a marvelous job in doing what he has done with adapting Forth for the Prop. If only Prop's had another COG that was an ARM
decomp swap 0FF8: 1 0FFA: ST@ 0FFC: 1 0FFE: ST@ 1000: 2 1002: ST! 1004: 0 1006: ST! 1008: exit Prop0 Cog6 ok decomp rot 0F80: litw 0002 0F84: ST@ 0F86: litw 0002 0F8A: ST@ 0F8C: litw 0002 0F90: ST@ 0F92: litw 0003 0F96: ST! 0F98: litw 0003 0F9C: ST! 0F9E: 0 0FA0: ST! 0FA2: exitNow, I've heard mentioned of these Multichannel Serial Communications, is there any more information about this? I want to see if I can use this and what I might have to do in hardware to make that possible. It may also be that this rack has an ARM processor or even a Raspberry Pi so if that's the case then GO may be the way to go and I need to learn a little bit more about that (I'm a quick study).
If I understand your intent:
In general, if you want something to run "in a cog" (a special function and not a word from the common forth dictionary), it would be in assembler. This is not a sacrifice, this is the design. We wouldn't be using the colon definition for 'rot', we would strip out the overhead that is slowing it down and just use the assembler sequence that does what we want. The assembly routine only needs to conform to forth when it is called and when it exits.
And one can add another processor that is an ARM (or anything else), if one implements the GO channel interface on that , as done on the PC in goterm & gomuxterm. The current path includes Cortex-M3 (I think) but non-prop work only makes it to Sal's list indirectly.
Is there some documentation on MSC stuff and how do I get to be one of the propforth group committers?
Sorry dude, I thought I added you to the list months ago. Please PM me with your gmail address and I can add you to the contributors list. I think other email addresses work, but I think gmail addresses work better.
The released multichannel serial material is "completely" demonstrated in the tutorials in
\Propforth-5.xx-yyyymmdd\kernels\doc\tutorials
in files
tutorial-3.3 MCS Loopack.txt
tutorial-7.3 MCS+NoROM.txt
BUT (for now) we have to work thru the tutorials from 1.0 up to 7.3 to run those tests. The tests demonstrate the proper usage and functions of the propforth kernel functions, to the best of our knowledge.
The GO channels (CSP stuff although some folks dispute the CSP-ish-ness of the channels) is in the BETA, I can send this out to you when I add you to the list.
BTW, I'm running LinuxMint 12&13 with Cinnamon desktop and multiple desktops/screens are devoted to things such as: Firefox (about 300 tabs in various groups open), Datasheets, Programming (this one), VirtualBox running WINXP in fullscreen, etc
With all this talk of a liberating Propeller experience, you won't be taken seriously and be banished to the ....oops, forgot which thread I was in!!
The bluetooth connectivity is very cool!! Are production copies of your bluetooth board available yet? I can see these being very handy for us stuck on Forth Island!!
I found also the paralax demo bord.
Can I use this also for propforth?
Enaugh memmory?
Jan
Propforth will run on ANY prop chip. Any hardware can be added as extensions to the kernel. Special optimized extended kernels have been added for extra EEPROM for file system, SD for file system, and others can be added as needed.
The minimum to boot propforth is 1 EEPROM of 32k. The minimum to use EEPROM as storage is 1 EEPROM of 64K. If you need more memory, you can add RAM chips if you want to to the work (we haven't found the need yet), the easiest way is to use SD as "main memory", (in addition to using th SD as storage), but you have to structure a little differently to keep it reasonable. Demooard has 32k EEPROM so maybe your best bet is to use the SD kernel. PropForthSDFastSerialKernel.spin
Show us you application requirements and we can work out a nice way to get it done.
I wont to used it for controlling a digital railroad (marklin digital)
More prosesses to run to control the railroad.
I need speed, memmory and vga output, keyboard.
So I think to start with a C3.
Wat are you thinking about this?
Thanks for any advice.
Cheers.
Jan
Maybe a QuickStart board with this from Gadget Gangster http://www.gadgetgangster.com/find-a-project/56.html?projectnum=402
It has most of the features you need plus about 1/2 the cost. It doesn't have the SRAM or flash like the C3 but supports an add on SD module.
http://www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/CategoryID/73/List/0/Level/a/ProductID/425/Default.aspx?SortField=ProductName%2cProductName
Still missing the SD adapter, but you have a lot of room left and easy pin access. The protoboard is not USB powered unless you mod it.
The non USB version requires the prop plug.
Massimo
decomp parse : parse padsize >in W@ <= if 0 else dup _lc C! 0 begin 2dup pad>in + C@ tuck = if drop -1 else 007E = if dup pad>in + dup 1+ 0003 2dup xisnumber if xnumber over C! over 0 do dup C@ over 0003 + C! 1- (loop) drop 0003 >in W+! else 3drop then 1+ 0 then until then nip ; decomp _fsread : _fsread _fsfind dup if dup t0 0003 _fsrd t1 C@ + 2+ 1+ t0 W@ bounds do fsps i fsps 1- and - ibound i - min i pad 0002 ST@ _fsrd pad over .str (+loop) else drop then padbl ;If you have a C3 already, that would be great and it has room for expansion.
If you don't have a C3 already, the prop demo board would be fine. It has same as C3, expect the additional RAM etc, drivers for these are not yet implemented in propforth but they are easy. But you can put an SD on an Demoboard and get very similar to C3, at least in propforth.
The Go-channels, did not work, and the regression automation did not work.
This morning, in the lab, it worked just fine. With no changes. Turns out someone forgot the step to set up the paths in windows. AND I forgot that the wired Ethernet port was configured to the brainolab router, and not for the demo; I should have given out the WIRELESS IP address for folks to telnet to. This is an example of the "DUH" in "Doug".
Aside from that, the presentation went smoothly.
The bluetooth serial cable replacement (with the $6 modules on ebay that everyone is talking about) works so well that Sal is adding it to the standard test bed configuration.
The only problem is keeping track of the various possible connections, now we get to choose from many more than previously. Sal is going to try to bbreak it into "modiule options". This means that the "standard" will now have "modules" so each user can configure if they have bluetooth, ethernet, RTC, SD, etc.
The result will be that the entire automation will be controlled from one configuration file. We will set up where we keep propforth, if we have GO where it is installed, and the various hardware for each configuration to be tested. But aside from that file, all the rest should remain the same. And propfoth will continue to run on any propchip, regardless of what other hardwares present. We hope.
Sal has found some little bugs, mostly with the script timeouts. The ALPHA had timeout hard coded in the scripts, some we too short and the test would move on and results got skipped. So Sal is putting in a periodic "keep-alive" output, maybe and old command line spinner, to show that the function didn't die (and if the spinner stops spinning, the automation can detected it and flag it right away).
I should have the bluetooth hardware and a new rev of the alpha or maybe a beta by next week or the week after.
In Forth some parts of the control structures are used by the "compiler" but not compiled so they cannot be decompiled. However the missing structure can be inferred by forward and backward references. To do this requires processing and building up a table of references on a first pass and then using this information for a second pass. The output of the first pass is suppressed while it builds it's reference table and re-enabled for the second pass. So such words as "begin" and "then" show up in the decompiled listing as they were in the original source. I may yet add some more improvements but reconstructing comments is just that little bit harder
Here's a sample of the default output:
decomp parse : parse padsize >in W@ <= if 0 else dup _lc C! 0 begin 2dup pad>in + C@ tuck = if drop -1 else 007E = if dup pad>in + dup 1+ 0003 2dup xisnumber if xnumber over C! over 0 do dup C@ over 0003 + C! 1- loop drop 0003 >in W+! else 3drop then 1+ 0 then until then nip ;I tried your Decomp.fth and decomp V2.fth.
It operate finely both in case of copy/paste.
When loading from TeraTerm(using "send file"), it can't load.
I often load file from TeraTerm.
Generally it is ok.
But,Somtimes loading-error is caused by some files.
Why cause this?
I just went and checked on a Windows machine via Bluetooth and there was no problem pasting through TeraTerm. But when I tried to send the file it spat out errors. Looks like the editor I was using decided to use line-feeds for new lines rather than the standard CRLF. Forth looks for a CR to process the line. I will update the file shortly.
BTW, just got my Raspberry Pi, finally!
Hey guys! This looks really cool. RE: reconstruction comments: This might not be a joke.
They did something with locating the original source in earlier versions of forth.
For example:
If the source code is on the SD or EEPROM, this could be indicated with a flag or variable
0= no source, 1 = EEPROM, 2 = SD, etc.
If another variable contains the pointer to file (i guess there would be a list of file pointers to choose from)
the file could be scanned for the original source. Hmmm, now its starting to get complicated, maybe it is a joke after all.
I guess it depends on how much time it available to mess with it.
Note: Sal did not opt to put source pointers in the dictionary definitions (due to space considerations).
But these could be kept in external table(s) that are rebuilt from the current source tree. Ok, now its really getting crazy, even for me.
RE: Raspberry Pi: Have you thought about trying the GO language on it? I haven't gotten mine yet, but when I looked it seemed possible.