How do I save forth-code(2_wire_LCD_1.5.f) on internal SD-card?
Install the SD support per the example in the regression test
\doc\tests\test-2.1.1.txt (this is the SD tutorial)
Step 5 loads the sd file system
Step 6 initializes the SD
At the end there are two partitions on the SD that can be mounted , USR and SSYSTEM
via the command mountusr and mountsys, respectively.
The SYSTEM partion is small, and for forth infrastructure, drivers etc.
The USR partion is for your application, drivers etc. The main portion of the SD is USR, please try working from this partion.
sdfs.f shows words for reading and writing files:
fwrite <filemname> writes a file
fload <filemname> loads a file (into the interpreter)
fread <filename> reads and displays a file
If we did this as we intended, you should be able to look at
\doc\tests\test-2.1.1.txt
The examples are scattered through the download package :frown:
This is one of the shortest scripts creating a file. It is cut from an editor and pasted into the terminal window.
10 fbwrite .autousr.f
mountsys
\ this is now hardwired into the onboot
\ .autoload.f and thus autousr.f will not be run if the ESC
\ key is held down during a boot
\
\
\ if esc has been hit the rest of the file does not execute
\ 6 cogio W@ 27 = c" clearkeys" find -1 = and and execute
fload ipconfig.f
fload ipserver.f
: onreset5
onreset
100 delms
0 cogreset
1 cogreset
2 cogreset
3 cogreset
100 delms
ip_init ip_server
;
5 cogreset
...
It uses the fbwrite word which seems to be favored in all the test scripts. It expects a block count to be on the stack.
\ fbwrite filename ( numblocks_to_allocate -- )
The first script says allocate 10 blocks to .autousr.f and copy everything following the fbwrite up to the '...' into that file. the the periods in the last line are IMPORTANT!! They are the EOF indicator.
That's how every file I've seen put onto an SD card gets created in the 4.5/4.6 release.
1 block should be 512 bytes, if I recall it is the default of the SD card.
Do you mean "..." is being flagged as undefined? I haven't gotten this message. You may be starting with basic kernel, and not loading the development extensions?
Did you follow the examples in the regression test and set up the drivers?
The examples are scattered through the download package :frown:.
Thanks for the feedback, this helps me determine how to structure the docs. Clearly, lots of work remains.
The "organize for the user" effort has been on hold till the 5.0 release. Things have been in flux, and have now become stable with 5.0.
This is where the REAL fun starts.
Currently, the download package consists of all the material (that I requested), in the order that Sal implemented it. The result makes perfect sense to someone that already is familiar with the material (i.e, Sal, as developer) but maybe is not so clear to the rest of us (users). My task is to figure out what Sal did, and put it into words so the rest of us can "just use it" without becoming clones of Sal. Propforth should not require users to have Sal's level of expertise, it should be easy enough for a beginner. It is, or would be with proper explanation.
The idea for the documentation is: "These are the functions. Here's how to use them. Go play"
I need your input. Can you give a high level outline of how you need to see the information? How should it best be organized?
I don't imagine this will be quick or short. We can take our time and be driven by user questions, to ensure we don't waste time on topics that aren't of interest.
I've put forth on the side burner until 5.0 comes out. At that point, I was intending on trying to write some documentation and tutorials. I'm currently being distracted by trying to do the same thing with propgcc. I think I learn things better if I try to write about them while I'm playing.
I'll try to start getting back to thinking about forth as winter swoops down upon us.
I use development kernel.
And character"..." is not WORD. It is EOF.
WORD"fbwrite" should search for "...".
But error occure.
I think my sample is wrong.
How can I save forth-code(text file) inside sd-card?
Remove fl from your test.f and you will find that it will work. I have noticed that fl will cause this problem with very short files.
I think it is when the file are shorter than the input buffer length. I have yet to confirm this.
I think you may have a corrupt sdfs system,. I will start with a clean sdcard and save test.f in the usr partion then re load it from the sdcard. I will get back to you later today (my time)
Tested the fwrite and fload. See below the log, with my comments added.
I cannot figure out why it is written to .partion-sys. The file should be written to the current
directory IMO.
I have not tested asm yet with sdfs loaded but I am thinking the code gets cleared by the sddriver sd_cogbufclr. Will check Ron
1. fl will cause UNDEFINED WORD ... in a very short files
consisting of only a one or two word definitions when using fwrite or fblock. Refer to Caskaz POST #96 #100
2. Cannot write large files to sdcard. AKA hex 50 fwrite testfile
the directory entry is written but no data. I used my edit_demo to test, which is a 6k text file.
3. Can only fwrite to .partion-sys. Should be able to fwrite to current
directory or to .partion-usr CasKaz POST #100
Prop0 Cog6 ok
ls [enter]
337 .partion-sys/
130 .sdcardinfo
136 .autousr.f
133 .autoload.f
Prop0 Cog6 ok
------------------------------
I did copy/paste above code.
------------------------------
-- Response from Forth
fl
5 fwrite greetings.f
Prop0 Cog6 ok
Prop0 Cog6 ok
fload greetings.f [enter]
-- Response from Forth
: hi c" Hello Caskaz" .cstr cr cr ;
Prop0 Cog6 ok
Prop0 Cog6 ok
hi
Response from forth
Hello Caskaz
Prop0 Cog6 ok
ls [enter]
337 .partion-sys/
130 .sdcardinfo
136 .autousr.f
576 greeting.f
133 .autoload.f
Prop0 Cog6 ok
But it cannot save in mountusr.
Prop0 Cog6 ok
mountusr [enter]
Prop0 Cog6 ok
ls [enter]
65667 .partion-usr/
Prop0 Cog6 ok
cd .partion-usr/
Prop0 Cog6 ok
ls [enter]
Prop0 Cog6 ok
------------------------------
I did copy/paste above code.
------------------------------
-- Response from Forth
fl
5 fwrite greetings.f
Prop0 Cog6 ok
Prop0 Cog6 ok
ls [enter]
65667 .partion-usr/
Prop0 Cog6 ok
cd .partion-usr/
Prop0 Cog6 ok
------------------------------
I did copy/paste above code.
------------------------------
-- Response from Forth
fl
5 fwrite greetings.f
Prop0 Cog6 ok
Prop0 Cog6 ok
ls [enter]
Prop0 Cog6 ok
I think forth runs out of room. I know hub is very tight, because I ran out of room recently with my editor program when I stopped using Ramblade and had to create a larger buffer.
I have decided to stay with standard Prop board with just a SDcard for now., so I am playing with a virtual memory system for the SDcard.
I have made a vram. f in .partion-sys. I am writing the driver in forth, but will need to convert is to asm later, so we need to be able asemble files to work with the sdcard driver.
I should have used the sdfs system much earlier, but I have only been using the driver and have not had any problems with that.
I wrote POV on QuickStart by spin.So, I translated it to PropForth.
You are the coolest!
POV was the example used in a forth applications class many years ago. The class was given several LED, a hack-saw blade and a solenoid from and old door bell. The idea was to trigger the solenoid and make it strike the saw blade to get it oscillating. Then the LEDs were flashed to make a message.
I guess all that's needed is a transistor, a saw-blade and a solenoid, and we will have the same demo.
I do not understand! I pass the rendevous address to the driver from the word blink ( rendevous v_hadr COG!, the adr of rendevous is pushed onto the stack, then top of stack is
popped and stored in cog4 adr at v_hadr )
I would have thought that the driver at line (wrlong _treg4 , __3v_hadr ) would write the char back to the address of rendevous.
In fact it puts the adr of the character in rendevous so in order to display the char I have to setup another level of indirection, see the word disp ( rendevous L@ W@ )
The code does exactly what it is supposed to do, but I would have expected to achieve the same result with ( rendevous W@ )
The program, blink (cog6) starts the driver in cog4 and outputs the character supplied by the driver
The driver runs in Cog4 and blinks the LED on pin 16 then sets up the next char in the alphabet for output by cog6.
I have a wc on the first line of my PASM code. It should not be there, but it does not affect the result
I have a revised the code I posted previously. Yes it did work but the code was wrong.
rendevous was ignored in the previous version and the char was always written to hub adr 0
Thats why it worked.
This version now works correctly and can be run from any cog. The par register is required, because the pad area is
different for each cog. The par points to the pad area assigned to the cog running blink.
The char address is written to rendevous so there is a level of indirection, L@ W@ is required.
rendevous is a dictionary word and common to all cogs. It will now hold the correct address for the char
irresective of which cog is running blink.
I have been quietly following in the shadows. I am sure that enough of us out here could "learn" from any info you would be willing to spend the time to share on the topic of getting started with Propforth asm even if it does change in v5.0.
Comments
Install the SD support per the example in the regression test
\doc\tests\test-2.1.1.txt (this is the SD tutorial)
Step 5 loads the sd file system
Step 6 initializes the SD
At the end there are two partitions on the SD that can be mounted , USR and SSYSTEM
via the command mountusr and mountsys, respectively.
The SYSTEM partion is small, and for forth infrastructure, drivers etc.
The USR partion is for your application, drivers etc. The main portion of the SD is USR, please try working from this partion.
sdfs.f shows words for reading and writing files:
fwrite <filemname> writes a file
fload <filemname> loads a file (into the interpreter)
fread <filename> reads and displays a file
If we did this as we intended, you should be able to look at
\doc\tests\test-2.1.1.txt
and be able to use the SD support.
fwrite<filename> writes a file from where ????
Do you fwrite foo.bar then paste the text to the terminal ???
Do you add it to the top of the file then paste it AKA a script.
Hence the question.
There a lot of info but not a specific HOW TO
Ron
This is one of the shortest scripts creating a file. It is cut from an editor and pasted into the terminal window.
10 fbwrite .autousr.f mountsys \ this is now hardwired into the onboot \ .autoload.f and thus autousr.f will not be run if the ESC \ key is held down during a boot \ \ \ if esc has been hit the rest of the file does not execute \ 6 cogio W@ 27 = c" clearkeys" find -1 = and and execute fload ipconfig.f fload ipserver.f : onreset5 onreset 100 delms 0 cogreset 1 cogreset 2 cogreset 3 cogreset 100 delms ip_init ip_server ; 5 cogreset ...It uses the fbwrite word which seems to be favored in all the test scripts. It expects a block count to be on the stack.
The first script says allocate 10 blocks to .autousr.f and copy everything following the fbwrite up to the '...' into that file. the the periods in the last line are IMPORTANT!! They are the EOF indicator.
That's how every file I've seen put onto an SD card gets created in the 4.5/4.6 release.
Thats the answer that Caskaz was looking for probably looking for.
@Caskaz
In the sample scipt that Rick posted....
Replace mountsys with mountusr, to keep your drivers etc in the usr file system not the sys file system.
Ron
1block of "fbwrite filename ( numblocks_to_allocate -- )" is 512byte?
I copy/paste below code to TeraTerm. Result is "UNDEFINED WORD ...".
Where is wrong?
Do you mean "..." is being flagged as undefined? I haven't gotten this message. You may be starting with basic kernel, and not loading the development extensions?
Did you follow the examples in the regression test and set up the drivers?
Thanks for the feedback, this helps me determine how to structure the docs. Clearly, lots of work remains.
The "organize for the user" effort has been on hold till the 5.0 release. Things have been in flux, and have now become stable with 5.0.
This is where the REAL fun starts.
Currently, the download package consists of all the material (that I requested), in the order that Sal implemented it. The result makes perfect sense to someone that already is familiar with the material (i.e, Sal, as developer) but maybe is not so clear to the rest of us (users). My task is to figure out what Sal did, and put it into words so the rest of us can "just use it" without becoming clones of Sal. Propforth should not require users to have Sal's level of expertise, it should be easy enough for a beginner. It is, or would be with proper explanation.
The idea for the documentation is: "These are the functions. Here's how to use them. Go play"
I need your input. Can you give a high level outline of how you need to see the information? How should it best be organized?
I don't imagine this will be quick or short. We can take our time and be driven by user questions, to ensure we don't waste time on topics that aren't of interest.
I've put forth on the side burner until 5.0 comes out. At that point, I was intending on trying to write some documentation and tutorials. I'm currently being distracted by trying to do the same thing with propgcc. I think I learn things better if I try to write about them while I'm playing.
I'll try to start getting back to thinking about forth as winter swoops down upon us.
I use development kernel.
And character"..." is not WORD. It is EOF.
WORD"fbwrite" should search for "...".
But error occure.
I think my sample is wrong.
How can I save forth-code(text file) inside sd-card?
Remove fl from your test.f and you will find that it will work. I have noticed that fl will cause this problem with very short files.
I think it is when the file are shorter than the input buffer length. I have yet to confirm this.
See the file below . It works for me. Ron
hex
10 fbwrite test.f
mountusr
: TEST 5 . ;
...
decimal
I did copy/paste below to TeraTerm. It seem to save test.f in mountsys.
And test.f cannot load.
My SD-function is strange?
I tried to assemble on PF4.6 with SD-function.
I use protoboard.
assembler-file is below;
(this is shift-in/shift-out for sd_driver.f.)
I did load asm.f from eeprom.
Next, copy/paste assembler_file
to TeraTerm.
Result is below;
Next, I tried same thing on QuickStart without SD-function.
result is below;
PropForth4.6 with SD-function cannot assemble asm-code.
Is this normal?
Or my PF4.6 with SD-function is strange?
I think you may have a corrupt sdfs system,. I will start with a clean sdcard and save test.f in the usr partion then re load it from the sdcard. I will get back to you later today (my time)
I will try to track down the fl issue too.
Ron
Cross post did not see your last post when I replied.
Will get back to you
Tested the fwrite and fload. See below the log, with my comments added.
I cannot figure out why it is written to .partion-sys. The file should be written to the current
directory IMO.
I have not tested asm yet with sdfs loaded but I am thinking the code gets cleared by the sddriver sd_cogbufclr. Will check Ron
Create this file greetings.f
fl \ Starts here
5 fwrite greetings.f
: hi c" Hello Caskaz" .cstr cr cr ;
... \ Ends here
paste it to Tera term
Response from Forth
fl
Prop0 Cog0 ok
5 fwrite greetings.f
Prop0 Cog6 ok
Now......
fload greetings.f
Response from Forth
Prop0 Cog0 ok
: hi c" Hello Caskaz" .cstr cr cr ;
Prop0 Cog0 ok
Now enter
hi
Response from forth
Hello Caskaz
Prop0 Cog6 ok
1. fl will cause UNDEFINED WORD ... in a very short files
consisting of only a one or two word definitions when using fwrite or fblock. Refer to Caskaz POST #96 #100
2. Cannot write large files to sdcard. AKA hex 50 fwrite testfile
the directory entry is written but no data. I used my edit_demo to test, which is a 6k text file.
3. Can only fwrite to .partion-sys. Should be able to fwrite to current
directory or to .partion-usr CasKaz POST #100
It seems to be succcess.
But it cannot save in mountusr.
Good, you have success
I cannot save to .partion-usr (mountusr) either. There are some other problems which you have mentioned. Read my post #107 to Prof.
Ron
I
Thanks.
And you can assemble assembler-file?
If you can do it, maybe I have mistake when installing sdfs-system.
Thanks for your investigation on these issues.
Sal is still traveling and I'm cleaning up the bug list in preparation for 5.0 release.
Hopefully these are (already) fixed in 5.0, I will make sure we have tests for these.
Opened issues 73, 74, 75 for the issues described in post #107
No can do....assemble an assemble file
I think forth runs out of room. I know hub is very tight, because I ran out of room recently with my editor program when I stopped using Ramblade and had to create a larger buffer.
I have decided to stay with standard Prop board with just a SDcard for now., so I am playing with a virtual memory system for the SDcard.
I have made a vram. f in .partion-sys. I am writing the driver in forth, but will need to convert is to asm later, so we need to be able asemble files to work with the sdcard driver.
I should have used the sdfs system much earlier, but I have only been using the driver and have not had any problems with that.
Hope Sal has got these issues covered.
Ron
I wrote POV on QuickStart by spin.
It scroll fonts inside ROM.
Looking is fine although simple code.
So, I translated it to PropForth.
I also upload spin-file.
You are the coolest!
POV was the example used in a forth applications class many years ago. The class was given several LED, a hack-saw blade and a solenoid from and old door bell. The idea was to trigger the solenoid and make it strike the saw blade to get it oscillating. Then the LEDs were flashed to make a message.
I guess all that's needed is a transistor, a saw-blade and a solenoid, and we will have the same demo.
Very nice.
I agree with Prof, this is a great project.
When can we have the code for the audio to go with the lyrics. ??
Good Job, it just goes to show how effective the Forth tools can be.
Ron
I do not understand! I pass the rendevous address to the driver from the word blink ( rendevous v_hadr COG!, the adr of rendevous is pushed onto the stack, then top of stack is
popped and stored in cog4 adr at v_hadr )
I would have thought that the driver at line (wrlong _treg4 , __3v_hadr ) would write the char back to the address of rendevous.
In fact it puts the adr of the character in rendevous so in order to display the char I have to setup another level of indirection, see the word disp ( rendevous L@ W@ )
The code does exactly what it is supposed to do, but I would have expected to achieve the same result with ( rendevous W@ )
The program, blink (cog6) starts the driver in cog4 and outputs the character supplied by the driver
The driver runs in Cog4 and blinks the LED on pin 16 then sets up the next char in the alphabet for output by cog6.
I have a wc on the first line of my PASM code. It should not be there, but it does not affect the result
fl hex variable rendevous variable datx 161 wconstant v_hadr 152 asmlabel a_tog 151 wconstant v_char 150 wconstant v_delay 14F wconstant v_pin lockdict variable def_014F 0162 l, 014F l, 00000010 l, 02625400 l, 00000061 l, A1FE1401 l, 2CBE154F l, A0BFED0A l, A0BE17F1 l, 80FE1680 l, A0BE1951 l, A0FE1A1A l, F8BE1750 l, 7CBFE90A l, F8BE1750 l, 78BFE90A l, 083E1961 l, 80FE1801 l, E4FE1B59 l, 5C7C0157 l, 0 l, freedict : lasm 4+ dup L@ swap 4+ swap over L@ dup coghere W! do 4+ dup L@ cog, loop drop ; : start_blink def_014F lasm a_tog ; : disp dup datx L@ <> if dup datx L! emit else drop then ; : blink rendevous v_hadr COG! c" start_blink" 4 cogx begin rendevous L@ W@ disp 0 until ; { fl hex :asm v_pin 10 v_delay 02625400 v_char 61 a_tog mov _treg2 , # 1 wc shl _treg2 , v_pin mov dira , _treg2 mov _treg3 , cnt add _treg3 , # 80 __1 mov _treg4 , v_char mov _treg5 , # 1a __2 waitcnt _treg3 , v_delay muxnz outa , _treg2 waitcnt _treg3 , v_delay muxz outa , _treg2 wrlong _treg4 , __3v_hadr add _treg4 , # 1 djnz _treg5 , # __2 jmp # __1 __3 v_hadr 0 ;asm }I tried QS with no SD-function and ptotoboard with SD-function.
Your code work fine.
By the way , you can assemble asm-code on Propforth4.6 with SD?
I cannot assemble them on my protoboard(PF4.6) with SD.
I cannot assemble asm-code with SD-function. This is a problem
Ok on my code. Yes I know it works but I do not understand why I need to write
: blink rendevous v_hadr COG! c" start_blink" 4 cogx
begin rendevous L@ W@ disp 0 until ;
Why not this way ?? I do not understand ??
: blink rendevous v_hadr COG! c" start_blink" 4 cogx
begin rendevous L@ disp 0 until ;
Ron
I have a revised the code I posted previously. Yes it did work but the code was wrong.
rendevous was ignored in the previous version and the char was always written to hub adr 0
Thats why it worked.
This version now works correctly and can be run from any cog. The par register is required, because the pad area is
different for each cog. The par points to the pad area assigned to the cog running blink.
The char address is written to rendevous so there is a level of indirection, L@ W@ is required.
rendevous is a dictionary word and common to all cogs. It will now hold the correct address for the char
irresective of which cog is running blink.
fl hex variable datx variable rendevous 163 wconstant v_adr 152 asmlabel a_tog 151 wconstant v_char 150 wconstant v_delay 14F wconstant v_pin lockdict variable def_014F 0164 l, 014F l, 00000010 l, 02625400 l, 00000061 l, A0BE1DF0 l, 80FE1C40 l, A0FE1401 l, 2CBE154F l, A0BFED0A l, A0BE17F1 l, 80FE1680 l, A0BE1951 l, A0FE1A1A l, F8BE1750 l, 7CBFE90A l, F8BE1750 l, 78BFE90A l, 083E190E l, 80FE1801 l, E4FE1B5B l, 5C7C0159 l, 00000002 l, freedict : lasm 4+ dup L@ swap 4+ swap over L@ dup coghere W! do 4+ dup L@ cog, loop drop ; : start_blink par COG@ 40 + rendevous L! def_014F lasm a_tog ; : disp dup datx L@ <> if dup datx L! emit else drop then ; : blink c" start_blink" 4 cogx begin rendevous L@ W@ disp 0 until ; { fl hex :asm v_pin 10 v_delay 02625400 v_char 61 a_tog mov _treg6 , par add _treg6 , # 40 mov _treg2 , # 1 shl _treg2 , v_pin mov dira , _treg2 mov _treg3 , cnt add _treg3 , # 80 __1 mov _treg4 , v_char mov _treg5 , # 1a __2 waitcnt _treg3 , v_delay muxnz outa , _treg2 waitcnt _treg3 , v_delay muxz outa , _treg2 wrlong _treg4 , _treg6 add _treg4 , # 1 djnz _treg5 , # __2 jmp # __1 __3 v_adr 2 ;asm }I need to write a few words on *Getting started with Propforth asm.* but rev 5.0 might be different again.
Ron
I have been quietly following in the shadows. I am sure that enough of us out here could "learn" from any info you would be willing to spend the time to share on the topic of getting started with Propforth asm even if it does change in v5.0.
Thanks
I have written a HOW TO but I need to read it again, before I post it. Too late tonight.
Ron
I