Replies: 9 comments
-
|
On Tue, Jul 2, 2024 at 10:28 AM mcctuxic ***@***.***> wrote:
Hi,
guess what? Today I received the Pi Pico (not the original one...) I
odered, which has some goodies: 16MB flash and a NeoPixel (and a modern USB
C socket).
Do I need to change anything, so that Zeptoforth can access the complete
flash?
Zeptoforth ROCKS! :)
Cheers!
Tuxic
zeptoforth rp2040 builds are limited to 960 KB of flash dictionary space
and 1 MB of blocks space, and rp2040_big builds are limited to 1472 KB of
flash dictionary space and 512 KB of blocks space. Getting zeptoforth to
access more flash dictionary space than this requires modifying zeptoforth
and its build scripts and rebuilding it and is not trivial.
This is because of something called the "mini-dictionary", which is a flash
dictionary index in the form of a hash table which is stored in RAM during
operation and which is stored in a particular location of flash so as to be
ready at bootup. It also is because there is a magic value in flash which
indicates the size of the most recent image to be written to flash, so as
to clear out the remainder of the flash dictionary after it. Both of these
would have to be moved, which requires a number of code changes in both
zeptoforth and its build scripts.
Additionally, if you expand the amount of flash dictionary space used you
are still limited by the number of entries in the mini-dictionary, which
makes it not very useful unless you expand the mini-dictionary as well, and
that takes space away from applications in RAM. Note that the
mini-dictionary is necessary because otherwise compilation gets dog-slow
because of the number of flash XIP cache misses as zeptoforth traverses the
flash dictionary linked list.
Simply expanding the size of the blocks space, however, is more trivial;
while it still requires modifying zeptoforth and rebuilding it, it is less
complicated to carry out as it is merely modifying a few constants (I
*think* QUADSPI_Size, which is the total size of the QSPI flash chip, in
src/rp2040/forth/qspi.fs and src/rp2040_big/forth/qspi.fs is all you need
to change, but I'd have to confirm that).
Travis
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Travi,
...do you sleep...at some point in time...? :)
I am not really sure right now, whether these clones I received
today are working at all...will see.
Should a unaltered zeptoforth run on a Pico Pi with 16MB?
And: Adding more sprace for blocks would be totally sufficient! :)
Chees!
Tuxic
…On 07/02 08:53, tabemann wrote:
On Tue, Jul 2, 2024 at 10:28 AM mcctuxic ***@***.***> wrote:
> Hi,
>
> guess what? Today I received the Pi Pico (not the original one...) I
> odered, which has some goodies: 16MB flash and a NeoPixel (and a modern USB
> C socket).
>
> Do I need to change anything, so that Zeptoforth can access the complete
> flash?
>
> Zeptoforth ROCKS! :)
>
> Cheers!
> Tuxic
>
zeptoforth rp2040 builds are limited to 960 KB of flash dictionary space
and 1 MB of blocks space, and rp2040_big builds are limited to 1472 KB of
flash dictionary space and 512 KB of blocks space. Getting zeptoforth to
access more flash dictionary space than this requires modifying zeptoforth
and its build scripts and rebuilding it and is not trivial.
This is because of something called the "mini-dictionary", which is a flash
dictionary index in the form of a hash table which is stored in RAM during
operation and which is stored in a particular location of flash so as to be
ready at bootup. It also is because there is a magic value in flash which
indicates the size of the most recent image to be written to flash, so as
to clear out the remainder of the flash dictionary after it. Both of these
would have to be moved, which requires a number of code changes in both
zeptoforth and its build scripts.
Additionally, if you expand the amount of flash dictionary space used you
are still limited by the number of entries in the mini-dictionary, which
makes it not very useful unless you expand the mini-dictionary as well, and
that takes space away from applications in RAM. Note that the
mini-dictionary is necessary because otherwise compilation gets dog-slow
because of the number of flash XIP cache misses as zeptoforth traverses the
flash dictionary linked list.
Simply expanding the size of the blocks space, however, is more trivial;
while it still requires modifying zeptoforth and rebuilding it, it is less
complicated to carry out as it is merely modifying a few constants (I
*think* QUADSPI_Size, which is the total size of the QSPI flash chip, in
src/rp2040/forth/qspi.fs and src/rp2040_big/forth/qspi.fs is all you need
to change, but I'd have to confirm that).
Travis
--
Reply to this email directly or view it on GitHub:
#110 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On Tue, Jul 2, 2024 at 11:40 AM mcctuxic ***@***.***> wrote:
Hi Travi,
...do you sleep...at some point in time...? :)
I do sleep, just at a different time than you. :)
I am not really sure right now, whether these clones I received
today are working at all...will see.
Should a unaltered zeptoforth run on a Pico Pi with 16MB?
An unaltered zeptoforth will run on an RP2040 board with 16 MB of flash
just fine, but you won't be able to use any flash beyond 2 MB. The only
catch is that the LED module probably won't work, because it is specific to
the original Pico (i.e. GPIO pin 25 is set to output and the LED is on when
high and off when low), even though there is hacked-on optional support for
the XIAO RP2040 and the Wio RP2040.
And: Adding more sprace for blocks would be totally sufficient! :)
One thing I have considered adding is block device support to replace the
SD card block device (the existing code is designed to be rather
interchangeable, as there is a <block-dev> superclass that could be
subclassed) so as to be able to use block storage for FAT32 filesystems.
The only issue with that is that code for formatting devices with MBR's and
FAT32 filesystems would have to be added, because currently zeptoforth does
not have builtin support for formatting devices.
Chees!
Tuxic
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9939161@
github.com>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Travis,
sorry for mispelling your name...I am the one who needs sleep
and possibly more of it as it seems... :)
FAT on flash: The region of the flash, where the FAT is located
gets much more written than the rest...and flash does not like
that so much. ;)
From a video of Ralph Bacon I know of "Little FS"
(https://piped.adminforge.de/watch?v=4r6YZlLfKfw), which -
if I can remember correctly - is especially designed for
flash in SoCs and µControllers.
May be this is more easier to implement as code already
exists? (I didn't code anything related to that...I only
watched the video).
Using zed directly on the flash would be ***###NICE###*** ! 8)
Cheers!
Tuxic
…On 07/02 10:33, tabemann wrote:
On Tue, Jul 2, 2024 at 11:40 AM mcctuxic ***@***.***> wrote:
> Hi Travi,
>
> ...do you sleep...at some point in time...? :)
>
I do sleep, just at a different time than you. :)
> I am not really sure right now, whether these clones I received
> today are working at all...will see.
>
> Should a unaltered zeptoforth run on a Pico Pi with 16MB?
>
An unaltered zeptoforth will run on an RP2040 board with 16 MB of flash
just fine, but you won't be able to use any flash beyond 2 MB. The only
catch is that the LED module probably won't work, because it is specific to
the original Pico (i.e. GPIO pin 25 is set to output and the LED is on when
high and off when low), even though there is hacked-on optional support for
the XIAO RP2040 and the Wio RP2040.
> And: Adding more sprace for blocks would be totally sufficient! :)
>
One thing I have considered adding is block device support to replace the
SD card block device (the existing code is designed to be rather
interchangeable, as there is a <block-dev> superclass that could be
subclassed) so as to be able to use block storage for FAT32 filesystems.
The only issue with that is that code for formatting devices with MBR's and
FAT32 filesystems would have to be added, because currently zeptoforth does
not have builtin support for formatting devices.
> Chees!
> Tuxic
>
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9939161@
> github.com>
>
--
Reply to this email directly or view it on GitHub:
#110 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On Tue, Jul 2, 2024 at 12:58 PM mcctuxic ***@***.***> wrote:
Hi Travis,
sorry for mispelling your name...I am the one who needs sleep
and possibly more of it as it seems... :)
Actually, I tend to be called by people I know personally as "Trav".
FAT on flash: The region of the flash, where the FAT is located
gets much more written than the rest...and flash does not like
that so much. ;)
Except... I implemented wear leveling into zeptoforth block's layer, which
solves this problem. An individual block changes position in flash each
time it is written.
From a video of Ralph Bacon I know of "Little FS"
(https://piped.adminforge.de/watch?v=4r6YZlLfKfw), which -
if I can remember correctly - is especially designed for
flash in SoCs and µControllers.
May be this is more easier to implement as code already
exists? (I didn't code anything related to that...I only
watched the video).
I should implement LittleFS sometime, even though it would probably
requiring reworking zeptoforth's FAT32 layer because it is not very
interchangeable with other filesystems. (zepto*script*'s FAT32 layer is
another story, because it is designed to be easily replaced with another
filesystem, taking advantage of zeptoscript's duck typing.)
Using zed directly on the flash would be ***###NICE###*** ! 8)
Oh, I would love to be able to do this.
Cheers!
Tuxic
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9939844@
github.com>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On 07/02 12:06, tabemann wrote:
On Tue, Jul 2, 2024 at 12:58 PM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> sorry for mispelling your name...I am the one who needs sleep
> and possibly more of it as it seems... :)
>
Actually, I tend to be called by people I know personally as "Trav".
:)
> FAT on flash: The region of the flash, where the FAT is located
> gets much more written than the rest...and flash does not like
> that so much. ;)
>
Except... I implemented wear leveling into zeptoforth block's layer, which
solves this problem. An individual block changes position in flash each
time it is written.
I am ... speechless ... WHOW! :)
> From a video of Ralph Bacon I know of "Little FS"
> (https://piped.adminforge.de/watch?v=4r6YZlLfKfw), which -
> if I can remember correctly - is especially designed for
> flash in SoCs and µControllers.
> May be this is more easier to implement as code already
> exists? (I didn't code anything related to that...I only
> watched the video).
>
I should implement LittleFS sometime, even though it would probably
requiring reworking zeptoforth's FAT32 layer because it is not very
interchangeable with other filesystems. (zepto*script*'s FAT32 layer is
another story, because it is designed to be easily replaced with another
filesystem, taking advantage of zeptoscript's duck typing.)
Since Zeptoforth is already wear leveling FAT32 is fine...and SDcards
written by Zeptoforth are readable nearly everywhere, which can not be
said about SDcards written with LittleFS. And FAT32 can be formatted
outside of the µC...so Zeptoforth don't need to have a formatted built
in...which makes its byte-footprint a little smaller.
The only downside I saw and no longer see is the wear and tear problem -
which doesn't exist anymore... :)
Looks great for me!
> Using zed directly on the flash would be ***###NICE###*** ! 8)
>
Oh, I would love to be able to do this.
:::)))
Cheers!
Tuxic
…
> Cheers!
> Tuxic
>
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9939844@
> github.com>
>
--
Reply to this email directly or view it on GitHub:
#110 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On Tue, Jul 2, 2024 at 9:42 PM mcctuxic ***@***.***> wrote:
> > FAT on flash: The region of the flash, where the FAT is located
> > gets much more written than the rest...and flash does not like
> > that so much. ;)
> >
>
> Except... I implemented wear leveling into zeptoforth block's layer,
which
> solves this problem. An individual block changes position in flash each
> time it is written.
I am ... speechless ... WHOW! :)
Actually, it is a side effect of the fact that a standard Forth block is
1024 bytes, which is smaller than the size that, say, the 25Q flash used
with the RP2040 can erase at any one time, so a means was needed to avoid
having to erase larger chunks of flash each time a single standard Forth
block is written.
> > From a video of Ralph Bacon I know of "Little FS"
> > (https://piped.adminforge.de/watch?v=4r6YZlLfKfw), which -
> > if I can remember correctly - is especially designed for
> > flash in SoCs and µControllers.
> > May be this is more easier to implement as code already
> > exists? (I didn't code anything related to that...I only
> > watched the video).
> >
>
> I should implement LittleFS sometime, even though it would probably
> requiring reworking zeptoforth's FAT32 layer because it is not very
> interchangeable with other filesystems. (zepto*script*'s FAT32 layer is
> another story, because it is designed to be easily replaced with another
> filesystem, taking advantage of zeptoscript's duck typing.)
>
Since Zeptoforth is already wear leveling FAT32 is fine...and SDcards
written by Zeptoforth are readable nearly everywhere, which can not be
said about SDcards written with LittleFS. And FAT32 can be formatted
outside of the µC...so Zeptoforth don't need to have a formatted built
in...which makes its byte-footprint a little smaller.
Note that the wear leveling is part of the zeptoforth in-flash blocks
layer, not part of the SDHC card layer; if there is wear leveling there it
would be part of the SDHC card itself, not part of zeptoforth.
The only downside I saw and no longer see is the wear and tear problem -
which doesn't exist anymore... :)
Looks great for me!
> > Using zed directly on the flash would be ***###NICE###*** ! 8)
> >
>
> Oh, I would love to be able to do this.
:::)))
Cheers!
Tuxic
Tonight I have been working on a layer that allows using FAT32 on top of
the zeptoforth blocks system (each 1024-byte Forth block is split into two
512 FAT32 sectors) along with a utility to initialize FAT32 filesystems
(and the requisite MBR's), which is necessary to be able to use FAT32 with
zeptoforth blocks (and to be able to initialize SDHC cards with FAT32
filesystems without making use of an external system).
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9942963@
github.com>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Travis,
On 07/02 09:54, tabemann wrote:
On Tue, Jul 2, 2024 at 9:42 PM mcctuxic ***@***.***> wrote:
> > > FAT on flash: The region of the flash, where the FAT is located
> > > gets much more written than the rest...and flash does not like
> > > that so much. ;)
> > >
> >
> > Except... I implemented wear leveling into zeptoforth block's layer,
> which
> > solves this problem. An individual block changes position in flash each
> > time it is written.
>
> I am ... speechless ... WHOW! :)
>
Actually, it is a side effect of the fact that a standard Forth block is
1024 bytes, which is smaller than the size that, say, the 25Q flash used
with the RP2040 can erase at any one time, so a means was needed to avoid
having to erase larger chunks of flash each time a single standard Forth
block is written.
I am still ... speechless ... :)
> > > From a video of Ralph Bacon I know of "Little FS"
> > > (https://piped.adminforge.de/watch?v=4r6YZlLfKfw), which -
> > > if I can remember correctly - is especially designed for
> > > flash in SoCs and µControllers.
> > > May be this is more easier to implement as code already
> > > exists? (I didn't code anything related to that...I only
> > > watched the video).
> > >
> >
> > I should implement LittleFS sometime, even though it would probably
> > requiring reworking zeptoforth's FAT32 layer because it is not very
> > interchangeable with other filesystems. (zepto*script*'s FAT32 layer is
> > another story, because it is designed to be easily replaced with another
> > filesystem, taking advantage of zeptoscript's duck typing.)
> >
>
> Since Zeptoforth is already wear leveling FAT32 is fine...and SDcards
> written by Zeptoforth are readable nearly everywhere, which can not be
> said about SDcards written with LittleFS. And FAT32 can be formatted
> outside of the µC...so Zeptoforth don't need to have a formatted built
> in...which makes its byte-footprint a little smaller.
>
Note that the wear leveling is part of the zeptoforth in-flash blocks
layer, not part of the SDHC card layer; if there is wear leveling there it
would be part of the SDHC card itself, not part of zeptoforth.
Ah...sorry...I wrote in "fuzzy mode" accidentally ... With "FAT32" I meant with "FAT32
when used in combination with FLASH".
Background was the idea to replace FAT32 with LittleFS on flash as on
SDcards...
> The only downside I saw and no longer see is the wear and tear problem -
> which doesn't exist anymore... :)
>
> Looks great for me!
>
> > > Using zed directly on the flash would be ***###NICE###*** ! 8)
> > >
> >
> > Oh, I would love to be able to do this.
>
> :::)))
>
> Cheers!
> Tuxic
Tonight I have been working on a layer that allows using FAT32 on top of
TONIGHT??? Man...sleep() is not only a system call. Your personal system
needs sleep as well and far more than a few ms... :)
the zeptoforth blocks system (each 1024-byte Forth block is split into two
512 FAT32 sectors) along with a utility to initialize FAT32 filesystems
(and the requisite MBR's), which is necessary to be able to use FAT32 with
zeptoforth blocks (and to be able to initialize SDHC cards with FAT32
filesystems without making use of an external system).
...from the golden age of home computers I remember, that Claus Brod
wrote a book called "Scheibenkleister" - unfortunately complete in german
and I can't find any legal pdf copy of it.
He had built a "fast formatting" tool ("fast" in the context of a
8Mhz clocked 68000...), which only put kind of marks on the floppy. The
"real" formatting was done while actually writing files to the disk.
I don't know, whether this may be applicable to flash based FAT32s...but
I hope this may reduce the implementation effort on your side a little...
One question of a totally different topic (still a Zeptoforthian topic,
of course ! :) )
You implemented the Wifi related handling in Zeptoforth...but the
firmware are two opaque (and proprietary...I think) binary blobs.
Is there any API documentation available (where?) ?
Cheers!
Tuxic
… Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9942963@
> github.com>
--
Reply to this email directly or view it on GitHub:
#110 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On Wed, Jul 3, 2024 at 10:26 AM mcctuxic ***@***.***> wrote:
Hi Travis,
On 07/02 09:54, tabemann wrote:
> On Tue, Jul 2, 2024 at 9:42 PM mcctuxic ***@***.***> wrote:
>
> > > > FAT on flash: The region of the flash, where the FAT is located
> > > > gets much more written than the rest...and flash does not like
> > > > that so much. ;)
> > > >
> > >
> > > Except... I implemented wear leveling into zeptoforth block's layer,
> > which
> > > solves this problem. An individual block changes position in flash
each
> > > time it is written.
> >
> > I am ... speechless ... WHOW! :)
> >
>
> Actually, it is a side effect of the fact that a standard Forth block is
> 1024 bytes, which is smaller than the size that, say, the 25Q flash used
> with the RP2040 can erase at any one time, so a means was needed to avoid
> having to erase larger chunks of flash each time a single standard Forth
> block is written.
I am still ... speechless ... :)
Now the question is if I ever go back to that code -- which I wrote before
I added local variables to zeptoforth -- will I ever understand it? lol.
>
> > > > From a video of Ralph Bacon I know of "Little FS"
> > > > (https://piped.adminforge.de/watch?v=4r6YZlLfKfw), which -
> > > > if I can remember correctly - is especially designed for
> > > > flash in SoCs and µControllers.
> > > > May be this is more easier to implement as code already
> > > > exists? (I didn't code anything related to that...I only
> > > > watched the video).
> > > >
> > >
> > > I should implement LittleFS sometime, even though it would probably
> > > requiring reworking zeptoforth's FAT32 layer because it is not very
> > > interchangeable with other filesystems. (zepto*script*'s FAT32 layer
is
> > > another story, because it is designed to be easily replaced with
another
> > > filesystem, taking advantage of zeptoscript's duck typing.)
> > >
> >
> > Since Zeptoforth is already wear leveling FAT32 is fine...and SDcards
> > written by Zeptoforth are readable nearly everywhere, which can not be
> > said about SDcards written with LittleFS. And FAT32 can be formatted
> > outside of the µC...so Zeptoforth don't need to have a formatted built
> > in...which makes its byte-footprint a little smaller.
> >
>
> Note that the wear leveling is part of the zeptoforth in-flash blocks
> layer, not part of the SDHC card layer; if there is wear leveling there
it
> would be part of the SDHC card itself, not part of zeptoforth.
Ah...sorry...I wrote in "fuzzy mode" accidentally ... With "FAT32" I meant
with "FAT32
when used in combination with FLASH".
Background was the idea to replace FAT32 with LittleFS on flash as on
SDcards...
I am sticking with FAT32 for flash, with all its faults, because it will
enable code written to use FAT32 for SD cards to be easily converted to
code to use FAT32 for flash (I already have the code for swapping one out
for the other implemented, but I have not fully tested it as of yet as I am
still wrangling with issues with my FAT32 formatting tool).
>
> > The only downside I saw and no longer see is the wear and tear problem
-
> > which doesn't exist anymore... :)
> >
> > Looks great for me!
> >
> > > > Using zed directly on the flash would be ***###NICE###*** ! 8)
> > > >
> > >
> > > Oh, I would love to be able to do this.
> >
> > :::)))
> >
> > Cheers!
> > Tuxic
>
>
> Tonight I have been working on a layer that allows using FAT32 on top of
TONIGHT??? Man...sleep() is not only a system call. Your personal system
needs sleep as well and far more than a few ms... :)
Well, I normally hit the sack around 23:00-23:30 and get up around 7:30 on
weekdays (I often get to bed later and get up later on weekends), so I do
sleep, just not when you do. :)
> the zeptoforth blocks system (each 1024-byte Forth block is split into
two
> 512 FAT32 sectors) along with a utility to initialize FAT32 filesystems
> (and the requisite MBR's), which is necessary to be able to use FAT32
with
> zeptoforth blocks (and to be able to initialize SDHC cards with FAT32
> filesystems without making use of an external system).
...from the golden age of home computers I remember, that Claus Brod
wrote a book called "Scheibenkleister" - unfortunately complete in german
and I can't find any legal pdf copy of it.
He had built a "fast formatting" tool ("fast" in the context of a
8Mhz clocked 68000...), which only put kind of marks on the floppy. The
"real" formatting was done while actually writing files to the disk.
I don't know, whether this may be applicable to flash based FAT32s...but
I hope this may reduce the implementation effort on your side a little...
Note that my FAT32 "formatting" is not like the formatting of a traditional
magnetic disk. All it does is write out the necessary blocks for the MBR,
the VBR, the info sector, the FAT's, and the first sector of the root
sector to the media, be it flash or an SDHC card.
One question of a totally different topic (still a Zeptoforthian topic,
of course ! :) )
You implemented the Wifi related handling in Zeptoforth...but the
firmware are two opaque (and proprietary...I think) binary blobs.
Is there any API documentation available (where?) ?
Cheers!
Tuxic
I don't have any API documentation for the firmware binary blobs -- my
CYW43439 driver itself was essentially taking a CYW43439 driver written in
Rust by someone else and converting it all but verbatim to Forth.
As for the documentation for zeptoIP and the CYW43439 driver's API, look in
https://github.com/tabemann/zeptoforth/blob/master/docs/extra/net.md and
https://github.com/tabemann/zeptoforth/blob/master/docs/extra/cyw43.md.
Also, there is a useful guide to using WiFi with zeptoIP at
https://github.com/tabemann/zeptoforth/blob/master/BUILDING_AND_USING_ZEPTOIP.md
.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/110/comments/9949797@
github.com>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
guess what? Today I received the Pi Pico (not the original one...) I odered, which has some goodies: 16MB flash and a NeoPixel (and a modern USB C socket).
Do I need to change anything, so that Zeptoforth can access the complete flash?
Zeptoforth ROCKS! :)
Cheers!
Tuxic
Beta Was this translation helpful? Give feedback.
All reactions