PropForth4.6 is available for download
prof_braino
Posts: 4,313
Please note: As of 2012-03-04 proforth 4.6 is no longer the current release
PLease the the new thread
http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download
PropForth4.6 is available for download at
http://code.google.com/p/propforth/downloads/list
This version contains corrections for all issues corrected in the 4.x release series.
All existing 4.x PropForth code is expected to work as in previous versions (minus the bugs).
This release contains corrections for all issues found in the 4.x release series that were reported and reproduced to date. Each issue that was reported has been analyzed. Each issue determined to be an error has been corrected and tested. All issues that have been reported have been reproduced except one. All reproduced errors have been analyzed. All analysis has been applied and resulted in a bug fix.
Note: one issue has been reported that has not been reproduced in the test environment. This is the issue reported by Brian Riley and involves large custom EEPROM hardware. Plans are underway to send the exact hardware for testing, but we did not want to hold up the release any longer. Since the error was not reported by any other user with any other hardware, it should not affect typical configurations.
For more Forth Application for the Propeller, the Forth Interest Group Thread
http://forums.parallax.com/showthread.php?131047-Propeller-Forth-Interest-Group
PLease the the new thread
http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download
PropForth4.6 is available for download at
http://code.google.com/p/propforth/downloads/list
This version contains corrections for all issues corrected in the 4.x release series.
All existing 4.x PropForth code is expected to work as in previous versions (minus the bugs).
This release contains corrections for all issues found in the 4.x release series that were reported and reproduced to date. Each issue that was reported has been analyzed. Each issue determined to be an error has been corrected and tested. All issues that have been reported have been reproduced except one. All reproduced errors have been analyzed. All analysis has been applied and resulted in a bug fix.
Note: one issue has been reported that has not been reproduced in the test environment. This is the issue reported by Brian Riley and involves large custom EEPROM hardware. Plans are underway to send the exact hardware for testing, but we did not want to hold up the release any longer. Since the error was not reported by any other user with any other hardware, it should not affect typical configurations.
For more Forth Application for the Propeller, the Forth Interest Group Thread
http://forums.parallax.com/showthread.php?131047-Propeller-Forth-Interest-Group
Comments
Not a big deal to me but it appears as if the latest PropForth4.6 still identifies itself as PropForth4.5.
Thanks in advance
I'm hoping a first-timer that has not run them before will give feedback from that perspective, but all feedback is appreciated. This involves downloading the release archive, loading propforth.spin to the prop EEPROM, find the tests in the doc directory, and following the instructions. It takes less than a couple hours.
The idea is that the more people that check the proper functions, the less likely we miss something. Also, we are attempting to combine the documentation, requirements, tutorial, and tests in the smallest, most efficient package. The result is the suplied "regression suite". The intent is that if runs the regression suite, one will have exercised all propforth functions, seen them execute successfully, and have some idea of how they are used; or at least know where to look to find an example of correct use and operation.
In next release series, the Regression Suite will be automated, such that a single command will launch the entire suite, and one can determine if something got broke within 45 seconds, rather than wait until something blows up in the field. More testing sooner means fixing issues now when they are easy; and less problems later, when they are expensive.
The experiment is to determine the dgree of success of this approach, and discover areas for improvement.
There is no deadline. Results reported before v5.0 release will be used in 5.0 developement, so sooner is better.
For each release, I re-run everything from scratch after posting, including re-assembling the test bed from scratch. But I won't be able to get started till this weekend. If anybody can beat me to it and find something, I would be grateful.
This actually is a big deal, but at least we got the date right. There will be a new version with corrections, hopefully this weekend.
Thanks for the feedback!
I had little time, so I did the first test, at the moment,
There is no echo when a function is defined via : (in the reference it is supposed to be echoed).
Is there a way to automate it, let's say with Perl or Python, saving the output to a file and simply diff it with a reference? It would simplify a lot the tests.
Massimo
edit: I reread your posts, and I see you are already planning the automation. Sorry..
Thanks for the feedback, I intend to put this in the documentation, once I figure out how I want to say it.
The idea is that the terminal program (teraterm) already does logging.
Also, the definition started with : and ending with ; echo "ok" if successful. This is by design.
Which reference says it is to be echoed? I should change it.
When the word is executed, in this case the lines after the --- are the test input and
the lines after the ### are the screen captute of your input and the expected output
The plan is that if the actual output of the test matches the predicted text, the test can pass.
If the text does not match, the test identifier and offending lines will be echoed to the screen for logging by teraterm or other logging utility; AND will be logged to a file on the EEPROM/SD if present and enabled.
There will also be an ability to do general match for things that are not expected to be predictable, for example time stamps.
The thought was that on version 4.x, the tests were still fairly simple and the checking could still be done visually.
I missed the AND..
Massimo
I have trouble.
I installed PropForth4.6 to protoboard.
MicroSD-card is 2Gbyte(SDSC).
Card is formatted by WindowsXP.
Procedure;
1. Loading PropForthKernel.spin
2. Loading fs.f
Executing fsclear and fsls
3. Loading fswr.f
4. Loading fsrd.f
5. Executing saveforth
6. reboot
I connected microSD-adapter on protoboard and modified sd_driver.f;
P0 cs
P1 di
P2 clk
P3 do
I checked sd_init on sd_driver.f(modified). It's no error. (A3 error don't occur)
7. Loading sd_driver.f(modified)
8. Loading sdfs.f
9. reboot
CON: Prop0 Cog0 RESET - last status: 0 ok
.
..
CON: Prop0 Cog5 RESET - last status: 0 ok
CON: Prop0 Cog6 RESET - last status: 163 UNKNOWN ERROR <-- (A3 read timed out)
CON: Prop0 Cog0 RESET - last status: 7 LOCK TIMEOUT
Prop0 Cog0 RESET - last status: 7 LOCK TIMEOUT
Prop0 Cog0 ok
What is wrong?
In this case, I must repeat from 1st step(Loading PropForthKernel.spin)?
Did you run the regression test? ...\Propforth\PropFroth4.6-20110725\doc\tests
test-1.3.1 EEPROMfsRW.txt
test-1.3.2 EEPROMfsRD.txt
You must run the regression test successfully to show that your hardware works correctly.
But this is what I think from reading your post:
- fs.f is the entire file system, includes read, also write functionality. Usually use this, load propforth.spin, load fs.f and do saveforth.
- fsrd.f is READ ONLY, use this when you have something in EEPROM, and you want to "protect" it from modification. It can still be modified, but it is less likely to do it accidentally. Use this after the final application is complete, and the files that reside in EEPROM are stable. Load propforth.spin, load fs.f and do saveforth.
- fswr.f is the set of WRITE extensions for fsrd. If you are using fsrd, and you want the ability to write to EEPROM temporarily, add fswr on top of fsrd. Load fswr.f into RAM, write to EEPROM, and reboot. The data will remain in EEPROM, and the file system will remain read only.
It looks like you are loading fswr after you already have the full file system loaded, this is an error.
It looks like you are loading fsrd after you already have the full file system loaded, this is an error.
It looks like you are loading fswr before you load fsrd, this is an error.
1) Load Propforth.spin
2) Choose EITHER fs.f or fsrd.f Load ONE of these
3) do saveforth
If you loaded fsrs but need to clear and re-write the EEPROM, load fswr, modify the EEPROM, and reboot.
If this fixes your error, I should put this in the instructions for fs.f. Should this go in the comments in the code, or in a web page?
I did;
1) Loading Propforth.spin
2) Loading fs.f
3) do saveforth
4) Loading sd_driver
5) Loading sdfs
6) do saveforth
I checked SD-card.
Only 1-card is usable, although sd_init of all card is successful(check before saveforth).
No error card (saveforth after loading sd_driver and sdfs)
Kingston standard-SDSC 2GB
Error SD-card(saveforth after loading sd_driver and sdfs)
Transcend standard-SDHC 4GB --> CON: Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR
Transcend micro-SDSC 2GB --> CON: Prop0 Cog6 RESET - last status: 163 UNKNOWN ERROR
No-Brand micro-SDSC 2GB --> CON: Prop0 Cog6 RESET - last status: 163 UNKNOWN ERROR
Transcend standard SDHC 4GB --> CON: Prop0 Cog6 RESET - last status: 163 UNKNOWN ERROR
SiliconPower standard SDHC 4GB --> CON: Prop0 Cog6 RESET - last status: 172 UNKNOWN ERROR
Did you run the regression test
test-2.1.1 SD.txt
on each card?
After step 5, the saveforth, the board should be able to test multiple cards. Power down the board, swap working SD card for the next card, then power up the board, and if no error, continue with step six.
If a card that gives an error was formatted by windows, please try to format the carrd with a camera or other device, and with the manufacturer's format utility.
If the cards still give an error, please open a new issue. You might have to send one of your problem cards to Sal.
I tested each card after saveforth.
Only Kingston-card was ok.
I formatted all SD-card by WindowsXP.
All SD-card is successful on sd_init.
I don't have camera(using SD-card). I will format SD-card after borrowing camera or other devices.
Look at this Software -- I have good experiences on it.
SDSDHCSDXC Memory Card Formatting Software
Thanks for your advice.
Formatting are ok.
But result is same as #11.
Only Kingston SDSC-card is ok.
I tested skipping .autoload.
Using no-brand micro2GB(SDSC).
After power-cycle, its card is successfull.
I did another card(Transcend standard4GB SDHC). It is ok, too.
So you problem is fixed? To summarize the answer, the software is set-up as described in test-2.1.1 SD.txt, up to step 5, the saveforth. After that, power cycle when the card is swapped. Remember, the design for THIS driver assumes that the SD card is INTERNAL to the system, and is not intended to be swapped after power up.
Support for FAT and hot swap is yet to be implemented, but it looks like caskaz is already started. If possible, can you make the FAT and hot swap SD support for a SECOND sd slot? I was thinking to have one SD as permenant, internal, and teh second for transfer to the PC, since the second driver will be much slower and much larger memory footprint.
Yes, error has gone.
I don't understand its reason.
I think I need to understand sdfs.f.
I will make 2nd SD-slot for FAT after understanding sdfs.f and sd_script.f.
I made DS1337(rtc)-demo.
Time-setting use Denpatokei(Radio Controlled Clock).
Denpatokei's decode-code cannot use in other country, because it is for Japan.
1) Loading DS_1337_0.2
2) Loading Denpatokei_0.2
3) Loading demo_DS1337
I believe the reason is initialization at power up.
To save memory space and complexity, the driver only initializes once at power up. It does NOT detect if the card is unplugged, and does NOT give many error messages. These are left to the user to define for a particular application.
However, the usage is "obvious" to Sal, but maybe not so obvious to the rest of us. I'll tell him about the problem you had, made we will make some better instructions, or change the way the functions are coded to make it clearer.
Thanks for looking at this. You input continues to be a main driver for progress.
EDIT - Opened Issue #50 - better docs for EEPROM and SD.
Good stuff!
Your code looks great. The only comment I would make at this time is about the word
It is very long and contains many nested if..thens. The "rule of thumb" is for the highest level words to contain no more than around 7 items. For example I might suggest breaking the word into its functional areas: Initialize_depatokei, Loop_denpatokei, Parse_frame_denpatokei, .display_denpatokei. This makes looking at the code easier, and thus will be easier to maintain in 3 months when you come back to it after looking at something else (i.e. to answer a new user's questions, this is a real possibility since you are the expert for all of Japan, the propforth expert for the whole world for many functions). This is considered "best practice", but is of course optional and totally up to you.
Arrigato, Sensei!
Thanks for your advice.
Now,I write DS3231(rtc) code.
I'm going to re-make denpatokei's code.
I played with PropForth yesterday and it seems to work well (nice job Sal) and so I may look at developing a real application (PLC) around it. The big scary question is where is the documentation or even user guides?
If you need contributors for the kernel or other utilities I am sure I can help.
BTW, I'm very glad it's not ANSI Forth, proof that a committee of experts can get it so wrong (and impractical). Forth's strengths IMO are not PC centric but embedded and real-time systems, right where Forth got it's roots.
There were bugs in denpatokei_0.2.
I made DS3231's code.
I tried to re-write denpatokei's deep nest. But it was difficult for me.
Although deep nest seems to be difficult to read, it is acutually simple.
Loading DS_3231, denpatokei_0.3, demo_DS3231
1second is 1.000047sec(80003760ticks).
This may be caused by using PropForth. <-- maybe incorrect
Needing to use assembler on check_1Hz. <-- meaningless
Crystal on protoboard is +-30ppm. DS3231's spec is +-2ppm.
Measurement by propeller is meaningless.
Later, I will use battery-backup and observe time-shift for long time.
I don't understand well DS3231's temperature-compenation.
Anyone teach me about temperature-compenation?
How to use it?
Thanks! Looking forward to seeing your work. Version 5.0 should be even cooler, so you are joining at a good time.
The only documentation at this time are Sal's comments in the source code, and a few of my own weak attempts on the wiki list.
http://code.google.com/p/propforth/w/list
There are a couple of pages added by other team members, but not nearly enough.
The pages are created and updated in response to user questions, but most users don't ask so many questions, so the pages are not updated often. Most pages are in fact my notes to my questions that Sal answered, and so only go as deep as my understanding. Ask questions or supply answers and explanations, I will see to it that they are added. Excellent, yes I do, please do. Just as the original Forth was Chuck Moore's personal tool, and he does not particularly care one way or another how anyone uses it, Sal's forth is Sal's personal tool, and he does not particiularly care if anyone else uses it. He is amused that I want to to use it for teaching kids, so has allowed me to ask for standardization, consistency, and added functions. But its still his tool done his way for his purpose. He wants folks to change it anyway they want or need, but deviations cannot be supported, each main branch is the responsibility of the author. That being said, we have not seen any deviations from th main branch, all the extensions are on top of the main branch (so far). This may change once the final 5.0 kernel comes out, but they would be great.
I'm looking forward to your feedback, and additions to the main branch or a branch in your own direction.
I translated WiiNunchuck-driver from OBEX to PropForth.
Sorry, only display of datas.
Don't connect 3rd 64keeprom(A2=0 A1=1 A0=0) because of using P28 and P29.
WiiNunchuck adapter
http://www.sparkfun.com/products/9281
I installed battery-back-up DS3231(rtc) on protoboard.
Today,I have adjusted DS3231 by radio-controlled clock.
1second for DS3231 is 80003520ticks for propeller system-counter.
Maybe it is a little bigger than 80MHz.
I will measure DS3231's time-lag in a month.
I have just downloaded the latest version of Propforth.
Might I suggest that the propforth.spin defines the FIRST TIME BOOT I/O Pins using the CON statement.
The RamBlade board( which supports 512k SRAM and SD card) uses pins 30 and 31 for addresssing the SRAM. Once
Propforth.spin is compiled and downloaded to eeprom via P30 and P31, these Pins are no longer available.
I/O is redirected through Pins $16 and $17 following an eeprom load. (see ramblade handware and drivers below)
This leaves users like myself having to modify propforth.spin. Defining the rx and tx pins using a CON statement in the spin file
would be most helpful. This first time boot pin config can be over written later if need be, by words in the forth Dict.
There are alot of Boards around with external Ram.
Below see Ramblade hardware Access
' P0-18 = A0-18 SRAM address
' P19 = -CS microSD
' P20 = -CE SRAM & enable eeprom
' P21 = -WE SRAM & enable eeprom
' P22 = SO \ not used by this driver
' P23 = SI / I/O RX TX
' P24-31 = D0-7 SRAM \ * see below
' | P28 = SCL eeprom
' | P29 = SDA eeprom
' | P30 = prog SO programming only
' / P31 = prog SI programmimg only
'
Forth Drivers for SRAM
17ffff constant ram_dr
0ff07ffff constant ram_dw
0ff37ffff constant ram_strobe
3ffff constant mem_top
: rd_ina ina COG@ ;
: xrd dup 0 dira COG! \ Random read
mem_top < if
outa COG!
ram_dr dira COG!
rd_ina
18 rshift
then ;
: xwr dup \ Random write
0 dira COG!
mem_top < if
ram_dw dira COG!
swap
18 lshift
or
outa COG!
ram_strobe dira COG!
ram_dw dira COG!
then ;
: xmv s_adr W@ xrd \ Copy scr to dest x bytes
d_adr W@ xwr
0 do
s_adr W@ i - xrd
d_adr W@ i - xwr
loop ;
: xclr hex swap s_adr W! \ fill with spaces
0 do
20 s_adr W@ i + xwr
loop ;
: xdump hex swap s_adr W! \ Sram dump from start adr, n bytes
0 do
i 4 u/mod 4* i swap - 0= if cr then drop
s_adr W@ i + dup xrd swap .word space .word space space
loop
cr ;
Random access to External Ram does not get any faster or easier than this. Hence my reason for using this RamBlade.
I would appreciate if you would pass this on to Sal for his comments.
Ron Sutcliffe
Sal is still out on vacation, he should be back in a couple weeks. I'll bring this up next time we talk.
We're getting ready for 5.0 in little while, and the editor work is becoming germane.
FYI-
The current design specifies the kernel is compatible with any propchip, and not specific to any particular hardware. We'll discuss this change and make sure it has no impact on this or other design decisions, and evaluate from there. The current set of design decisions would indicate SRAM support as an extension to the standard kernel, and not permit kernel modifications for specific hardware unless there is no impact on the standard hardware. When specific hardware applications are present, these are handled with extensions as in the case of the spineret board.
So far you are the only one to use the RamBlade with forth and request this change. Another forth user with SRAM is drohne235 at Hive-project.de. The hive board uses a different configuration for SRAM, and so a change for either risks presenting a conflict for the other. If a user has an alternate hardware configuration IE remapping the standard serial terminal pins, the user is responsible for determining the best way to handle that hardware.
In general, if in fact a kernel change specific to the RamBlade is required, you would become maintainer of the "RamBlade branch". Modifying propforth.spin as the recommend solution in this case, but confined to the branch.
This is a good time to have this discussion, I'll post the results.
EDIT added Issue 53 for this
http://code.google.com/p/propforth/issues/detail?id=53
I am not in favour of any modified version if it can be avoided.
I think we all want a common PropForth.spin, but it needs be portable.
I look forward to hearing what comes out of your discussion with SAL
Cheers
I made fs.f for 128k-eeprom.
24LC1025
address:0x20000 - 0x3ffff
Pin1 A0
+3.3V
Pin2 A1
GND
Pin3 A2
3.3V
Pin4 Vss
GND
Pin5 SDA
P29
Pin6 SCL
P28
Pin7 WP
GND
Pin8 Vcc
3.3V
I had trouble when I made this codes.
Somtimes read/write error occured.
Reason was pull-up-resisterfor SDA/SCL.
I had installed DS3231S(rtc) on protoboard.
So SDA/SCL line connected 64k-eeprom(on board) and DS3231S and 128k-eeprom.
64k-eeprom and DS3231S had no trouble.
I added pull-up-resister(10k ohm) beside 128k-eeprom.
Read/write's error has gone.
I also tested QuicStart board(32k-eeprom on board).
Not need extra pull-upresister(10k ohm) when 128k-eeprom read/write.
Maybe pull-up-resister(10k ohm) on protoboard is a little big.
If extra 64k-eeprom(7pcs) installed on prop-board, read/write's error might cause.