OK, TNX, stating it as "Getting Started with Forth" confused me. I have that link already and I even scored a used-like new print copy of Brodie's "Starting Forth" from Amazon!
Sorry I must be dense again. I only ever found the two binaries, then and now I do not see any code.
There are some code snippets, but not anything one can build on. For example, to correct errors in the kernel.
Google code says activity is still "none" since 2008. If you have a link to the source code please post.
Forth is still an important langauge for micro controllers.
SAL's contribution is a significant step towards making Forth available to Prop enthusiasts. Its great piece of work.
He would have not written Propforth just for a handful of users.
Beginners need help up to get started, and to suggest that propForth is different enough not
to be able to be able to use widely available tutorials is to misrepresent propforth.
There is no other documentation which people can use to get started. If they get stuck they can ask.
JonesForth may be of interest to the some prop enthusiasts, hence the link. If you have read the docs then you will soon realise its not strickly about writing Interactive Forth for i386, he simply uses i386 in his examples. He specifly notes.... that you do not have to understand i386 assemblerto follow the tutorial.
Cheers
Ron
CB Forth is not worth playing with unless he has fixed the loading system. It hard to beat SAL's Forth IMO. getting started is the problem
There were requests for a simplified Master / Slave example. This has the Demo board as Master and a single ROM-less slave.
The demo board is connected to a bare prop chip ROM-less slave hanging off 4 of the demo board's unused pins. The first two MASTER pins are used for EEPROM emulation for the SLAVE when it it booted, and then become the synchronous communications channel. The other two master pins control the slave's reset and clock. Just as Brian's drawing, the EEPROM lines need the 10k pull up resistor on slave pin 29, and the both pins 28 & 29 need a 220 ohm (or so) resistor inline between the master and slave. There should be 0.1 uF capacitors between power and ground on the slave.
Notes: Removed (just editied out) of the original 4.0 example are the EEPROM file stuff, the logic analyzer stuff, the assembler, the synchronous serial on the local prop test code, the extra serial port example, the spineret test code, the spineret ethernet development. Actually there was quite a bit of stuff going on, wasn't there? Small wonder it was difficult to follow. You want bleeding edge? I got bleeding edge.
Explanation: The examples posted in 4.0 are what Sal runs in his development rig: protoboard, using the extra EEPROM for a mini-file-system; using the software logic analyzer; and includes the spineret for development. The example given is a snapshot of Sal's complete development system, and the current state of development. The idea was to give the advanced users an idea of where the project stands. The alternative was to wait a couple months to polish up the individual pieces, I was too impatient. While this was an interesting experiment, and some folks were able to move forward, it caused more questions than expected. Thus another example.
This is not the final version: no multiple slaves, no shared reset or clock, no auto addressing of slaves. It's propforth with 12 available cogs instead of only 5.
Please post or PM if you get stuck or have questions.
Thanks to all the folks that provided questions and input. Merry Christmas!
I fix bugs sd_loader_1.0.
sd_viewer_2.4 didn't work on SDHC because of sd_loader's bugs.
sd_viewer_ 2.4 modified to 2.4a.
sd_loader also modified interface.
Braino .... in what file and in what line vicinity are the actual pin assignments for clock, reset, sda and scl for the master(8,9,10,11) talking to slave (P28, P29, RESn, Xin)?
in what file and in what line vicinity are the actual pin assignments for clock, reset, sda and scl for the master(8,9,10,11) talking to slave (P28, P29, RESn, Xin)?
File: 48-comnorom 20101223-2016 one slave.f
Line 35-46 has examples, this is definitions for demo board using pins 7, 6, 5, 4, running on cog 5
I brought up sdloader 1.0a on a Propeller Platform USB board - 64K EEPROM, 5Mhz-x-pll16, and SD card 0(DO), 1(Clk), 2 (DI), and 3(CS). There is a picture of the board attached. I already had PropForth.spin, and fs.f in place. I loaded sdloader.f via copy/paste and it all worked fine.
RESET Prop0 Cog6 ok
fsls
008000 002272 propforth.f
00A280 000E7A LogicAnalyzer.f
00B140 0020CE asm.f
00D240 000D0F norom.f
00DF80 001426 com.f
00F3C0 000221 comnorom.f
00F600 000112 snet.f
8C0 bytes free in files system
Prop0 Cog6 ok
--- here I copy/pasted sdloader.f ---
Prop0 Cog6 ok
sdls
SDSC initialize success
- File list -
1 ._.Trashes
2 .Trashes
3 .fseventsd
4 .Spotlight-V100
5 Dump.f
6 .TemporaryItems
7 ._.TemporaryItems
8 ._Dump.f
9 LogicAnalyzer.f
10 ._LogicAnalyzer.f
11 sd_viewer_2.4a.f
12 ._sd_viewer_2.4a.f
Loading file number (q if quit) > q
Prop0 Cog6 ok
-- note the "." files are mouse droppings of Mac OSX file system --
So far so good .... but then I tried an "sdload" it blew up and then when I tried to read the card again it errorred and locked the prop and the terminal program up.
Prop0 Cog6 ok
sdload Dump.f
SDSC initialize success
Prop0 Cog0 ok
00FF21 RESET Prop0 Cog6 ok
UNDEFINED WORD RESET
Prop0 Cog0 ok
sdls
error: no card
One more thing .. I cannot seem to "fswrite sdloader.f" some how it RESETs the prop blowing out to a PF4 prompt and screws everything up. Thankfully, an additional reset and restarting the terminal program, and some EEPROM file maintenance cleans it all up.
RESET Prop0 Cog6 ok
fsls
008000 002272 propforth.f
00A280 000E7A LogicAnalyzer.f
00B140 0020CE asm.f
00D240 000D0F norom.f
00DF80 001426 com.f
00F3C0 000221 comnorom.f
00F600 000112 snet.f
00F740 000000 sd_loader.f
00F780 007472 entry freedict ;
0 _crf W!
0074728
fsls
@
-6C80 bytes free in files system
Prop0 Cog6 ok
fsdrop
Prop0 Cog6 ok
fsdrop
Prop0 Cog6 ok
reboot
RESET Prop0 Cog6 ok
fsls
008000 002272 propforth.f
00A280 000E7A LogicAnalyzer.f
00B140 0020CE asm.f
00D240 000D0F norom.f
00DF80 001426 com.f
00F3C0 000221 comnorom.f
00F600 000112 snet.f
8C0 bytes free in files system
Prop0 Cog6 ok
Thanks for your test.
I forgot deleting WORD"sdload" from sd_loader_1.0a.
But you can use WORD"sdload".
Usage: cluster-number sdload (cluster-number is area's number that file save on SD-card)
1 - "fswrite sdloader.f" - I was using a board with one 64K EEPROM that only had $0BC0 free, sdloader wants $4075. Obviously the EEPROM file system handling does not gracefully handle getting stuffed full! @braino, pass this onto Sal.
I moved over to my main PP board with two 64K EEPROMs and it appears to load fine, straddling the $10000 boundary, but when you do an "fsload sd_loader.f" it burps as it crosses that boundary and generates an UNDEFINED WORD and aborts.
Now, I then did a "fswrite dump.f" of Kaz' handy little dump routines, ramDump and eeDump (thanks kaz!). I did this for two reasons, I needed them and I wanted to see if writing beyond the boundary suffered as opposed to straddling the boundary ... it didn't. I dumped $FE00 and $10000 for $200 bytes each and sure enough they showed me right where I had seen the fsload fail. @braino, another one for Sal
Prop0 Cog6 ok
fsls
008000 002272 propforth.f
00A280 0020CE asm.f
00C380 000221 comnorom.f
00C5C0 000D0F norom.f
00D300 000112 snet.f
00D440 000E77 LogicAnalyzer.f
00E300 001426 com.f
00F740 004075 sd_loader.f
013800 0004EB dump.f
C300 bytes free in files system
Prop0 Cog6 ok
2 - with regard to "sdload ##" I blindly assumed it worked like the EEPROM FS which is "fsload filename.ext" - my bad! HOWEVER, it is my rarely very humble opinion that there should be consistency - now if bytes are a scarce commodity, the filename handling code is already there in the EEPROM FS, maybe they can be broken out so they can be used in the SD FS or we can do sector numbers on both ... @caskaz and @ braino need to hash this out.
I did some snooping and the fsload problem of an EEPROM file written straddling a 64K boundary is consistent and repeatable. I moved some files around so that sdloader crossed at different places.
This is what I found ... here are the last few lines before fsload blew up
Prop0 Cog0 ok
wvariable num_fat
Prop0 Cog0 ok
wvariable root_entry
Prop0 Cog0 ok
variable sector/fat
Prop0 Cog0 ok
variable t4riable rootCluster
UNDEFINED WORD rootCluster
Prop0 Cog6 ok
Now here is the dump from $FF90 to $1002F of the EEPROM FS (again! thanks for the tools Kaz!) It does the same thing every time ... it puts the extraneous "4" in and then picks up offset 14 bytes into the first page of the next EEPROM.
EEPROM file system handling does not gracefully handle getting stuffed full! @braino, pass this onto Sal.
when you do an "fsload sd_loader.f" it burps as it crosses that boundary and generates an UNDEFINED WORD and aborts.
"fswrite dump.f" of Kaz' handy little dump routines, ramDump and eeDump (thanks kaz!). I did this for two reasons, I needed them and I wanted to see if writing beyond the boundary suffered as opposed to straddling the boundary ... it didn't. I dumped $FE00 and $10000 for $200 bytes each and sure enough they showed me right where I had seen the fsload fail. @braino, another one for Sal
there should be consistency - now if bytes are a scarce commodity, the filename handling code is already there in the EEPROM FS, or we can do sector numbers on both ... @caskaz and @ braino need to hash this out.
Sal sez: the kernel has the basic tools implemented. The user can extend these as needed.
I.E. The USER (us) is responsible for keeping track on the system filling up. Now that you have experienced this, it will likely never happen again (due to your mind like a steel trap). If we (or in this case you) want to add error handling to the file names, please do and we can post another extension; we can all work together as a group project if yo want. But Sal adheres to a strict minimalist rule in all cases, except when he get carried away, but usually takes the extra stuff out later. He will most likely not add this class of material to the kernel.
I will start testing the rest of the sd material today. I agree that consistency is better, and that SD is not as limited on space as is the EEPROM. My idea is to get everything non-kernel in non permanent functions that load from SD and are removed after execution. This might take more than a couple days to find out how this might work. The file system error checking as discussed for EEPROM above might find a better home in the SD context.
EEPROM file written straddling a 64K boundary is consistent and repeatable.
variable t4riable rootCluster
UNDEFINED WORD rootCluster
Prop0 Cog6 ok
... it puts the extraneous "4" in and then picks up offset 14 bytes into the first page of the next EEPROM.
Did you look at what the first EEPROM has in the same location? That 14 bytes looks familiar, like the space allocated for dictionary entry or something.
Did you look at what the first EEPROM has in the same location? That 14 bytes looks familiar, like the space allocated for dictionary entry or something.
I thought so too, but the file directory entry is variable - two bytes (word) file length, one byte, I dunno what it is, then start filename, terminate with 0x0d, then start stored text. So I have no idea what the significance of the 14 (decimal) byte offset is.
Prop0 Cog6 ok
8000 eeDump
eeprom address 0x8000
0 1 2 3 4 5 6 7 8 9 A B C D E F
000 72 22 0B 70 72 6F 70 66 6F 72 74 68 2E 66 0D 68 r".propforth.f.h
010 65 78 0D 0D 31 20 77 63 6F 6E 73 74 61 6E 74 20 ex..1 wconstant
Prop0 Cog6 ok
e300 eeDump
eeprom address 0xE300
0 1 2 3 4 5 6 7 8 9 A B C D E F
000 26 14 05 63 6F 6D 2E 66 0D 68 65 78 0D 0D 31 20 &..com.f.hex..1
010 77 63 6F 6E 73 74 61 6E 74 20 62 75 69 6C 64 5F wconstant build_
020 63 6F 6D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D com.............
OK, while TPTB (the powers that be) ponder the boundary straddle problem in the "fsload" command I looked for a work around. I used an original Propeller Platform set with two EEPROMs and an add on uSD Platform Module (see picture) and carefully loaded files until I was within $100 bytes or so of $10000 and then took a dummy copy of "snet.f" an renamed it "no_use.f" and loaded it across the boundary. Then loaded the rest of my files.
This minimized file space lost while 'blanking out' the danger zone. Everything seems to work well and I have it all at hand in EEPROM, including Kaz' great sdloader code, which can quickly be loaded and used to access GBs of code on SD.
@Caskaz and @Braino, ...It occurred to me that I could put a file on the SD card with an "fl" and "fswrite" and load from "sdls" to EEPROM. I tried a copy of Kaz' "debug_tool.f" and it blew up. Left me with a corrupted PF4 prompt and input processor as well as a two messy entries in the EEPROM FS. It let me "reboot" and two "fsdrop"s later all was well again. Any idea why?????
I took the simple BlinkLED.f that I had updated for the Prof, from v2.5 to v3.2. I brought it up to PF4 and duped it to 2 files ... BlinkLEDdemo.f and BlinkLED2pins.f. The first blinks the P16 LED on the VGA port of the Demo Board. The second file is for any board, plugging an LED into two adjacent pins and setting the pin that has the cathode to 0 and toggling the other pin.
I watched source code of fs.f.
I think fsLoad's error on boundary is caused by WORD"eereadpage".
WORD"eereadpage" read out eeprom's data from eeprom to buffer(0x40).
But it can't switch from first eeprom to second eeprom.
If datas straddle on two eeprom, second eeprom's data can't read. Maybe first eeprom's data is read out.
So load error cause.
If PropFORTH is going to become a multi cog language, it definitely needs a new name and not just a number or letter appended or incremented to it. I think you were talking about ForthLinda at one time which served the multi processor purpose.
My post'#49' is a little mistake.
Although reason for boundary error is correct, WORD"eereadpage" is not wrong.
We must modify WORD"(fsread)".
I cannot test code because of no 24c512.
Please load to override this code.
Please teach results.
fl
: (fsread)
(fsfind) dup
if
dup t0 3 (fsrd)
t1 C@ + 2+ 1+ t0 W@ bounds
do
ibound i - fsps >=
if
i fsps + ffff and i ffff and >
if
i pad fsps (fsrd) pad fsps bounds
do i C@ emit loop i fsps 1- + seti
else
i EC@ emit
then
else
i EC@ emit
then
loop
else
drop
then
padbl
;
: fsread parsenw dup if (fsread) else drop then ;
: (fsload) cogid nfcog iolink (fsread) d emit d emit cogid iounlink ;
: fsload parsenw dup if (fsload) else drop then ;
If PropFORTH ... a multi cog language... new name ... ForthLinda ...multi processor ....
Now I see what you mean. I'm assuming you mean multi-processor in both places.
Propforth now simply has "support" the multiple prop communication, but the infrastructure at the application level has not been established. The plan is to borrow from any relevant existing techniques, but the set of items to borrow has not been estqablished. Once software is in place that starts to take advantage of the multi-prop configs at an application level, these decisions will have some basis. Multi propessing hardware and and paralel processor is only as useful as the software, and thesoftware lags thehardware by 10 ten years usually, so we are just catching up.
My post'#49' is a little mistake.
Although reason for boundary error is correct, WORD"eereadpage" is not wrong.
We must modify WORD"(fsread)".
I cannot test code because of no 24c512.
Please load to override this code.
Please teach results.
fl
: (fsread)
(fsfind) dup
if
dup t0 3 (fsrd)
t1 C@ + 2+ 1+ t0 W@ bounds
do
ibound i - fsps >=
if
i fsps + ffff and i ffff and >
if
i pad fsps (fsrd) pad fsps bounds
do i C@ emit loop i fsps 1- + seti
else
i EC@ emit
then
else
i EC@ emit
then
loop
else
drop
then
padbl
;
: fsread parsenw dup if (fsread) else drop then ;
: (fsload) cogid nfcog iolink (fsread) d emit d emit cogid iounlink ;
: fsload parsenw dup if (fsload) else drop then ;
I ran a couple of quick tests and it seems to work. I have to go out and do some errands when I get back I will do more exhaustive tests. For now, though, I am reasonably certain that you have it. Nice work, kaz!
We see success debugging the EEPROM words from the various participants' informal examination of the code. This is the most common method of public code review on the these forums.
We are having some difficulty getting caskaz SD support working. It is a little more complicated than the EEPROM access, so we are going to try using a slight bigger hammer.
We are going to attempt a slightly more formalized CODE REVIEW process. This is an extremely powerful technique getting the code to function reliably and getting the team on a common style and set of expectations. Maybe its overkill, maybe one can't afford not to; we'll see what results we get, if any.
Before we jump in and tackle the SD code, I would like to learn the CODE REVIEW PROCESS by applying it to a simple mostly working chunk of code, the ANSI.f support. If this is successful, we could apply the CODE REVIEW PROCESS to the SD functions. Please see the example review already started at:
Now I see what you mean. I'm assuming you mean multi-processor in both places.
Propforth now simply has "support" the multiple prop communication, but the infrastructure at the application level has not been established. The plan is to borrow from any relevant existing techniques, but the set of items to borrow has not been estqablished. Once software is in place that starts to take advantage of the multi-prop configs at an application level, these decisions will have some basis. Multi propessing hardware and and paralel processor is only as useful as the software, and thesoftware lags thehardware by 10 ten years usually, so we are just catching up.
Maybe to be more clear I should say multi-prop chip instead of multi-cog. I was thinking we already have PropForth. The upcoming multiple prop chip Forth for the Propellers could have a unique name to signify the multi-prop chip capability. All in due time of course. I can see exactly how long good preparation and cooking takes so it won't happen overnight... Even the converse is true: the software is only as good as the hardware design so we have two areas of contention.
Maybe to be more clear I should say multi-prop chip instead of multi-cog. I was thinking we already have PropForth. The upcoming multiple prop chip Forth for the Propellers could have a unique name to signify the multi-prop chip capability. All in due time of course. I can see exactly how long good preparation and cooking takes so it won't happen overnight... Even the converse is true: the software is only as good as the hardware design so we have two areas of contention.
I see where you are coming from, but hasten to point out that while PF4 is a major restructuring of PropForth, the bulk of that restructuring is to the PropForth kernal with some hooks and tweaks to accomodate multi-Props in the com.f and norom.f extensions later. The PF4 kernal is just yet another step in the single Prop Propforth evolution. In my view another name is not needed because the same PF4 kernal is the foundation of single prop or multi-prop. A second name could likely bring confusion rather than enlightenment. Just my $0.02!
Brian has it nailed. Now, what Humanoido is talking about could the "application" of the multiprop extensions.
For example, the Jupiter ACE is the stand-alone forth development environment. There is default Jupiter ACE configuration for the Prop Demo board call HiResVGA.spin. There is a Jupiter ACE for Hive hardware, it is waiting for implementation of support for all the Hive hardware. drohne235 is getting started, but had been occupied with R14 Hive hardware. If Sal and drohne235 get can work on it at the same time, it might go faster, but Sal has it on his list, and drohne235 is capable, so it will happen one way or another. When the C3 hardware comes out, there will likely be a Jupiter ACE for C3 that takes advantage of all the C3 hardware. Ron Suttcliffe has already stated that he feel this should be the target for propforth. It is, but only as the "Jupiter ACE for C3" extensions package. I don't know if he sees this the same way, but it doesn't matter; ALL development moves the entire project forward.
From the multi-prop configurations, there will be at least two concepts: one looking at increasing the number of avaialbe I/O pins, another looking at increasing the pool of available processors. These necessarily overlap. Sal is particularly interested in more I/O pins, so we can be confident that this will happen sooner than later. I am particularly interested in a large pool of cogs for experiements in distributed parallel processing, but I am not as capable as Sal; so this is the secondary focus, and happens as a side effect of Sal's "more I/O pins" direction.
Sal is working on a couple of reference designs for the multiprop configurations, so we can test what works nice for a given application. This is what I believe Humanoido is interested in naming. But these designs have not been "born" yet, so for the time being they are simply called "the multi-prop reference designs Sal is working on". I call these Level 0, Level 1, Level 2, etc, based on the number of layers of slaves between the master and the I/O pins on the leaf node. But the structure and hence the naming may change before design is final. I am confident that Humanoido will come up with an appropriate name for the configuration he decides to build, and it will also be nick-named "the Humanoido configuration".
So, we all more or less agree on these points, the only difference is the words used to express these ideas based on the type of background knowledge available.
@Braino and @Caskaz - I have just finished fairly exhaustive testing of the "fsload" fix and it is working, first as a dictionary override and then as a source code edit and total reload of PropForth.spin and reapply corrected "fs.s" , saveforth, and reboot. I tried different files and different boundary crossings for the same files. It all holds up.
@Braino and @Caskaz - I have just finished fairly exhaustive testing of the "fsload" fix and it is working, first as a dictionary override and then as a source code edit and total reload of PropForth.spin and reapply corrected "fs.s" , saveforth, and reboot. I tried different files and different boundary crossings for the same files. It all holds up.
Wow! You totally rock!
When you finish testing (assuming you have enough EEPROMs and time to test further), could you update Issue 22 with the final changes? That way Sal will add them to the next release.
Comments
OK, TNX, stating it as "Getting Started with Forth" confused me. I have that link already and I even scored a used-like new print copy of Brodie's "Starting Forth" from Amazon!
Sorry I must be dense again. I only ever found the two binaries, then and now I do not see any code.
There are some code snippets, but not anything one can build on. For example, to correct errors in the kernel.
Google code says activity is still "none" since 2008. If you have a link to the source code please post.
Forth is still an important langauge for micro controllers.
SAL's contribution is a significant step towards making Forth available to Prop enthusiasts. Its great piece of work.
He would have not written Propforth just for a handful of users.
Beginners need help up to get started, and to suggest that propForth is different enough not
to be able to be able to use widely available tutorials is to misrepresent propforth.
There is no other documentation which people can use to get started. If they get stuck they can ask.
JonesForth may be of interest to the some prop enthusiasts, hence the link. If you have read the docs then you will soon realise its not strickly about writing Interactive Forth for i386, he simply uses i386 in his examples. He specifly notes.... that you do not have to understand i386 assemblerto follow the tutorial.
Cheers
Ron
CB Forth is not worth playing with unless he has fixed the loading system. It hard to beat SAL's Forth IMO. getting started is the problem
MASTER-SLAVE-demoboard.zip
There were requests for a simplified Master / Slave example. This has the Demo board as Master and a single ROM-less slave.
The demo board is connected to a bare prop chip ROM-less slave hanging off 4 of the demo board's unused pins. The first two MASTER pins are used for EEPROM emulation for the SLAVE when it it booted, and then become the synchronous communications channel. The other two master pins control the slave's reset and clock. Just as Brian's drawing, the EEPROM lines need the 10k pull up resistor on slave pin 29, and the both pins 28 & 29 need a 220 ohm (or so) resistor inline between the master and slave. There should be 0.1 uF capacitors between power and ground on the slave.
Notes: Removed (just editied out) of the original 4.0 example are the EEPROM file stuff, the logic analyzer stuff, the assembler, the synchronous serial on the local prop test code, the extra serial port example, the spineret test code, the spineret ethernet development. Actually there was quite a bit of stuff going on, wasn't there? Small wonder it was difficult to follow. You want bleeding edge? I got bleeding edge.
Explanation: The examples posted in 4.0 are what Sal runs in his development rig: protoboard, using the extra EEPROM for a mini-file-system; using the software logic analyzer; and includes the spineret for development. The example given is a snapshot of Sal's complete development system, and the current state of development. The idea was to give the advanced users an idea of where the project stands. The alternative was to wait a couple months to polish up the individual pieces, I was too impatient. While this was an interesting experiment, and some folks were able to move forward, it caused more questions than expected. Thus another example.
This is not the final version: no multiple slaves, no shared reset or clock, no auto addressing of slaves. It's propforth with 12 available cogs instead of only 5.
Please post or PM if you get stuck or have questions.
Thanks to all the folks that provided questions and input. Merry Christmas!
I fix bugs sd_loader_1.0.
sd_viewer_2.4 didn't work on SDHC because of sd_loader's bugs.
sd_viewer_ 2.4 modified to 2.4a.
sd_loader also modified interface.
please report bugs.
TNX
File: 48-comnorom 20101223-2016 one slave.f
Line 35-46 has examples, this is definitions for demo board using pins 7, 6, 5, 4, running on cog 5
7 6 5 4 rambootnx
c" 7 6 5 5 commaster" 5 cogx
I brought up sdloader 1.0a on a Propeller Platform USB board - 64K EEPROM, 5Mhz-x-pll16, and SD card 0(DO), 1(Clk), 2 (DI), and 3(CS). There is a picture of the board attached. I already had PropForth.spin, and fs.f in place. I loaded sdloader.f via copy/paste and it all worked fine.
So far so good .... but then I tried an "sdload" it blew up and then when I tried to read the card again it errorred and locked the prop and the terminal program up.
One more thing .. I cannot seem to "fswrite sdloader.f" some how it RESETs the prop blowing out to a PF4 prompt and screws everything up. Thankfully, an additional reset and restarting the terminal program, and some EEPROM file maintenance cleans it all up.
RESET Prop0 Cog6 ok fsls 008000 002272 propforth.f 00A280 000E7A LogicAnalyzer.f 00B140 0020CE asm.f 00D240 000D0F norom.f 00DF80 001426 com.f 00F3C0 000221 comnorom.f 00F600 000112 snet.f 00F740 000000 sd_loader.f 00F780 007472 entry freedict ; 0 _crf W! 0074728 fsls @ -6C80 bytes free in files system Prop0 Cog6 ok fsdrop Prop0 Cog6 ok fsdrop Prop0 Cog6 ok reboot RESET Prop0 Cog6 ok fsls 008000 002272 propforth.f 00A280 000E7A LogicAnalyzer.f 00B140 0020CE asm.f 00D240 000D0F norom.f 00DF80 001426 com.f 00F3C0 000221 comnorom.f 00F600 000112 snet.f 8C0 bytes free in files system Prop0 Cog6 okThanks for your test.
I forgot deleting WORD"sdload" from sd_loader_1.0a.
But you can use WORD"sdload".
Usage: cluster-number sdload (cluster-number is area's number that file save on SD-card)
Please read Line395 of sd_loader_1.0a.f.
I added 2-lines to sd_loader_1.0a.f below;
I copy/paste sd_loader_1.0a.f to TeraTerm.
1 - "fswrite sdloader.f" - I was using a board with one 64K EEPROM that only had $0BC0 free, sdloader wants $4075. Obviously the EEPROM file system handling does not gracefully handle getting stuffed full! @braino, pass this onto Sal.
I moved over to my main PP board with two 64K EEPROMs and it appears to load fine, straddling the $10000 boundary, but when you do an "fsload sd_loader.f" it burps as it crosses that boundary and generates an UNDEFINED WORD and aborts.
Now, I then did a "fswrite dump.f" of Kaz' handy little dump routines, ramDump and eeDump (thanks kaz!). I did this for two reasons, I needed them and I wanted to see if writing beyond the boundary suffered as opposed to straddling the boundary ... it didn't. I dumped $FE00 and $10000 for $200 bytes each and sure enough they showed me right where I had seen the fsload fail. @braino, another one for Sal
2 - with regard to "sdload ##" I blindly assumed it worked like the EEPROM FS which is "fsload filename.ext" - my bad! HOWEVER, it is my rarely very humble opinion that there should be consistency - now if bytes are a scarce commodity, the filename handling code is already there in the EEPROM FS, maybe they can be broken out so they can be used in the SD FS or we can do sector numbers on both ... @caskaz and @ braino need to hash this out.
This is what I found ... here are the last few lines before fsload blew up
Now here is the dump from $FF90 to $1002F of the EEPROM FS (again! thanks for the tools Kaz!) It does the same thing every time ... it puts the extraneous "4" in and then picks up offset 14 bytes into the first page of the next EEPROM.
190 6C 65 20 73 65 63 74 6F 72 2F 63 6C 75 73 74 65 le sector/cluste 1A0 72 0D 77 76 61 72 69 61 62 6C 65 20 72 65 73 65 r.wvariable rese 1B0 72 76 65 5F 73 65 63 74 6F 72 0D 77 76 61 72 69 rve_sector.wvari 1C0 61 62 6C 65 20 6E 75 6D 5F 66 61 74 0D 77 76 61 able num_fat.wva 1D0 72 69 61 62 6C 65 20 72 6F 6F 74 5F 65 6E 74 72 riable root_entr 1E0 79 0D 76 61 72 69 61 62 6C 65 20 73 65 63 74 6F y.variable secto 1F0 72 2F 66 61 74 0D 76 61 72 69 61 62 6C 65 20 74 r/fat.variable t Prop0 Cog6 ok 10000 eeDump eeprom address 0x0000 0 1 2 3 4 5 6 7 8 9 A B C D E F 000 6F 74 61 6C 5F 73 65 63 74 6F 72 0D 76 61 72 69 otal_sector.vari 010 61 62 6C 65 20 72 6F 6F 74 43 6C 75 73 74 65 72 able rootCluster 020 0D 20 0D 76 61 72 69 61 62 6C 65 20 42 54 42 5F . .variable BTB_Sal sez: the kernel has the basic tools implemented. The user can extend these as needed.
I.E. The USER (us) is responsible for keeping track on the system filling up. Now that you have experienced this, it will likely never happen again (due to your mind like a steel trap). If we (or in this case you) want to add error handling to the file names, please do and we can post another extension; we can all work together as a group project if yo want. But Sal adheres to a strict minimalist rule in all cases, except when he get carried away, but usually takes the extra stuff out later. He will most likely not add this class of material to the kernel.
I will start testing the rest of the sd material today. I agree that consistency is better, and that SD is not as limited on space as is the EEPROM. My idea is to get everything non-kernel in non permanent functions that load from SD and are removed after execution. This might take more than a couple days to find out how this might work. The file system error checking as discussed for EEPROM above might find a better home in the SD context.
Did you look at what the first EEPROM has in the same location? That 14 bytes looks familiar, like the space allocated for dictionary entry or something.
I thought so too, but the file directory entry is variable - two bytes (word) file length, one byte, I dunno what it is, then start filename, terminate with 0x0d, then start stored text. So I have no idea what the significance of the 14 (decimal) byte offset is.
Prop0 Cog6 ok 8000 eeDump eeprom address 0x8000 0 1 2 3 4 5 6 7 8 9 A B C D E F 000 72 22 0B 70 72 6F 70 66 6F 72 74 68 2E 66 0D 68 r".propforth.f.h 010 65 78 0D 0D 31 20 77 63 6F 6E 73 74 61 6E 74 20 ex..1 wconstantProp0 Cog6 ok e300 eeDump eeprom address 0xE300 0 1 2 3 4 5 6 7 8 9 A B C D E F 000 26 14 05 63 6F 6D 2E 66 0D 68 65 78 0D 0D 31 20 &..com.f.hex..1 010 77 63 6F 6E 73 74 61 6E 74 20 62 75 69 6C 64 5F wconstant build_ 020 63 6F 6D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D com.............This minimized file space lost while 'blanking out' the danger zone. Everything seems to work well and I have it all at hand in EEPROM, including Kaz' great sdloader code, which can quickly be loaded and used to access GBs of code on SD.
@Caskaz and @Braino, ...It occurred to me that I could put a file on the SD card with an "fl" and "fswrite" and load from "sdls" to EEPROM. I tried a copy of Kaz' "debug_tool.f" and it blew up. Left me with a corrupted PF4 prompt and input processor as well as a two messy entries in the EEPROM FS. It let me "reboot" and two "fsdrop"s later all was well again. Any idea why?????
The zip archive with both files is on the Google Code site. http://code.google.com/p/propforth/downloads/list
I watched source code of fs.f.
I think fsLoad's error on boundary is caused by WORD"eereadpage".
WORD"eereadpage" read out eeprom's data from eeprom to buffer(0x40).
But it can't switch from first eeprom to second eeprom.
If datas straddle on two eeprom, second eeprom's data can't read. Maybe first eeprom's data is read out.
So load error cause.
Sorry, I don't check because no 24c512 now.
Please change line2 of eeDump.
My post'#49' is a little mistake.
Although reason for boundary error is correct, WORD"eereadpage" is not wrong.
We must modify WORD"(fsread)".
I cannot test code because of no 24c512.
Please load to override this code.
Please teach results.
fl : (fsread) (fsfind) dup if dup t0 3 (fsrd) t1 C@ + 2+ 1+ t0 W@ bounds do ibound i - fsps >= if i fsps + ffff and i ffff and > if i pad fsps (fsrd) pad fsps bounds do i C@ emit loop i fsps 1- + seti else i EC@ emit then else i EC@ emit then loop else drop then padbl ; : fsread parsenw dup if (fsread) else drop then ; : (fsload) cogid nfcog iolink (fsread) d emit d emit cogid iounlink ; : fsload parsenw dup if (fsload) else drop then ;Now I see what you mean. I'm assuming you mean multi-processor in both places.
Propforth now simply has "support" the multiple prop communication, but the infrastructure at the application level has not been established. The plan is to borrow from any relevant existing techniques, but the set of items to borrow has not been estqablished. Once software is in place that starts to take advantage of the multi-prop configs at an application level, these decisions will have some basis. Multi propessing hardware and and paralel processor is only as useful as the software, and thesoftware lags thehardware by 10 ten years usually, so we are just catching up.
Thanks for you work on this. You guys are the main point of progress on this issue, and it frees up Sal to work on the kernel stuff
I ran a couple of quick tests and it seems to work. I have to go out and do some errands when I get back I will do more exhaustive tests. For now, though, I am reasonably certain that you have it. Nice work, kaz!
We are having some difficulty getting caskaz SD support working. It is a little more complicated than the EEPROM access, so we are going to try using a slight bigger hammer.
We are going to attempt a slightly more formalized CODE REVIEW process. This is an extremely powerful technique getting the code to function reliably and getting the team on a common style and set of expectations. Maybe its overkill, maybe one can't afford not to; we'll see what results we get, if any.
Before we jump in and tackle the SD code, I would like to learn the CODE REVIEW PROCESS by applying it to a simple mostly working chunk of code, the ANSI.f support. If this is successful, we could apply the CODE REVIEW PROCESS to the SD functions. Please see the example review already started at:
http://code.google.com/p/propforth/wiki/CodeReview101
For now, we are going to try it via email (otherwise known as "desk review" with no formal meeting, as all folks are in different parts of the world).
If anybody would like to comment or participate, please response or PM
I see where you are coming from, but hasten to point out that while PF4 is a major restructuring of PropForth, the bulk of that restructuring is to the PropForth kernal with some hooks and tweaks to accomodate multi-Props in the com.f and norom.f extensions later. The PF4 kernal is just yet another step in the single Prop Propforth evolution. In my view another name is not needed because the same PF4 kernal is the foundation of single prop or multi-prop. A second name could likely bring confusion rather than enlightenment. Just my $0.02!
Brian has it nailed. Now, what Humanoido is talking about could the "application" of the multiprop extensions.
For example, the Jupiter ACE is the stand-alone forth development environment. There is default Jupiter ACE configuration for the Prop Demo board call HiResVGA.spin. There is a Jupiter ACE for Hive hardware, it is waiting for implementation of support for all the Hive hardware. drohne235 is getting started, but had been occupied with R14 Hive hardware. If Sal and drohne235 get can work on it at the same time, it might go faster, but Sal has it on his list, and drohne235 is capable, so it will happen one way or another. When the C3 hardware comes out, there will likely be a Jupiter ACE for C3 that takes advantage of all the C3 hardware. Ron Suttcliffe has already stated that he feel this should be the target for propforth. It is, but only as the "Jupiter ACE for C3" extensions package. I don't know if he sees this the same way, but it doesn't matter; ALL development moves the entire project forward.
From the multi-prop configurations, there will be at least two concepts: one looking at increasing the number of avaialbe I/O pins, another looking at increasing the pool of available processors. These necessarily overlap. Sal is particularly interested in more I/O pins, so we can be confident that this will happen sooner than later. I am particularly interested in a large pool of cogs for experiements in distributed parallel processing, but I am not as capable as Sal; so this is the secondary focus, and happens as a side effect of Sal's "more I/O pins" direction.
Sal is working on a couple of reference designs for the multiprop configurations, so we can test what works nice for a given application. This is what I believe Humanoido is interested in naming. But these designs have not been "born" yet, so for the time being they are simply called "the multi-prop reference designs Sal is working on". I call these Level 0, Level 1, Level 2, etc, based on the number of layers of slaves between the master and the I/O pins on the leaf node. But the structure and hence the naming may change before design is final. I am confident that Humanoido will come up with an appropriate name for the configuration he decides to build, and it will also be nick-named "the Humanoido configuration".
So, we all more or less agree on these points, the only difference is the words used to express these ideas based on the type of background knowledge available.
Also
Will this work for more than 2 EEPROMs addresses $20000, $30000, etc ?
I think ok it's ok , although not test.
if 0x2000, "10 rshift .hex" is 0x2.
if 0x3000, "10 rshift .hex" is 0x3.
..
if 0x7000, "10 rshift .hex" is 0x7.
Wow! You totally rock!
When you finish testing (assuming you have enough EEPROMs and time to test further), could you update Issue 22 with the final changes? That way Sal will add them to the next release.