Hi.
I found out strange on QuickStart board.
I saved QuickstartTouchSenseBoot-20110623.txt on eeprom of QS.
And I supply 5V at Vin of QS without connecting PC.
TouchSense is a little difficult.
I was able to run the quickstart forth demo from batteries (4x1.2v AA = 4.8v on Vin) with the servo demo.
What is "difficult"? Could it be humidity, dust, etc?
Regarding Open Isues: Sal and I stated to scrub the issues list. The idea is to fix and close out everything for 5.0. If you interested in any open issue, now is the time to provide input. Turns out most are already fixed and just need to be verified (by me) as "works per design". If you find this in error, or have conflicts with the current design. bring it up now so we can discuss and make adjustments before 5.0 RC (release candidate) is ready. Sal will be working the items tagged with his name, these are a bit interesting.
Please notes issues for CREATE, DOES>, ... , and WORDS (lists for different vocabularies). Standard forth definitions for these words present a conflict for propforth, so these need additional consideration.
I added formatted number displays to the serial LCD display code for dec, bin, and hex ... here is the updated code. Still to be done ... a thoroughly annotated demo ...
I added formatted number displays to the serial LCD display code for dec, bin, and hex ... here is the updated code. Still to be done ... a thoroughly annotated demo ...
When supplying 5V in QuickStart-board's Vin, response for TouchPad is very slow.
Although I touch pad, LED is not on soon. It takes a little time.
When connecting to PC with USB, its response is normal.
It's pulse-monitor.
Hemoglobin among blood absorb infrared(700nm - 1200nm).
Using photo-reflector's(LBR-127HLD) infrared emitting wavelength is 940nm(Peak).
LM358 amplify AC(pulse-signal) of sensor-output and Prop get pulse.
Loading 2_wire_LCD_1.5 and BigFont_0.2 and pulse_monitor_0.1
When supplying 5V in QuickStart-board's Vin, response for TouchPad is very slow, LED is not on soon. It takes a little time.
When connecting to PC with USB, its response is normal.
I think I noticed similar. This could be due to the buffering circuit on the resistive touch buttons. There had been some discussion on other quickstart threads, and resulted in several versions of the demo. I didn't find it annoying, I only use it as a demo to show that the program is running. Is it a problem or are you just curious?
Dude, you are too fast for me.
Can you post this on the google code site?
We need a separate archive for all your drivers and experiments.
When we get the automated testing running, I want to make demos for all your code.
My codes is incomplete. And some codes is worthless.
A few people watch the google code site.
But everybody can see my codes when I post junk-code on this Forum.
Some people might point out my mistake.
DownloadCount of PropForth4.6 is 141.
I expect anybody take an interest in PropForth.
Hi.
I updated pulse_monitor.
I found out amp-out-signal for pulse is affected by LCD's backlight control(1kHz).
I think this is solved by using shield-line.
I took easy way. I used LCD without backlight.
WORD"pulse"
Measured signal's time for pulse
1. waiting for High
2. waiting for Low
3. Starting time-measuring
Loading cnt.
If time exceed 1second, this is error.
waiting for High
4. If time exceed 1second, this is error.
waiting for Low
5. Loading cnt.
Calculating time-difference.
Store time-difference to pulse_array
pulse_array has 8-Long. Old one is deleted and new is stored to pulse_array's last.
Calculating pulse-figure per minute. Store value to pulse_rate.
6 repeat to 1.
WORD"pulse_monitor"
Display pulse-value per min on LCD
1. Execute WORD"pulse" on Cog5
2. Initialize LCD
3. Set BigFont
4. waiting 1second.
Loading pulse_rate
If pulse_count is 0, display "--"
If pulse_rate exceed 200, this value is ignored.
Put value to LCD.
5. repaet to 4
Hi.
I calculated timeshift for DS3231.
I setted time to use denpatokei on 8/22 0:00.(temp=32.00degree) WORD'set_DS3231'
I measured timeshift today.(temp=34.25degree)
8/22 00:00 -- 10/22 22:00 = 59days 22Hour = 5176800sec
Measured >1sec to use WORD'timeshift_>1sec' ==> 3second
Measured <1sec to use WORD'timeshift_<1sec' ==> 59067424(d) ticks
Measured 1second to use WORD'check_1Hz' ===> 80003504(d) ticks
1Hz_pulse's 1st is Low(0.5sec), 2nd is High(0.5sec)
I saw the proposal to move the dictionary on to SD card for Propforth 5.00.
I can understand the need to create more room in HUB ram, but it will limit Propforth to Propboards which do not share data and address lines between
storage devices and/or peripherals.
What about Prop boards which don't have an SDcard, will they be limited to a forthbootkernal, leaving users to add to the kernel ???
Will the two systems be maintained ??
Don't get me wrong I think its a great idea but I would like to think the forthbootkernal is common to
both dictionary configurations and that some sort of configuration arrangement is provided so that users can select where the dictionary is located.
FYI my work around using Propforth 4.6 on Rambladeis is set out below, but Propforth 5.0 would render Ramblade useless
I have no idea how many other boards share address and data lines/pins between devices, but its not uncommon, why else do we have a CS
or CE pin on storage devices.
The Ramblade board, for example, shares the SDO and SDI pins with two of the 8 bit data lines of my 512k byte external sram.
So I have to unmount the SDcard and re_mount the SDcard between each 512k byte blockread and blockwrite, it's horrible, but it works.
Fortunately it only comes into play when saving or loading a text file after an edit session. The unmount and mount words below are executed
in the sddriver cog 0 from cog 6 using cogx. (necessary due to the wired ORed pins) Cog 6 being my default working cog.
: unmount _sd_cs_out_h ; \ deselect sdcard by setting cs pin high
: mount sd_init mountsys ; \ restart sdcard and usr file sys. It's not too painful
move the dictionary on to SD card for Propforth 5.00.
What about Prop boards which don't have an SDcard, will they be limited to a forthbootkernal, leaving users to add to the kernel ???
Propforth ALWAYS runs on ALL prop chips is our rule of thumb. The design is intended to allow Extensions to accommodate additonal hardware.
The BOOT kernel (defined in high level forth, minimal dictionary, hex default number base, no error message text, no development utilities) runs on any prop
The DEV kernel (defined in high level forth, regular dictionary, decimal default number base, error message stubs, most development utilites) runs on any prop
The OPTIMIZED kernel (most functions optimized in assembly version of DEV kernel, ultra small dictionary, crazy fast) runs on prop with appropriate hardware (SD card, insanely large EEPROM, etc)
From any starting kernel one may create the other kernels. Any kernel may be modified or optimized as the user wishes, (but we have to show Sal the code if we want him to help debug it).
FYI my work around using Propforth 4.6 on Rambladeis is set out below, but Propforth 5.0 would render Ramblade useless
Have no fear, nothing will be rendered useless. PF5.0 has some differences from 4.6, but porting should take about 6 minutes. Sal's pretty good about paying attention to this stuff.
: unmount _sd_cs_out_h ; \ deselect sdcard by setting cs pin high
: mount sd_init mountsys ; \ restart sdcard and usr file sys. It's not too painful
Thanks, Sal mentioned something like this. I think there was one more part to the unmount to free up memory, but I might be mistaken. It should be included in the archive after we complete the regression tests and scrub the issues list (unless we determine it causes more problems than it solves)
I don't normally lurk here. My RamBlade, now like many other pcbs, share lines with the SD (microSD) pins.
However, it should not be necessary to unmount and mount the SD card between accesses. It should only be required that the SD be deselected (all pins go tristate) between SD accesses. The glitch found a long time ago was that it was necessary to give the SD card some clk pulses after CS was disabled because some(?) SD cards did not tristate their DO pin until this happened. I would expect any software driver (on the prop) to release CS after SD access completes, and to optionally provide these clocks to enforce DO is tristated. This is certainly the case with the SD drivers I have tested.
Ray my unmount definition, in Forth terms, simple means deselecting the CS pin.. The fact is, SDO is shared its always going to be a bit flakey to expect it is to recover on reselecting CS without the standard set up routine. 512k block transfers is tolerable between deselecting and reselecting the sdcard
@Prof
In general I think Propforth needs to take account of the fact that data and address lines are often shared, so its good practice to allow for that in
the design. Proforth is very robust, the last thing we need is to be reliant on flakey sdcard recovery. If you use just reselect the sdcard and just use
sd_init the card will recover but you need mountsys( I think) to init the file system correctly. I would like to think it was possible to keep the dictionary
on the sdCard but my gut feeling is that it will be too slow. I have not been successful in recovering the sdcard by just resetting the CS pin. I will do some
tests using PASM to check if the SDcard will recover when reselecting the card
BTW yes, you are right, there is one other thing that I forgot to add in the unmount word. You need to clear the 128 longs in the cog above cogbuf using sd_cogbufclr. Or are you refering to the big endian packed longs, if so the editor does not care, but the data can't be read off the sdcard by other software unless is is re packaged.
... Propforth needs to take account of the fact that data and address lines are often shared...
I think this was left to the user to address simplicity, size, and function creep. Any insights or efforts you make in this area will of course be applied to the next release. Sort of over my head, my impression was that Sal just adds another prop when he runs out of pins or cogs, I never have yet.
Could this be done as an extension, or are you think kernel change is needed?
... flakey sdcard recovery...
make a new issue for particulars and we will work it
dictionary on the sdCard but my gut feeling is that it will be too slow.
Sal says PF5.0 is significantly faster than 4.6. To the extent of "you can feel the difference". I believe this because the transfer is optimized, there is no FAT on the SD, and the asssembler is paged. I have not played with it yet, only parts of the internal alpha, but the impression I got from Sal was that paged assembler on SD kernel makes the old kernel look like a sleeping dog. But I might have misunderstood, I tend to hear what I like to hear, rather than what was actually said. We will be doing some oranges to oranges comparisions when 5.0 comes out.
I have not been successful in recovering the sdcard by just resetting the CS pin.
Please get in contact with caskaz, he knows more than I.
[/QUOTE] editor does not care, but the data can't be read off the sdcard by other software[/QUOTE]
We had thought that having the SD cog handle all transactions and access one file at a time (last file accessed is current file for all) would take care of that. We need to clarify the use notes, or otherwise account for changes to the architecture. This might be best held until 5.0.
1. Clusso99 statement only reinforces my concern, " CS should be released after SD access ".
If the dictionary was to be moved onto SDcard the SD CS line would need to be enabled to access the dictionary and then be released before Forth executes the word. Mounting the SDcard and umounting each time the dictionary if accessed so frequently would stall forth..
In Forth 4.6 i the SD CS line is selected and held hold it for the duration of the Forth session.
This approach does not take account of boards that share data and address lines between storage devices, therefore changes are required, if it is decided to support these other boards. (where to keep the dictionary is a problem)
I am not concerned about clocking after CS it is released. Now we know about it, the fix is trival.
In summary, only one storage device should be open at any one time. The selected storage device should be released after access (a blockread or blockwrite) then there would be no data or address conficts. How this buffering is done is best left to the Forth user. IMO
Hope that makes sense
Ron
BTW the issue you raised in Wilki seems to cover it
OK, I added post post #80 to the issue so Sal can find it. I don't know a lot of particulars aside from the current architecture was one device per one pin, the impact of multiplexing will be an interesting investigation.
Sal doesn't have C3 (or RamBlade) for testing, but but he should be able to look at mine over the internet once we get 5.0 kernel ready.
If you get started looking into solutions, any code for experiments or implementation would move thing forward.
Multiplexing will be an interesting instigation ?????.
I don't think I have ever suggested that.
One pin for each device (CS or CE) which can be selected/enabled then released before another device is selected, but I think that's what you were getting at.
Having read the +Prop External Hardware Survey+ thread it's is fairly obvious that my idea of just deselecting the CE/CS pin on a device is not going to
solve the confict issues for all these boards. Even if the SDcard is deselected, the SDdriver itself may continue to clock the SDcard unless the SDdriver is aware that some other process had deselected the SDcard. If this was so and the SD clk line is shared with the data line of other devices, (ramblade is one)a potential conflict exists. It looks like we need a simple method of pausing the SDdriver without resetting the cog
The only way I have been able to copy from xmem to SDcard is as follows
1 Stop the SDdriver
2 Copy a external mem Blk to Hub
3 Restart SDdriver
4 Copy Hub Blk to SDdriver cog starting at adr sd_cogbuf
5 Do a sd_blockwrite to the sdcard
This is required for every blk transfered.
Please pass these notes on to Sal for his comments. I think that the other issues that I raised are better covered in this post. Maybe it would be better
to clear those issues and replace it with these notes.
BTW You said that PropForth was using an SDcard as RAM, I would like to see some code for that.
Has Caz done this ?? Its something that I was going to play with whilst we get some direction from SAL. I have a propmod board with SDcard
(no external Sram) I will play with the SDRAM driver idea. I would like to see if I can get my Editor going using SDcard ram.
BTW You said that PropForth was using an SDcard as RAM, I would like to see some code for that.
Has Caz done this ?? Its something that I was going to play with whilst we get some direction from SAL. I have a propmod board with SDcard
(no external Sram) I will play with the SDRAM driver idea. I would like to see if I can get my Editor going using SDcard ram.
Cheers Ron
I can only imagine that what is meant is that the SD card or other mass storage device is treated as a standard block device along with byte/word/long etc operators such as @ and ! that take an address and this accesses the storage device in a linear fashion without regard to file storage systems etc.This was very common in the early days of Forth to treat the floppy or hard-drive as a virtual memory device. The primitives would work out which block (1k traditionally) of the storage device that needed to be read into RAM buffers and if it was not already there it would perform a read. If the virtual memory was written to then a "write" flag would be set to ensure this buffer was written before being flushed etc.
So by using such virtual memory primitives the mass storage device effectively looks like "RAM" to the application although it does not have the same speed or guaranteed latency as a buffer might need to be written before another read can be performed etc.
So by using such virtual memory primitives the mass storage device effectively looks like "RAM" to the application although it does not have the same speed or guaranteed latency as a buffer might need to be written before another read can be performed etc.
What Peter said, only difference is that the default design only has/allows/needs one block open at a time, so the overhead is small. The idea is that a given block is immediately written, it is not held open, buffering is something to be handled in the application. The result is that the access speed and latency approaches that of the SD card itself. Which can be, depending on the card, "purdy-dern-snappy" , to use the technical term. Remember, this is a trade-off, best speed and biggest size for lowest cost. If you plan to handle 1920x1200 full color HD video, you might have better results with something else; but if you want 512 bytes every tens or hundreds of milliseconds up to 2 Gig or so, this might be useful.
Yes, thats problably what Prof was getting at. The Propforth SDSYS however does not use virtual memory or caching, which is really required if you want use the SDcard for RAM.
I re-built Propforth with the SDdriver only ( no file system). With a newly formatted Sdcard I am able to read and write to any block on the SDcard. This means that I can play with SDram above 2 gigs and leave the File system intact.
Prof the last Block remains in cog ram starting adr sd_cogbuf'. It is cleared on cog resest or before another sd_rd or sd_wr is executed.
I am using the cogbuf as my edit buffer.
Do cogdump and see for youself.
Whoops you maybe right, it may be cleared following one of the above operations, Its for me to check. LOL
I am using the cog buffer as the edit buffer BEFORE I write it the buffer to SDcard
I believe you are correct, the cogbuf is "cleared" only as a side affect of the read. That is, it is not specifically cleared.
After the last write to SD, the cogbuf is not changed until new data is read from the card, or the application changes it.
Comments
I found out strange on QuickStart board.
I saved QuickstartTouchSenseBoot-20110623.txt on eeprom of QS.
And I supply 5V at Vin of QS without connecting PC.
TouchSense is a little difficult.
This phenomenon is only me?
What is "difficult"? Could it be humidity, dust, etc?
http://code.google.com/p/propforth/wiki/IssueListScrub
Please notes issues for CREATE, DOES>, ... , and WORDS (lists for different vocabularies). Standard forth definitions for these words present a conflict for propforth, so these need additional consideration.
When supplying 5V in QuickStart-board's Vin, response for TouchPad is very slow.
Although I touch pad, LED is not on soon. It takes a little time.
When connecting to PC with USB, its response is normal.
It's pulse-monitor.
Hemoglobin among blood absorb infrared(700nm - 1200nm).
Using photo-reflector's(LBR-127HLD) infrared emitting wavelength is 940nm(Peak).
LM358 amplify AC(pulse-signal) of sensor-output and Prop get pulse.
Loading 2_wire_LCD_1.5 and BigFont_0.2 and pulse_monitor_0.1
I think I noticed similar. This could be due to the buffering circuit on the resistive touch buttons. There had been some discussion on other quickstart threads, and resulted in several versions of the demo. I didn't find it annoying, I only use it as a demo to show that the program is running. Is it a problem or are you just curious?
These guys have some detailed information, maybe this would help?
http://forums.parallax.com/showthread.php?132267-Alternative-mode-for-the-QuickStart-touch-buttons
Dude, you are too fast for me.
Can you post this on the google code site?
We need a separate archive for all your drivers and experiments.
When we get the automated testing running, I want to make demos for all your code.
My codes is incomplete. And some codes is worthless.
A few people watch the google code site.
But everybody can see my codes when I post junk-code on this Forum.
Some people might point out my mistake.
DownloadCount of PropForth4.6 is 141.
I expect anybody take an interest in PropForth.
I updated pulse_monitor.
I found out amp-out-signal for pulse is affected by LCD's backlight control(1kHz).
I think this is solved by using shield-line.
I took easy way. I used LCD without backlight.
WORD"pulse"
Measured signal's time for pulse
1. waiting for High
2. waiting for Low
3. Starting time-measuring
Loading cnt.
If time exceed 1second, this is error.
waiting for High
4. If time exceed 1second, this is error.
waiting for Low
5. Loading cnt.
Calculating time-difference.
Store time-difference to pulse_array
pulse_array has 8-Long. Old one is deleted and new is stored to pulse_array's last.
Calculating pulse-figure per minute. Store value to pulse_rate.
6 repeat to 1.
WORD"pulse_monitor"
Display pulse-value per min on LCD
1. Execute WORD"pulse" on Cog5
2. Initialize LCD
3. Set BigFont
4. waiting 1second.
Loading pulse_rate
If pulse_count is 0, display "--"
If pulse_rate exceed 200, this value is ignored.
Put value to LCD.
5. repaet to 4
I calculated timeshift for DS3231.
I setted time to use denpatokei on 8/22 0:00.(temp=32.00degree) WORD'set_DS3231'
I measured timeshift today.(temp=34.25degree)
8/22 00:00 -- 10/22 22:00 = 59days 22Hour = 5176800sec
Measured >1sec to use WORD'timeshift_>1sec' ==> 3second
Measured <1sec to use WORD'timeshift_<1sec' ==> 59067424(d) ticks
Measured 1second to use WORD'check_1Hz' ===> 80003504(d) ticks
1Hz_pulse's 1st is Low(0.5sec), 2nd is High(0.5sec)
(80003504 - 59067424)/80003504 = 0.261second
3.261sec/5176800sec = 0.00000063 = +0.63ppm
This value is very small. (DS3231 spec:+-2ppm)
I saw the proposal to move the dictionary on to SD card for Propforth 5.00.
I can understand the need to create more room in HUB ram, but it will limit Propforth to Propboards which do not share data and address lines between
storage devices and/or peripherals.
What about Prop boards which don't have an SDcard, will they be limited to a forthbootkernal, leaving users to add to the kernel ???
Will the two systems be maintained ??
Don't get me wrong I think its a great idea but I would like to think the forthbootkernal is common to
both dictionary configurations and that some sort of configuration arrangement is provided so that users can select where the dictionary is located.
FYI my work around using Propforth 4.6 on Rambladeis is set out below, but Propforth 5.0 would render Ramblade useless
I have no idea how many other boards share address and data lines/pins between devices, but its not uncommon, why else do we have a CS
or CE pin on storage devices.
The Ramblade board, for example, shares the SDO and SDI pins with two of the 8 bit data lines of my 512k byte external sram.
So I have to unmount the SDcard and re_mount the SDcard between each 512k byte blockread and blockwrite, it's horrible, but it works.
Fortunately it only comes into play when saving or loading a text file after an edit session. The unmount and mount words below are executed
in the sddriver cog 0 from cog 6 using cogx. (necessary due to the wired ORed pins) Cog 6 being my default working cog.
: unmount _sd_cs_out_h ; \ deselect sdcard by setting cs pin high
: mount sd_init mountsys ; \ restart sdcard and usr file sys. It's not too painful
Just something to think about
Cheers
Ron
Propforth ALWAYS runs on ALL prop chips is our rule of thumb. The design is intended to allow Extensions to accommodate additonal hardware.
The BOOT kernel (defined in high level forth, minimal dictionary, hex default number base, no error message text, no development utilities) runs on any prop
The DEV kernel (defined in high level forth, regular dictionary, decimal default number base, error message stubs, most development utilites) runs on any prop
The OPTIMIZED kernel (most functions optimized in assembly version of DEV kernel, ultra small dictionary, crazy fast) runs on prop with appropriate hardware (SD card, insanely large EEPROM, etc)
From any starting kernel one may create the other kernels. Any kernel may be modified or optimized as the user wishes, (but we have to show Sal the code if we want him to help debug it).
Have no fear, nothing will be rendered useless. PF5.0 has some differences from 4.6, but porting should take about 6 minutes. Sal's pretty good about paying attention to this stuff.
Thanks, Sal mentioned something like this. I think there was one more part to the unmount to free up memory, but I might be mistaken. It should be included in the archive after we complete the regression tests and scrub the issues list (unless we determine it causes more problems than it solves)
We will run it by you before it is finalized.
However, it should not be necessary to unmount and mount the SD card between accesses. It should only be required that the SD be deselected (all pins go tristate) between SD accesses. The glitch found a long time ago was that it was necessary to give the SD card some clk pulses after CS was disabled because some(?) SD cards did not tristate their DO pin until this happened. I would expect any software driver (on the prop) to release CS after SD access completes, and to optionally provide these clocks to enforce DO is tristated. This is certainly the case with the SD drivers I have tested.
http://code.google.com/p/propforth/issues/detail?id=67
Ray my unmount definition, in Forth terms, simple means deselecting the CS pin.. The fact is, SDO is shared its always going to be a bit flakey to expect it is to recover on reselecting CS without the standard set up routine. 512k block transfers is tolerable between deselecting and reselecting the sdcard
@Prof
In general I think Propforth needs to take account of the fact that data and address lines are often shared, so its good practice to allow for that in
the design. Proforth is very robust, the last thing we need is to be reliant on flakey sdcard recovery. If you use just reselect the sdcard and just use
sd_init the card will recover but you need mountsys( I think) to init the file system correctly. I would like to think it was possible to keep the dictionary
on the sdCard but my gut feeling is that it will be too slow. I have not been successful in recovering the sdcard by just resetting the CS pin. I will do some
tests using PASM to check if the SDcard will recover when reselecting the card
BTW yes, you are right, there is one other thing that I forgot to add in the unmount word. You need to clear the 128 longs in the cog above cogbuf using sd_cogbufclr. Or are you refering to the big endian packed longs, if so the editor does not care, but the data can't be read off the sdcard by other software unless is is re packaged.
Cheers
Ron
I think this was left to the user to address simplicity, size, and function creep. Any insights or efforts you make in this area will of course be applied to the next release. Sort of over my head, my impression was that Sal just adds another prop when he runs out of pins or cogs, I never have yet.
Could this be done as an extension, or are you think kernel change is needed?
make a new issue for particulars and we will work it
Sal says PF5.0 is significantly faster than 4.6. To the extent of "you can feel the difference". I believe this because the transfer is optimized, there is no FAT on the SD, and the asssembler is paged. I have not played with it yet, only parts of the internal alpha, but the impression I got from Sal was that paged assembler on SD kernel makes the old kernel look like a sleeping dog. But I might have misunderstood, I tend to hear what I like to hear, rather than what was actually said. We will be doing some oranges to oranges comparisions when 5.0 comes out.
Please get in contact with caskaz, he knows more than I.
[/QUOTE] editor does not care, but the data can't be read off the sdcard by other software[/QUOTE]
We had thought that having the SD cog handle all transactions and access one file at a time (last file accessed is current file for all) would take care of that. We need to clarify the use notes, or otherwise account for changes to the architecture. This might be best held until 5.0.
1. Clusso99 statement only reinforces my concern, " CS should be released after SD access ".
If the dictionary was to be moved onto SDcard the SD CS line would need to be enabled to access the dictionary and then be released before Forth executes the word. Mounting the SDcard and umounting each time the dictionary if accessed so frequently would stall forth..
In Forth 4.6 i the SD CS line is selected and held hold it for the duration of the Forth session.
This approach does not take account of boards that share data and address lines between storage devices, therefore changes are required, if it is decided to support these other boards. (where to keep the dictionary is a problem)
I am not concerned about clocking after CS it is released. Now we know about it, the fix is trival.
In summary, only one storage device should be open at any one time. The selected storage device should be released after access (a blockread or blockwrite) then there would be no data or address conficts. How this buffering is done is best left to the Forth user. IMO
Hope that makes sense
Ron
BTW the issue you raised in Wilki seems to cover it
Sal doesn't have C3 (or RamBlade) for testing, but but he should be able to look at mine over the internet once we get 5.0 kernel ready.
If you get started looking into solutions, any code for experiments or implementation would move thing forward.
Multiplexing will be an interesting instigation ?????.
I don't think I have ever suggested that.
One pin for each device (CS or CE) which can be selected/enabled then released before another device is selected, but I think that's what you were getting at.
I am back to my qwerty keyboard now.
Ron
Having read the +Prop External Hardware Survey+ thread it's is fairly obvious that my idea of just deselecting the CE/CS pin on a device is not going to
solve the confict issues for all these boards. Even if the SDcard is deselected, the SDdriver itself may continue to clock the SDcard unless the SDdriver is aware that some other process had deselected the SDcard. If this was so and the SD clk line is shared with the data line of other devices, (ramblade is one)a potential conflict exists. It looks like we need a simple method of pausing the SDdriver without resetting the cog
The only way I have been able to copy from xmem to SDcard is as follows
1 Stop the SDdriver
2 Copy a external mem Blk to Hub
3 Restart SDdriver
4 Copy Hub Blk to SDdriver cog starting at adr sd_cogbuf
5 Do a sd_blockwrite to the sdcard
This is required for every blk transfered.
Please pass these notes on to Sal for his comments. I think that the other issues that I raised are better covered in this post. Maybe it would be better
to clear those issues and replace it with these notes.
BTW You said that PropForth was using an SDcard as RAM, I would like to see some code for that.
Has Caz done this ?? Its something that I was going to play with whilst we get some direction from SAL. I have a propmod board with SDcard
(no external Sram) I will play with the SDRAM driver idea. I would like to see if I can get my Editor going using SDcard ram.
Cheers Ron
I can only imagine that what is meant is that the SD card or other mass storage device is treated as a standard block device along with byte/word/long etc operators such as @ and ! that take an address and this accesses the storage device in a linear fashion without regard to file storage systems etc.This was very common in the early days of Forth to treat the floppy or hard-drive as a virtual memory device. The primitives would work out which block (1k traditionally) of the storage device that needed to be read into RAM buffers and if it was not already there it would perform a read. If the virtual memory was written to then a "write" flag would be set to ensure this buffer was written before being flushed etc.
So by using such virtual memory primitives the mass storage device effectively looks like "RAM" to the application although it does not have the same speed or guaranteed latency as a buffer might need to be written before another read can be performed etc.
What Peter said, only difference is that the default design only has/allows/needs one block open at a time, so the overhead is small. The idea is that a given block is immediately written, it is not held open, buffering is something to be handled in the application. The result is that the access speed and latency approaches that of the SD card itself. Which can be, depending on the card, "purdy-dern-snappy" , to use the technical term. Remember, this is a trade-off, best speed and biggest size for lowest cost. If you plan to handle 1920x1200 full color HD video, you might have better results with something else; but if you want 512 bytes every tens or hundreds of milliseconds up to 2 Gig or so, this might be useful.
Added post#83 info to issue 67
Yes, thats problably what Prof was getting at. The Propforth SDSYS however does not use virtual memory or caching, which is really required if you want use the SDcard for RAM.
I re-built Propforth with the SDdriver only ( no file system). With a newly formatted Sdcard I am able to read and write to any block on the SDcard. This means that I can play with SDram above 2 gigs and leave the File system intact.
Cheers
Ron
BTW I spent 30 years in Sydney.
Sorry Prof didn't see your last post
I am using the cogbuf as my edit buffer.
Do cogdump and see for youself.
Whoops you maybe right, it may be cleared following one of the above operations, Its for me to check. LOL
I am using the cog buffer as the edit buffer BEFORE I write it the buffer to SDcard
Ron
Ron
After the last write to SD, the cogbuf is not changed until new data is read from the card, or the application changes it.
The edit_demo file is the result of trying to get to grips with the PropForth SDdriver over the last few days
Cheers
Ron
I have question.
How do I save forth-code(2_wire_LCD_1.5.f) on internal SD-card?