I've noticed something odd that happens when I mistype something in Propforth and hit backspace. The word looks correct in the terminal window, but when I hit return Propforth says that it doesn't understand the word. In addition there's a junk value deposited on the stack that I need to pop off. I consulted the documents, but I don't know why this happens, or if there's a way to correct typos.
I've noticed something odd that happens when I mistype something in Propforth and hit backspace. The word looks correct in the terminal window, but when I hit return Propforth says that it doesn't understand the word. In addition there's a junk value deposited on the stack that I need to pop off. I consulted the documents, but I don't know why this happens, or if there's a way to correct typos.
There is a bug in the interpret routine, when it doesn't find a match (word definition or number) it leaves junk on the stack. This has already been detected and will be fixed in the next release. Just do "sc" for stack clear to clear the stack after any typo. This does not affect anything in a working app, its just a nuisance during debug.
As far as the backspace, what terminal emulator are you using? Tera term works fine (for me at least), but over bluetooth, the free android app BLUETERM does not implement backspace correctly. The paid version of blueterm is required if proper backspace is needed, so we use the Sal's Android GREEN.apk when we need the backspace to work over bluetooth.
There is a bug in the interpret routine, when it doesn't find a match (word definition or number) it leaves junk on the stack. This has already been detected and will be fixed in the next release. Just do "sc" for stack clear to clear the stack after any typo. This does not affect anything in a working app, its just a nuisance during debug.
As far as the backspace, what terminal emulator are you using? Tera term works fine (for me at least), but over bluetooth, the free android app BLUETERM does not implement backspace correctly. The paid version of blueterm is required if proper backspace is needed, so we use the Sal's Android GREEN.apk when we need the backspace to work over bluetooth.
IIRC I've found that if you install "Terminal IDE" keyboard that the backspace works correctly, as does other keys.Anyway, the thing is that the issue is with the keyboard and not so much Blueterm as the same issues occur with Telnet.
IIRC I've found that if you install "Terminal IDE" keyboard that the backspace works correctly, as does other keys.Anyway, the thing is that the issue is with the keyboard and not so much Blueterm as the same issues occur with Telnet.
So, the blue term issue is the key board, thanks, this has been bugging me since my first HC06 experiments.
I'm using PuTTY which works pretty well when connecting to remote hosts at work.
I'm using teraterrm on windows and minicom and picocom on linux, and the back space fuctions correctly on these. Could there be something to configure in PuTTY?
SD Logger has been running 1 per second for weeks. It can do 20 per second easily, but measurement time and record size needs to be taken into account. The most Sal did was 50 per second probablly. PF6 with queuing can go higher. In PF6, the load balances completely, all cogs going full bore.
There have been many different systems for load balancing over the years. Propforth rips off all the applicable parts of those and makes it work well. Sal says there probably isn't anything thats new about this method of load balancing, he just assembled known parts in an appropriate way.
Maybe tthe anly thing different about proforth is the way the team approach. There's no commercial pressures (deadlines, marketing driven features etc), yet we still preform thorough testing through automation.
I noticed an issue running pf5.5 on the machine I used to do 5.3 build and test. It might be that the PC can't keep up with the 230400 baud transfer. PF6 will have synchronous serial, so this will no longer be an issue next release.
There is a request for auto-time correction for the logger. Issue 212 asks that the ds1302 RTC autocorrect be brought to time.f. Also that time auto correct support be implemented as an optional script in Goterm.
Issue 211 is opened requesting the SD kernel to interface to Goterm. Seems we only used the regualr dev kernel for the automation, so the other kernels never implemented the Goterm interface.
Issue 210 is about the Logger2 new daily logfile. When the day rolls over, a new long file is created; the single logfile was getting huge and getting at the data cumbersome. I thought I was seeing the new logfile create happening early, perhaps from UTC midnight instead of local time midnight. Sal doesn't see that happening in the code, so maybe I'm seeing things, I will do more testing. If anybody has noticed this please let me know.
We talk a bit about the Android program GREEN.apk. We have not done anything to move this forwad for a while. There aren't so many folks exploring an Android interface to forth. The question is "What kind of interface do we want for our embedded system?". At present, Green will load scripts from propforth, and present these as macro buttons. It already supports touch buttons and things like joy stick areas. But we have to define the macros we want to present, and the layout for the presentation. Green is not so such for application development, rather is for development and presentation of the final app's interface. If we can define the functions we want, Geen can present a bunch of buttons as shortcuts to those. Sal uses it for his interface to propforth apps, but I don't think many other have tried it.
I tried to run this simple piece of code, which sends "cmd" bits via SPI
fl
variable cmd
\ p16: data; p17: clk (falling edge)
: init 2 0 do 16 i + pinout loop b1000_1111_0101_1111_0000_1111_0000_1111 cmd L! ;
: spi_hi 16 pinhi 17 pinhi 17 pinlo 17 pinhi ;
: spi_low 16 pinlo 17 pinhi 17 pinlo 17 pinhi ;
: send_cmd cmd L@ 16 0 do dup i lshift h80000000 and if spi_hi else spi_low then loop drop ;
: run begin send_cmd 100 delms 0 until ;
init
\ send_cmd
\ run
It works fine if I uncomment "run" and paste the whole thing into Tera Term. If I paste in the code as it is (after reset), and try to type "run" in Tera Term afterwards, nothing happens. ( I am using latest version of PropForth.)
I tried to run this simple piece of code, which sends "cmd" bits via SPI
It works fine if I uncomment "run" and paste the whole thing into Tera Term. If I paste in the code as it is (after reset), and try to type "run" in Tera Term afterwards, nothing happens. ( I am using latest version of PropForth.)
Am I missing something here?
I think you are missing the ... that terminates the fl
fl sends the input stream to another free cog, so we don't have to mess with buffers and over run etc. The other forths do something else, at a cost of more support in the kernel, or more gyrations on the part of the developer during development. the fl ... loading construct should go away when we move to propforth 6, but PF 6 won't re leases until it has been tested on the prop 2, which is not yet available.
I'm not in the lab so I could not test it, but please try the following, it is identical except for the ... at the end.
fl
variable cmd
\ p16: data; p17: clk (falling edge)
: init 2 0 do 16 i + pinout loop b1000_1111_0101_1111_0000_1111_0000_1111 cmd L! ;
: spi_hi 16 pinhi 17 pinhi 17 pinlo 17 pinhi ;
: spi_low 16 pinlo 17 pinhi 17 pinlo 17 pinhi ;
: send_cmd cmd L@ 16 0 do dup i lshift h80000000 and if spi_hi else spi_low then loop drop ;
: run begin send_cmd 100 delms 0 until ;
init
\ send_cmd
\ run
...
\ dont forget the ...
Doug, I'm pretty sure that the "..." characters are not needed, unless Sal has added something to fl in the past 5 months. I looked at the source for the fl word, and posted my comments in post #198 of this thread. It seems that the fl mode is exited when a character hasn't been received for a certain timeout period. I couldn't find any reference in the code to "..." being used to terminate fl.
I suspect that iam's problem is because the fl word is interpreted in a different cog than the normal interpreter. I believe the init and run words should be run in the same cog, so they should either be both uncommented, or they should be both commented and then run manually after fl is done.
This monitor voltage of resistor(0.1ohm) for USB-device.
Vbus
USBdevice's Vbus
GND--0.1ohm
USB GND
This display USB-actual-current[unit:mA] and total-current[unit:Ahour].
This code is Not yet 'saveforth'.
I will upload curcuit-diagram and final code lator.
1. Insert USB-Current-Monitor to PC's USB-port otr USB-Hub.
2. USB-Current-Monitor adjust zero for amp.
3. Display actual current when inserting USB-device.
4. When pushed sw, total-current is displayed.
When adding word'onreset', it seems word'forget' cannot use.
Loading below, word'test' cannot do 'forget test'.
Freespace don't be small.
d13 wconstant current
: test current pinout begin current pinhi d100 delms current pinlo d100 delms fkey? swap drop until ;
: onreset2 onreset test ;
saveforth
reboot
\ free ( -- ) display free main bytes and current cog longs
[ifndef free
: free
dictend W@ here W@ - . ." bytes free - " par coghere W@ - . ." cog longs free" cr
;
]
Before do 'saveforth' USB_Current_Monitor_0.3.f
dictend W@ .
32660 Prop0 Cog6 ok
here W@
19478 Prop0 Cog6 ok
After do 'saveforth' USB_Current_Monitor_0.3.f
dictend W@ .
24290 Prop0 Cog6 ok
here W@ .
19478 Prop0 Cog6 ok
I mentioned Martin's comment that the forth code is slower than the C version. Sal responded:
This is a good example of the first stage of forth development. Now that the forth code is working, the code can be optimized. One example is the ASR word. In forth this has a do--loop, this will of course be very slow. The ASR is already implemented in assembler, and has been optimized. Switching to an assembler version of any word that is expensive or called often is a good start at optimization. Sometimes significant percent of execution happens in a small percent of the code, if these areas can be optimized, large payoff can be gained.
This might be a candidate for an optimization example. (if Martin is interested).
* Iammegatron's initialization question from post #369; and Caskaz's savefort/forget question from post #374:
fl (source code Fast Load) is a method to load source code into the interpreter (and so into the propforth dictionary) by buffering into a free cog. This eliminates the need for flow control (which is problematic, since we don't how or if its implemented on the PC) and/or delays in the terminal program (since we don't know if the user can set these properly).
fl provides a separate cog as an input buffer for the incoming source stream.
Performing initialization in fl means the code is initialize on that cog (e.g. cog3), not on the teminal cog (i.e. cog6). This is a powerful design feature.
fl has memory allocated. If saveforth is performed inside fl, the memory allocation (in the other cogs) is saved!
We must let fl release the memory before trying the saveforth.
So fl requires care, let fl finish before doing saveforth; and take carre to perform initialization on the cog that needs it.
Sal hates fl because this, this is why hes getting rid of it in PF6.
PF6 may have support to determine "Am I initialize on THIS cog?" which would address Iammegaon's issue.
PF6 will include advanced flow control which will eliminate fl which will resolve Caskaz's issue.
* PF6 release cycle is starting. There's a LOT of documentaion to do. PF6 will start with PF5.5 and Go installed on a windows box. We will not add linux support until windows is finished, to eliminate unknowns.The new testbad hardware configuration will separated by hardware.
Build - The build automation will start with a generic configuration tha will run on ANY prop, if you can talk tto the prop, you can do the build.
Test - The test automation will have a section of general tests that run on all hardware,
the remaining remaining tests have specific hardware prerequisites.
So, PF6 should be much eaiser to test just the peices that are underinvestigation, without having to run the whjole show every time.
DEMOS - we are concidering demos for PF6 capabilities. The original driver for PF6 was complex control with several times more tasks than cogs. This would have made a fine demo, but unfortunately it can't be made public.
So here's what we are considering:
The first part could be to present PF6 as a continuation of PF5.5, as in, "here's how we do all the previous stuff"
The second part could to show the new fancy PF6 multitasks and load balancing
Aside from the automated build and test (which is pretty darn cool by itself) we have several options
* data logger (time stamps, SD log files, many records)
* perhaps a simple game with sprites
* a new LittleRobot Demo
* FFT - Sal will used fixed point math rather than float in software. What should FFT be used for in a demo?
* something along the lines of Martin's SCARA arm.
Sal decided NOT to do any RepRap CNC implementation on the prop. The existing Reprap support using Arduino is fine as it is, and does not need the extra cores or speed.
My GO ( travel )
I now have a running system to Windows 8 and Windows 7
There was nothing wrong with the operating system and GO.
It was just me who did not fully understand what happened.
Over the summer I have read and tested GO , to understand it.
My goal was to run 10 tests through without errors.
In Windows 8 , there were random errors .
On Windows 7, there was constant error .
So it was on Windows 7, I made changes in windows_serial.go
and cogCommandProcessor.go .
As the test went well on Windows 7, I copied the files to Windows 8
and repeated the test there. I've only tested up to but not dosnettest.bat
My test system is :
G / G Propeller Platform
USB Propeller Plug
Windows 8 ASUS SonicMaster Intel CPU I3-3217U@1.80GHz 1.80GHz RAM 6GB 64- bit operating system
Windows 7 ASUS Eee PC Intel Atom CPU D525@1.80GHz 1.80GHz RAM 2GB 32- bit operating system
Now I started with testing on Linux UBUNTU 13.10 on my SonicMaster and
on a LUBUNTU 13.10 on a simple core Intel CPU@2.6GHz RAM 0.5GB 32- bit operating system
Test runs fine with domake.sh , the next will be dotest.sh
There was nothing wrong with the operating system and GO.
It was just me who did not fully understand what happened.
...
My goal was to run 10 tests through without errors.
In Windows 8 , there were random errors .
On Windows 7, there was constant error .
So it was on Windows 7, I made changes in windows_serial.go
and cogCommandProcessor.go .
As the test went well on Windows 7, I copied the files to Windows 8
and repeated the test there. I've only tested up to but not dosnettest.bat
My test system is :
Windows 8 ASUS SonicMaster Intel CPU I3-3217U@1.80GHz 1.80GHz RAM 6GB 64- bit operating system
Windows 7 ASUS Eee PC Intel Atom CPU D525@1.80GHz 1.80GHz RAM 2GB 32- bit operating system
Did you resolve all the errors? Sal has cautioned that on the slower windows machines, the serial port might not keep up at 230400 baud. My 1.6 Ghz test system is fine for PF5.3, but will not set the prop "listening" on PF5.5. I should be able to set the baud back to 56700 and make it work. However, I did not test it yet, too many other fish to fry.
Loading from 'fl' to ': onreset2 onreset USB_current ;'.
After that, doing 'saveforth'.
Trouble has gone about 'free' mistake.
But it cannot do 'forget USB_Current_Monitor'.
When executing ': onreset2 onreset USB_current ;', 'forget' cannot use.
This is bug or PropForth's specificasion?
Loading from 'fl' to ': onreset2 onreset USB_current ;'.
After that, doing 'saveforth'.
But it cannot do 'forget USB_Current_Monitor'.
When executing ': onreset2 onreset USB_current ;', 'forget' cannot use.
This is bug or PropForth's specificasion?
I'm not able to try this at the moment...
So, are you doing
forget USB_Current_Monitor
and getting an error, or is USB_Current_Monitor not removed from the dictionary and the memory not released?
Which kernel are you using? It should be fine with devkernel, but saveforth required caution with SD or EEPROM file system kernels, it can behave badly.
We walked through PF6.0. We were surprised that the walkthrough only took one session, we had scheduled this activity to take at least three sessions.
PF6.0 has automatic multitasking and load balancing. It uses ideas from occam and go. Its totally simple from the user point of view, but requires a bit of understanding from the software designer point of view. The prop is treated as a pool of seven cogs (the eighth is the serial cog). A max of 128 tasks can be defined (more than 128 we run out of memory, and we can't do anything useful) and are in the demo. The next free cog takes the next task in the queue. The task executes one cycle, and the task goes to the end of the queue, and the cog goes back to the pool.
One of the tasks is the garabge collection task. When a task is marked (or marks itself) as terminated, the garbage collection task removes it from the queue. Any terminated tasks are removed in the next time the garabage collector runs.
If a given task is very slow or takes a long time, that cog is not available to the pool. Even so, the system capacity is only dinished by 1/7th. While this has minimal affect, we still have to be aware of how long each task will take.
With 128 tasks, each tasks gets a turn about every 696 milliseconds. So if we needed these tasks to be serviced more frequently, we would be late, and we would have to remove a few tasks. Sal has been running 20-30 tasks for various projects since last April. Fewer task means much less time to get through the queue (but I didn't get the numbers, we ran out of day light). His stress test was complex control and interesting numerical calculations, and the multitasker implementation is proving itself very suitable.
The PropForth 6.0 prototype is not yet available to the general public, it only has the build automaton. There are a couple decisions that stil have to be made. I'm only sending it to the team members that expressed interest; but I can send it out to any additional team members that are interested. (And if you want to join the team, send me a message). The current set of kernels are just the ones Sal was using, he will add the custom kernels and anything else we need for release.
PF6.0 totally rocks on the Prop 1. It should be 4x more awesome on the prop 2
I sent out the prototype to the folks that experssed interest. If you have not recieved it yet, message me with your proper email, I might have fumbled fingered an address.
There is [: onreset2 onreset USB_current ;] at last line in "USB_CUrrent_Monitor_0.3.f".
I did 'forget onreset2'. I also did 'c" onreset2" (forget)'.
But cannot.
After saving [: onreset2 onreset USB_current ;], any words cannot forget.
Last way is re-installing PropForth5.5.
There is [: onreset2 onreset USB_current ;] at last line in "USB_CUrrent_Monitor_0.3.f".
I did 'forget onreset2'. I also did 'c" onreset2" (forget)'.
But cannot.
After saving [: onreset2 onreset USB_current ;], any words cannot forget.
Last way is re-installing PropForth5.5.
This is bug or PropForth's specificasion?
Sorry, can't determine at this moment.
Could you open an issue, with the steps to reproduce the problem on a generic board, such as quickstart or protoboard?
Please separate out the current monitor portion, and only include the forget portion, so we reproduce the issue.
If we can reproduce the exact problem, Sal and I will go through it next Sunday, and look for an answer and possibly a solution.
Comments
There is a bug in the interpret routine, when it doesn't find a match (word definition or number) it leaves junk on the stack. This has already been detected and will be fixed in the next release. Just do "sc" for stack clear to clear the stack after any typo. This does not affect anything in a working app, its just a nuisance during debug.
As far as the backspace, what terminal emulator are you using? Tera term works fine (for me at least), but over bluetooth, the free android app BLUETERM does not implement backspace correctly. The paid version of blueterm is required if proper backspace is needed, so we use the Sal's Android GREEN.apk when we need the backspace to work over bluetooth.
IIRC I've found that if you install "Terminal IDE" keyboard that the backspace works correctly, as does other keys.Anyway, the thing is that the issue is with the keyboard and not so much Blueterm as the same issues occur with Telnet.
I'm using PuTTY which works pretty well when connecting to remote hosts at work.
So, the blue term issue is the key board, thanks, this has been bugging me since my first HC06 experiments.
I'm using teraterrm on windows and minicom and picocom on linux, and the back space fuctions correctly on these. Could there be something to configure in PuTTY?
Bingo, I found a configuration option to send ctrl-H versus the Windows backspace value.
SD Logger has been running 1 per second for weeks. It can do 20 per second easily, but measurement time and record size needs to be taken into account. The most Sal did was 50 per second probablly. PF6 with queuing can go higher. In PF6, the load balances completely, all cogs going full bore.
There have been many different systems for load balancing over the years. Propforth rips off all the applicable parts of those and makes it work well. Sal says there probably isn't anything thats new about this method of load balancing, he just assembled known parts in an appropriate way.
Maybe tthe anly thing different about proforth is the way the team approach. There's no commercial pressures (deadlines, marketing driven features etc), yet we still preform thorough testing through automation.
I noticed an issue running pf5.5 on the machine I used to do 5.3 build and test. It might be that the PC can't keep up with the 230400 baud transfer. PF6 will have synchronous serial, so this will no longer be an issue next release.
There is a request for auto-time correction for the logger. Issue 212 asks that the ds1302 RTC autocorrect be brought to time.f. Also that time auto correct support be implemented as an optional script in Goterm.
Issue 211 is opened requesting the SD kernel to interface to Goterm. Seems we only used the regualr dev kernel for the automation, so the other kernels never implemented the Goterm interface.
Issue 210 is about the Logger2 new daily logfile. When the day rolls over, a new long file is created; the single logfile was getting huge and getting at the data cumbersome. I thought I was seeing the new logfile create happening early, perhaps from UTC midnight instead of local time midnight. Sal doesn't see that happening in the code, so maybe I'm seeing things, I will do more testing. If anybody has noticed this please let me know.
We talk a bit about the Android program GREEN.apk. We have not done anything to move this forwad for a while. There aren't so many folks exploring an Android interface to forth. The question is "What kind of interface do we want for our embedded system?". At present, Green will load scripts from propforth, and present these as macro buttons. It already supports touch buttons and things like joy stick areas. But we have to define the macros we want to present, and the layout for the presentation. Green is not so such for application development, rather is for development and presentation of the final app's interface. If we can define the functions we want, Geen can present a bunch of buttons as shortcuts to those. Sal uses it for his interface to propforth apps, but I don't think many other have tried it.
It works fine if I uncomment "run" and paste the whole thing into Tera Term. If I paste in the code as it is (after reset), and try to type "run" in Tera Term afterwards, nothing happens. ( I am using latest version of PropForth.)
Am I missing something here?
I think you are missing the ... that terminates the fl
fl sends the input stream to another free cog, so we don't have to mess with buffers and over run etc. The other forths do something else, at a cost of more support in the kernel, or more gyrations on the part of the developer during development. the fl ... loading construct should go away when we move to propforth 6, but PF 6 won't re leases until it has been tested on the prop 2, which is not yet available.
I'm not in the lab so I could not test it, but please try the following, it is identical except for the ... at the end.
I suspect that iam's problem is because the fl word is interpreted in a different cog than the normal interpreter. I believe the init and run words should be run in the same cog, so they should either be both uncommented, or they should be both commented and then run manually after fl is done.
I built up USB-current-monitor.
This monitor voltage of resistor(0.1ohm) for USB-device.
Vbus
USBdevice's Vbus
GND--0.1ohm
USB GND
This display USB-actual-current[unit:mA] and total-current[unit:Ahour].
This code is Not yet 'saveforth'.
I will upload curcuit-diagram and final code lator.
What Dave said. I was confusing fl with "fwrite" (writes to SD file) which wants to see ...
init and run from the cog6 command line should do it.
1. Insert USB-Current-Monitor to PC's USB-port otr USB-Hub.
2. USB-Current-Monitor adjust zero for amp.
3. Display actual current when inserting USB-device.
4. When pushed sw, total-current is displayed. It seems USB-Current-Monitor operate finely.
But I found out strange.
FIRST;
I installed DevKernel.
Free-space is 15064bytes.
When loading from 'fl' to word'onreset2' for 'USB_Current_Monitor_0.2.f'.
Not 'saveforth'
But When Loading all 'USB_Current_Monitor_0.2.f', free-space is small.
After Executing saveforth;
SECOND;
Cannot do 'forget USB_Current_Monitor'.
I placed word'USB_Current_Monitor' on top line of'USB_Current_Monitor_0.2.f'.
It operate finely.
Why free-space become smaller?
Why cannot do 'forget USB_Current_Monitor'?
When adding word'onreset', it seems word'forget' cannot use.
Loading below, word'test' cannot do 'forget test'.
Freespace don't be small.
This is bug or PropForth's specification?
Update USB_Current_Monitor.
Modified 'bin_to_bcd'.
Why do dictend change?
I have no idea.
http://forums.parallax.com/showthread.php/151826-Scara-robot-using-servos-and-hardware-store-components
I mentioned Martin's comment that the forth code is slower than the C version. Sal responded:
This is a good example of the first stage of forth development. Now that the forth code is working, the code can be optimized. One example is the ASR word. In forth this has a do--loop, this will of course be very slow. The ASR is already implemented in assembler, and has been optimized. Switching to an assembler version of any word that is expensive or called often is a good start at optimization. Sometimes significant percent of execution happens in a small percent of the code, if these areas can be optimized, large payoff can be gained.
This might be a candidate for an optimization example. (if Martin is interested).
fl (source code Fast Load) is a method to load source code into the interpreter (and so into the propforth dictionary) by buffering into a free cog. This eliminates the need for flow control (which is problematic, since we don't how or if its implemented on the PC) and/or delays in the terminal program (since we don't know if the user can set these properly).
fl provides a separate cog as an input buffer for the incoming source stream.
Performing initialization in fl means the code is initialize on that cog (e.g. cog3), not on the teminal cog (i.e. cog6). This is a powerful design feature.
fl has memory allocated. If saveforth is performed inside fl, the memory allocation (in the other cogs) is saved!
We must let fl release the memory before trying the saveforth.
So fl requires care, let fl finish before doing saveforth; and take carre to perform initialization on the cog that needs it.
Sal hates fl because this, this is why hes getting rid of it in PF6.
PF6 may have support to determine "Am I initialize on THIS cog?" which would address Iammegaon's issue.
PF6 will include advanced flow control which will eliminate fl which will resolve Caskaz's issue.
* PF6 release cycle is starting. There's a LOT of documentaion to do. PF6 will start with PF5.5 and Go installed on a windows box. We will not add linux support until windows is finished, to eliminate unknowns.The new testbad hardware configuration will separated by hardware.
Build - The build automation will start with a generic configuration tha will run on ANY prop, if you can talk tto the prop, you can do the build.
Test - The test automation will have a section of general tests that run on all hardware,
the remaining remaining tests have specific hardware prerequisites.
So, PF6 should be much eaiser to test just the peices that are underinvestigation, without having to run the whjole show every time.
DEMOS - we are concidering demos for PF6 capabilities. The original driver for PF6 was complex control with several times more tasks than cogs. This would have made a fine demo, but unfortunately it can't be made public.
So here's what we are considering:
The first part could be to present PF6 as a continuation of PF5.5, as in, "here's how we do all the previous stuff"
The second part could to show the new fancy PF6 multitasks and load balancing
Aside from the automated build and test (which is pretty darn cool by itself) we have several options
* data logger (time stamps, SD log files, many records)
* perhaps a simple game with sprites
* a new LittleRobot Demo
* FFT - Sal will used fixed point math rather than float in software. What should FFT be used for in a demo?
* something along the lines of Martin's SCARA arm.
Sal decided NOT to do any RepRap CNC implementation on the prop. The existing Reprap support using Arduino is fine as it is, and does not need the extra cores or speed.
I now have a running system to Windows 8 and Windows 7
There was nothing wrong with the operating system and GO.
It was just me who did not fully understand what happened.
Over the summer I have read and tested GO , to understand it.
My goal was to run 10 tests through without errors.
In Windows 8 , there were random errors .
On Windows 7, there was constant error .
So it was on Windows 7, I made changes in windows_serial.go
and cogCommandProcessor.go .
As the test went well on Windows 7, I copied the files to Windows 8
and repeated the test there. I've only tested up to but not dosnettest.bat
My test system is :
G / G Propeller Platform
USB Propeller Plug
Windows 8 ASUS SonicMaster Intel CPU I3-3217U@1.80GHz 1.80GHz RAM 6GB 64- bit operating system
Windows 7 ASUS Eee PC Intel Atom CPU D525@1.80GHz 1.80GHz RAM 2GB 32- bit operating system
Now I started with testing on Linux UBUNTU 13.10 on my SonicMaster and
on a LUBUNTU 13.10 on a simple core Intel CPU@2.6GHz RAM 0.5GB 32- bit operating system
Test runs fine with domake.sh , the next will be dotest.sh
Sincerely,
Frida
Did you resolve all the errors? Sal has cautioned that on the slower windows machines, the serial port might not keep up at 230400 baud. My 1.6 Ghz test system is fine for PF5.3, but will not set the prop "listening" on PF5.5. I should be able to set the baud back to 56700 and make it work. However, I did not test it yet, too many other fish to fry.
Loading from 'fl' to ': onreset2 onreset USB_current ;'.
After that, doing 'saveforth'.
Trouble has gone about 'free' mistake.
But it cannot do 'forget USB_Current_Monitor'.
When executing ': onreset2 onreset USB_current ;', 'forget' cannot use.
This is bug or PropForth's specificasion?
I'm not able to try this at the moment...
So, are you doing
and getting an error, or is USB_Current_Monitor not removed from the dictionary and the memory not released?
Which kernel are you using? It should be fine with devkernel, but saveforth required caution with SD or EEPROM file system kernels, it can behave badly.
I use DevKernel.
If no loading ': onreset2 onreset USB_current ;', it can do 'forget USB_Current_Monitor'.
This runs at reset, then forgets itself. It allows me to use the ESC key to stop from switching to bluetooth during autoload.
We walked through PF6.0. We were surprised that the walkthrough only took one session, we had scheduled this activity to take at least three sessions.
PF6.0 has automatic multitasking and load balancing. It uses ideas from occam and go. Its totally simple from the user point of view, but requires a bit of understanding from the software designer point of view. The prop is treated as a pool of seven cogs (the eighth is the serial cog). A max of 128 tasks can be defined (more than 128 we run out of memory, and we can't do anything useful) and are in the demo. The next free cog takes the next task in the queue. The task executes one cycle, and the task goes to the end of the queue, and the cog goes back to the pool.
One of the tasks is the garabge collection task. When a task is marked (or marks itself) as terminated, the garbage collection task removes it from the queue. Any terminated tasks are removed in the next time the garabage collector runs.
If a given task is very slow or takes a long time, that cog is not available to the pool. Even so, the system capacity is only dinished by 1/7th. While this has minimal affect, we still have to be aware of how long each task will take.
With 128 tasks, each tasks gets a turn about every 696 milliseconds. So if we needed these tasks to be serviced more frequently, we would be late, and we would have to remove a few tasks. Sal has been running 20-30 tasks for various projects since last April. Fewer task means much less time to get through the queue (but I didn't get the numbers, we ran out of day light). His stress test was complex control and interesting numerical calculations, and the multitasker implementation is proving itself very suitable.
The PropForth 6.0 prototype is not yet available to the general public, it only has the build automaton. There are a couple decisions that stil have to be made. I'm only sending it to the team members that expressed interest; but I can send it out to any additional team members that are interested. (And if you want to join the team, send me a message). The current set of kernels are just the ones Sal was using, he will add the custom kernels and anything else we need for release.
PF6.0 totally rocks on the Prop 1. It should be 4x more awesome on the prop 2
Send me a copy, I'll do some user testing.
Cheers!
There is [: onreset2 onreset USB_current ;] at last line in "USB_CUrrent_Monitor_0.3.f".
I did 'forget onreset2'. I also did 'c" onreset2" (forget)'.
But cannot.
After saving [: onreset2 onreset USB_current ;], any words cannot forget.
Last way is re-installing PropForth5.5.
This is bug or PropForth's specificasion?
Sorry, can't determine at this moment.
Could you open an issue, with the steps to reproduce the problem on a generic board, such as quickstart or protoboard?
Please separate out the current monitor portion, and only include the forget portion, so we reproduce the issue.
If we can reproduce the exact problem, Sal and I will go through it next Sunday, and look for an answer and possibly a solution.
Using DevKernel on QuickStartBoard.
It seems string inside cds cause problem. <
this is mistake.
Even if no string inside cds, it cannot be [forget onreset2] .