@Rayman said:
@ersmith A PSRAM based file system would be pretty neat. Lot of moving parts to make that work I think. Not exactly sure how practical for use it is, but interesting to think about.
A PSRAM block device to interact with littlefs should be straightforward to implement. Littlefs already supports RAM disks from HUB and from HyperFlash. Unfortunately I haven't been able to find any simple working PSRAM demo code, or at least none that I've been able to get working . I'm sure that's my fault, I haven't had time to really dig into it. The ramdisk code I did manage to get working (HyperFlash and RAM) is in examples/shell/shell.c (for the /ram file system).
@ersmith said:
A PSRAM block device to interact with littlefs should be straightforward to implement. Littlefs already supports RAM disks from HUB and from HyperFlash. Unfortunately I haven't been able to find any simple working PSRAM demo code, or at least none that I've been able to get working . I'm sure that's my fault, I haven't had time to really dig into it. The ramdisk code I did manage to get working (HyperFlash and RAM) is in examples/shell/shell.c (for the /ram file system).
It should be possible to use PSRAM for a RAM disk if you have HyperRAM going as they use the same fundamental interface in my drivers. I think you may just require the later memory driver that supports it. I took a look at your SPIN include folder in spin2cpp that contains some of this and the file you called HyperMemory.spin2 seems to be based on my original 0.8b HyperRAM memory driver file I put together before PSRAM was supported. There is a simpler PSRAM interface these days for video use but IIRC there should also be support for PSRAM in the updated memory.spin2 file in the later 0.9b release (at top post of Memory driver thread) that works similar to HyperRAM, and you might like to look at that sometime. Wuerfel_21 is correct in mentioning that input delays need tuning for different HW boards although I think the default timing profile should work with the P2-Edge PSRAM (at room temps anyway) .
@rogloh said:
It should be possible to use PSRAM for a RAM disk if you have HyperRAM going as they use the same fundamental interface in my drivers. I think you may just require the later memory driver that supports it. I took a look at your SPIN include folder in spin2cpp that contains some of this and the file you called HyperMemory.spin2 seems to be based on my original 0.8b HyperRAM memory driver file I put together before PSRAM was supported. There is a simpler PSRAM interface these days for video use but IIRC there should also be support for PSRAM in the updated memory.spin2 file in the later 0.9b release (at top post of Memory driver thread) that works similar to HyperRAM, and you might like to look at that sometime. Wuerfel_21 is correct in mentioning that input delays need tuning for different HW boards although I think the default timing profile should work with the P2-Edge PSRAM (at room temps anyway) .
Unfortunately I don't have a P2 Edge with PSRAM yet (I have ordered one). I do have some of @Rayman 's nice PSRAM boards, but the drivers for those don't seem to be in the memory thread (or I couldn't find them). I grabbed some drivers from MegaYume, but they don't work for me. Again, almost certainly something I've done wrong, I haven't had time to really dig into it, I was just hoping that the code would plug and play.
@ersmith said:
Unfortunately I don't have a P2 Edge with PSRAM yet (I have ordered one). I do have some of @Rayman 's nice PSRAM boards, but the drivers for those don't seem to be in the memory thread (or I couldn't find them). I grabbed some drivers from MegaYume, but they don't work for me. Again, almost certainly something I've done wrong, I haven't had time to really dig into it, I was just hoping that the code would plug and play.
Yes fair enough, maybe best to wait for a PSRAM P2 Edge to arrive for a more consistent HW setup to base it off, and one that plenty of others will have too. There were some patched/test drivers for those larger boards buried somewhere in the memory thread (or perhaps in one of Rayman's or Wuerfel_21's threads), as they needed modifications to adjust for different bit widths and chip select options and reduced speeds to work right. I know I sent a bunch of patched drivers to Wuerfel_21 too while we were figuring some of it out and parts of that probably made its way into her NeoYume codebase. Would need some digging to find it all, so perhaps focus on the P2 Edge for now once you get the shipment. Other boards support can then follow once the core is working.
@ersmith I'm not seeing an "Identify" feature in the FlexProp menu. I find this very useful in Prop Tool to make first contact with a new board...
Is this hard to add?
Another question, just in case this is just a really old version of FlexProp....
How hard is it to have FlexProp GUI, on startup, check the web for what the latest release is and give a notice if current version is not the latest?
And, maybe making this a feature that can be disabled?
@Rayman said:
@ersmith I'm not seeing an "Identify" feature in the FlexProp menu. I find this very useful in Prop Tool to make first contact with a new board...
Is this hard to add?
@Rayman said:
I guess ideally, the same as Prop Tool. It basically just resets the Prop and probes it with serial to see what kind it is and if it able to reply.
Pretend I've never seen Prop Tool (which isn't far off the mark). So what should the Identify menu item do? Does it probe just one serial port and report on the device, if any, found on that port? Does it probe all ports and report on the first device found on any port? Does it probe all ports and report on all devices found on all ports? What does it report -- just P1 or P2, or is there additional information it should show?
FlexProp 6.3.0 has been released on my GitHub page and on Patreon. Besides the usual bug fixes, this version has several new features:
#pragma exportdef allows #define statements in one source file to be exported to others; this is useful for specifying driver names and other strings
the littlefs file system ramdisk support has been extended to include hyperram, 4 bit PSRAM, and 16 bit PSRAM (e.g. the P2-EC32MB Edge board). The hyperram actually should have worked in the previous releases, but due to a typo the wrong version of the file was checked in
To try out the littlefs RAM disks, edit the file samples/shell/shell.c; near the top are a set of #if / #elif clauses for the various RAM disk types. The version checked in is for the 32 MB P2 Edge board, as that is probably the most common, but you can change this to suit your setup. At runtime, mount /ram will mount a ramdisk, which may usefully be used for temporary storage during transfers between flash and SD card (since these cannot both be mounted at the same time).
@ersmith said:
... - the littlefs file system ramdisk support has been extended to include hyperram, 4 bit PSRAM, and 16 bit PSRAM (e.g. the P2-EC32MB Edge board). The hyperram actually should have worked in the previous releases, but due to a typo the wrong version of the file was checked in
Great stuff. Glad to see you have some support for PSRAM in there now. I'll have to give it a try soon.
@Wuerfel_21 said:
No 96MB board support? ;3
I guess ramdisk is another use case for that much memory...
It's probably doable, as there is some support for the slower sysclk/3 and sysclk/4 clock rates it needed for its high fanout already in the 8 bit PSRAM driver. This 8 bit bus driver seems to be present, just needs its API to init it and setup the banks correctly. Was there a special custom version of it for 96MB clock/CE mapping? Given you wanted it for NeoYume you'll probably recall better than me the history of that variant...
As the number of board configurations have proliferated we probably need some more init API abstraction or additional parameters so this sort of board selection can be passed down from a higher level going forward. Or do we want the user to have to configure some of this themselves...? Tricky.
By the way, any transfer between HUB and external RAMs spanning different memory device banks will not currently be broken up automatically by the low level APIs. For a sector based access system that is already aligned on 2^n boundaries (such as a RAM disk should be doing) this is not an issue, but for arbitrary transfers of any size at any address it may become so. It probably needs some address+length testing to check that the address range does not cross a device boundary and then split the transfer into two or more transfers accordingly. This also happens internally for the 16MB HyperRAMs (which are internally just two 8MB dies coupled together). Until now with effectively single RAM bank devices like the P2-EC32MB and the HyperRAM module, it hasn't really been an issue, but could become so once people start to use this external memory randomly/arbitrarily like regular RAMs and have lots of devices on board. In my full blown memory driver which was originally intended for multiple banks and multiple memory types I was planning to add this check to the topmost API so it could split the transfer requests across different drivers and make it look like a single address space, but haven't yet looked at it within a given wrapper driver like we have for PSRAM. Something more to do when I get back onto it....
@ersmith said:
... - the littlefs file system ramdisk support has been extended to include hyperram, 4 bit PSRAM, and 16 bit PSRAM (e.g. the P2-EC32MB Edge board). The hyperram actually should have worked in the previous releases, but due to a typo the wrong version of the file was checked in
Great stuff. Glad to see you have some support for PSRAM in there now. I'll have to give it a try soon.
Thanks for providing the drivers! I'm not sure if I have the latest versions of everything, if I don't then please let me know.
As the number of board configurations have proliferated we probably need some more init API abstraction or additional parameters so this sort of board selection can be passed down from a higher level going forward. Or do we want the user to have to configure some of this themselves...? Tricky.
That's kind of what the #pragma exportdef was designed for. As you'll see when you look at shell.c, I used that to select the PSRAM driver, and constant overrides to select parameters like pins.
@ersmith said:
Pretend I've never seen Prop Tool (which isn't far off the mark). So what should the Identify menu item do? Does it probe just one serial port and report on the device, if any, found on that port? Does it probe all ports and report on the first device found on any port? Does it probe all ports and report on all devices found on all ports? What does it report -- just P1 or P2, or is there additional information it should show?
I think it only uses the first it finds. Which is pretty useless for me since I generally always have multiple Props attached. What order the scan is I don't know.
PS: I always use the by-id path spec. No order confusion this way.
You have to use search very carefully, or this happens:
bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs
bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs
while executing
"$t tag config hilite -background yellow"
invoked from within
"if ![winfo exists $w] {
toplevel $w
wm title $w "Search"
grid [label $w.1 -text Find:] [entry $w.f -textvar Find] [ttk::button $..."
(procedure "searchrep" line 5)
invoked from within
"searchrep [focus] 0"
(menu invoke)
Edit: yet another, slightly different. And if this occurs, no more searching can be done and the only solution is to save all, close flexprop and reopen it again.
bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs
bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs
while executing
"$w tag ranges hilite"
(procedure "searchrep'next" line 3)
invoked from within
"searchrep'next .p.nb"
invoked from within
".sr.bn invoke "
invoked from within
".sr.bn instate !disabled { .sr.bn invoke } "
invoked from within
".sr.bn instate pressed { .sr.bn state !pressed; .sr.bn instate !disabled { .sr.bn invoke } } "
(command bound to event)
can't read "filetimes(D:/Programowanie/P2-Retromachine-Basic/basic025.bas)": no such element in array
can't read "filetimes(D:/Programowanie/P2-Retromachine-Basic/basic025.bas)": no such element in array
while executing
"if {$disktime > $filetimes($s)} {
set needRead "yes"
}"
(procedure "checkFilesForChanges" line 15)
invoked from within
"checkFilesForChanges"
(procedure "checkFocusIn" line 6)
invoked from within
"checkFocusIn . "
(command bound to event)
The error window can not be closed (it reopens immediately) and Flexprop has to be killed from a task manager
@pik33 : Your "no such element in array" error appears to be difficult to reproduce. Do you remember what you were doing when it happened? Has it happened again?
No, it happened once. I can not remember exactly what I did, but there were 024 and 025 opened in 2 tabs of flexprop and I think I used winmerge to compare these versions and try to save while winmerge was still opened. I may also do something witth github desktop at the same time.
Alsso I found a workaround for a search window error. Close it, switch to another tab, return, reopen, and in 99% cases it works again. This search window error is not critical, but I got this everyday, several times a day, and it seems it is related to working simultaneously on several tabs at once.
I've released FlexProp 6.4.0 on github. The major changes to the compiler are:
- Added getcrc() builtin for Spin2
- Added VFS layer for Parallax flash file system
- Added recognition for "$" and "%" to __builtin_atoi
- Changed littlefs to not return . and .. entries in path search (so it matches host fs and FATFS)
- Fixed compilation error for object arrays in bytecode
- Fixed some quirks in the space/tab warning code
- Fixed incorrect expansion of field[ptr][n]~~
- Fixed an incompatibility between _tx and debug()
- Fixed timeout in _rxraw() (test was wrong way around)
- Improved range of sin and cos functions
- Improved performance of flash access in littlefs (thanks, Evan!)
- Updated -gbrk code to most recent from Chip, and add support for brk #0 interactive debug (thanks, Ada!)
There is also a small tweak to the GUI code which I hope will make search & replace more reliable.
It looks like the VFS layer for Parallax flash file system does not fully work.
If I try to open more than one file, strange things happen. You can see the effect in the shell example, if you try to copy a file inside the /pfs file system.
This will open one file for read and one for write.
Also if you open only 1 file for read, the first 2 characters of the file seem to not be read correct.
At the end I need to open 4 files, 2 for read and 2 for write. Will this be supported by the VFS layer, if I increase the MAX_FILES_OPEN to 4 files in the 'FlashFileSystem_16MB_eh.spin2' file?
@pik33 said:
Instead of crashing, the find window simply doesn't pop up at all sometimes. The workaround is as before: change the active tab and return.
I've updated src/gui.tcl in the flexprop repository to try to make this harder to happen.
It looks like the VFS layer for Parallax flash file system does not fully work.
If I try to open more than one file, strange things happen. You can see the effect in the shell example, if you try to copy a file inside the /pfs file system.
This will open one file for read and one for write.
Also if you open only 1 file for read, the first 2 characters of the file seem to not be read correct.
At the end I need to open 4 files, 2 for read and 2 for write. Will this be supported by the VFS layer, if I increase the MAX_FILES_OPEN to 4 files in the 'FlashFileSystem_16MB_eh.spin2' file?
Andy
Aargh, yes, the VFS layer is unaware of the file system limitation. I'll try to hook some error checking up. I think increasing MAX_FILES_OPEN should do what you need, but I'm not sure of that.
Sorry for the stupid questions. It's been a long time since I've tried to use the P2 tools and I seem to have forgotten how to build and load programs. So far I've compiled cdemo.c from the samples folder of the flex prop project using this command:
flexcc -2 cdemo.c
That produced cdemo.binary which I tried to load with proploader but that gave me an error saying it wasn't a propeller binary. Should I be using loadp2?
Comments
A PSRAM block device to interact with littlefs should be straightforward to implement. Littlefs already supports RAM disks from HUB and from HyperFlash. Unfortunately I haven't been able to find any simple working PSRAM demo code, or at least none that I've been able to get working
. I'm sure that's my fault, I haven't had time to really dig into it. The ramdisk code I did manage to get working (HyperFlash and RAM) is in examples/shell/shell.c (for the /ram file system).
It should be possible to use PSRAM for a RAM disk if you have HyperRAM going as they use the same fundamental interface in my drivers. I think you may just require the later memory driver that supports it. I took a look at your SPIN include folder in spin2cpp that contains some of this and the file you called HyperMemory.spin2 seems to be based on my original 0.8b HyperRAM memory driver file I put together before PSRAM was supported. There is a simpler PSRAM interface these days for video use but IIRC there should also be support for PSRAM in the updated memory.spin2 file in the later 0.9b release (at top post of Memory driver thread) that works similar to HyperRAM, and you might like to look at that sometime. Wuerfel_21 is correct in mentioning that input delays need tuning for different HW boards although I think the default timing profile should work with the P2-Edge PSRAM (at room temps anyway) .
Unfortunately I don't have a P2 Edge with PSRAM yet (I have ordered one). I do have some of @Rayman 's nice PSRAM boards, but the drivers for those don't seem to be in the memory thread (or I couldn't find them). I grabbed some drivers from MegaYume, but they don't work for me. Again, almost certainly something I've done wrong, I haven't had time to really dig into it, I was just hoping that the code would plug and play.
The actual drivers in there should work, but you need to tune the parameters if you're using a different clkfreq than megayume does.
Yes fair enough, maybe best to wait for a PSRAM P2 Edge to arrive for a more consistent HW setup to base it off, and one that plenty of others will have too. There were some patched/test drivers for those larger boards buried somewhere in the memory thread (or perhaps in one of Rayman's or Wuerfel_21's threads), as they needed modifications to adjust for different bit widths and chip select options and reduced speeds to work right. I know I sent a bunch of patched drivers to Wuerfel_21 too while we were figuring some of it out and parts of that probably made its way into her NeoYume codebase. Would need some digging to find it all, so perhaps focus on the P2 Edge for now once you get the shipment. Other boards support can then follow once the core is working.
A single PSRAM chip is easy to attach to an Eval. 8MB, 4 bit and still a lot of possibilities.
@ersmith I'm not seeing an "Identify" feature in the FlexProp menu. I find this very useful in Prop Tool to make first contact with a new board...
Is this hard to add?
Another question, just in case this is just a really old version of FlexProp....
How hard is it to have FlexProp GUI, on startup, check the web for what the latest release is and give a notice if current version is not the latest?
And, maybe making this a feature that can be disabled?
What exactly should "Identify" do?
I guess ideally, the same as Prop Tool. It basically just resets the Prop and probes it with serial to see what kind it is and if it able to reply.
I kind of use it as a basic functionality check...
It also reports back on what serial port it is connected. I think.
Pretend I've never seen Prop Tool (which isn't far off the mark). So what should the Identify menu item do? Does it probe just one serial port and report on the device, if any, found on that port? Does it probe all ports and report on the first device found on any port? Does it probe all ports and report on all devices found on all ports? What does it report -- just P1 or P2, or is there additional information it should show?
It scans all ports. I never connected more than 1 Propeller at once so I don't know what it does in this case. Then it displays a message
or, if failed
FlexProp 6.3.0 has been released on my GitHub page and on Patreon. Besides the usual bug fixes, this version has several new features:
#pragma exportdefallows#definestatements in one source file to be exported to others; this is useful for specifying driver names and other stringsTo try out the littlefs RAM disks, edit the file samples/shell/shell.c; near the top are a set of #if / #elif clauses for the various RAM disk types. The version checked in is for the 32 MB P2 Edge board, as that is probably the most common, but you can change this to suit your setup. At runtime,
mount /ramwill mount a ramdisk, which may usefully be used for temporary storage during transfers between flash and SD card (since these cannot both be mounted at the same time).No 96MB board support? ;3
I guess ramdisk is another use case for that much memory...
cool, thank you Eric
Great stuff. Glad to see you have some support for PSRAM in there now. I'll have to give it a try soon.
It's probably doable, as there is some support for the slower sysclk/3 and sysclk/4 clock rates it needed for its high fanout already in the 8 bit PSRAM driver. This 8 bit bus driver seems to be present, just needs its API to init it and setup the banks correctly. Was there a special custom version of it for 96MB clock/CE mapping? Given you wanted it for NeoYume you'll probably recall better than me the history of that variant...
As the number of board configurations have proliferated we probably need some more init API abstraction or additional parameters so this sort of board selection can be passed down from a higher level going forward. Or do we want the user to have to configure some of this themselves...? Tricky.
By the way, any transfer between HUB and external RAMs spanning different memory device banks will not currently be broken up automatically by the low level APIs. For a sector based access system that is already aligned on 2^n boundaries (such as a RAM disk should be doing) this is not an issue, but for arbitrary transfers of any size at any address it may become so. It probably needs some address+length testing to check that the address range does not cross a device boundary and then split the transfer into two or more transfers accordingly. This also happens internally for the 16MB HyperRAMs (which are internally just two 8MB dies coupled together). Until now with effectively single RAM bank devices like the P2-EC32MB and the HyperRAM module, it hasn't really been an issue, but could become so once people start to use this external memory randomly/arbitrarily like regular RAMs and have lots of devices on board. In my full blown memory driver which was originally intended for multiple banks and multiple memory types I was planning to add this check to the topmost API so it could split the transfer requests across different drivers and make it look like a single address space, but haven't yet looked at it within a given wrapper driver like we have for PSRAM. Something more to do when I get back onto it....
Thanks for providing the drivers! I'm not sure if I have the latest versions of everything, if I don't then please let me know.
That's kind of what the
#pragma exportdefwas designed for. As you'll see when you look at shell.c, I used that to select the PSRAM driver, and constant overrides to select parameters like pins.I think it only uses the first it finds. Which is pretty useless for me since I generally always have multiple Props attached. What order the scan is I don't know.
PS: I always use the
by-idpath spec. No order confusion this way.You have to use search very carefully, or this happens:
bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs while executing "$t tag config hilite -background yellow" invoked from within "if ![winfo exists $w] { toplevel $w wm title $w "Search" grid [label $w.1 -text Find:] [entry $w.f -textvar Find] [ttk::button $..." (procedure "searchrep" line 5) invoked from within "searchrep [focus] 0" (menu invoke)Edit: yet another, slightly different. And if this occurs, no more searching can be done and the only solution is to save all, close flexprop and reopen it again.
bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs bad command "tag": must be add, configure, cget, forget, hide, identify, index, insert, instate, select, state, tab, or tabs while executing "$w tag ranges hilite" (procedure "searchrep'next" line 3) invoked from within "searchrep'next .p.nb" invoked from within ".sr.bn invoke " invoked from within ".sr.bn instate !disabled { .sr.bn invoke } " invoked from within ".sr.bn instate pressed { .sr.bn state !pressed; .sr.bn instate !disabled { .sr.bn invoke } } " (command bound to event)Something new while saving a file:
can't read "filetimes(D:/Programowanie/P2-Retromachine-Basic/basic025.bas)": no such element in array can't read "filetimes(D:/Programowanie/P2-Retromachine-Basic/basic025.bas)": no such element in array while executing "if {$disktime > $filetimes($s)} { set needRead "yes" }" (procedure "checkFilesForChanges" line 15) invoked from within "checkFilesForChanges" (procedure "checkFocusIn" line 6) invoked from within "checkFocusIn . " (command bound to event)The error window can not be closed (it reopens immediately) and Flexprop has to be killed from a task manager
@pik33 : Your "no such element in array" error appears to be difficult to reproduce. Do you remember what you were doing when it happened? Has it happened again?
No, it happened once. I can not remember exactly what I did, but there were 024 and 025 opened in 2 tabs of flexprop and I think I used winmerge to compare these versions and try to save while winmerge was still opened. I may also do something witth github desktop at the same time.
Alsso I found a workaround for a search window error. Close it, switch to another tab, return, reopen, and in 99% cases it works again. This search window error is not critical, but I got this everyday, several times a day, and it seems it is related to working simultaneously on several tabs at once.
I've released FlexProp 6.4.0 on github. The major changes to the compiler are:
There is also a small tweak to the GUI code which I hope will make search & replace more reliable.
Instead of crashing, the find window simply doesn't pop up at all sometimes. The workaround is as before: change the active tab and return.
Thanks Eric
It looks like the VFS layer for Parallax flash file system does not fully work.
If I try to open more than one file, strange things happen. You can see the effect in the shell example, if you try to copy a file inside the /pfs file system.
This will open one file for read and one for write.
Also if you open only 1 file for read, the first 2 characters of the file seem to not be read correct.
At the end I need to open 4 files, 2 for read and 2 for write. Will this be supported by the VFS layer, if I increase the
MAX_FILES_OPENto 4 files in the 'FlashFileSystem_16MB_eh.spin2' file?Andy
I've updated src/gui.tcl in the flexprop repository to try to make this harder to happen.
Aargh, yes, the VFS layer is unaware of the file system limitation. I'll try to hook some error checking up. I think increasing MAX_FILES_OPEN should do what you need, but I'm not sure of that.
Sorry for the stupid questions. It's been a long time since I've tried to use the P2 tools and I seem to have forgotten how to build and load programs. So far I've compiled cdemo.c from the samples folder of the flex prop project using this command:
flexcc -2 cdemo.cThat produced cdemo.binary which I tried to load with proploader but that gave me an error saying it wasn't a propeller binary. Should I be using loadp2?
I'm getting closer. This command seems to be finding the P2 but having trouble loading.
Is there another option I need to pass to loadp2? I'm using a P2-EC32MB board.