Replies: 15 comments
-
On Thu, Jul 4, 2024, 10:32 mcctuxic ***@***.***> wrote:
Hi Travis,
...I am speechless... (Did I mentioned this before...? ;) )
You are using a time-machine...aren't you?
LOL :)
Just got the info that you have published an new release with FAT32 support
for the internal flash memory.
The idea of a self-starting formatting tool is the most convenient
solution I can think of...I have
already formatted the flash of my pico pi (I need to backup what is on
flash of my pi pico w).
My board is now in the state of having a FAT32 formatted flash and Zed in
RAM.
What is the correct doing to make the FAT32 flash "visible" to Zed?
If you used the recommended setup program it will be visible to zeptoed on
bootup.
If you manually set up a <simple-blocks-fat32-fs> object, then pass it to
fat32-tools::current-fs! so zeptoed can use it.
and:
Will "compile-to-flash" work as before?
Yes it will because it acts on a different region of flash from FAT32
filesystems.
A big THANK YOU for implementing FAT32 for the internal flash! GREAT! :)
Cheers!
Tuxic
You're welcome!
Travis
… |
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
(: * M * A * G * I * C * :)
May be I am thinking too complicate right now and mapping
SDcard related things to the handling of the internal flash...
Is there a way to list files, move files, rename files and delete files?
Is there a way to upload files directly from PC into
the internal FLASH32 ;) ?
(I used the zeptoforth-file, uploaded it and the Pi Pico reboots and
then there were light...hrrrrmmm....FAT32)
Cheers!
Tuxic
…On 07/04 09:46, tabemann wrote:
On Thu, Jul 4, 2024, 10:32 mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> ...I am speechless... (Did I mentioned this before...? ;) )
> You are using a time-machine...aren't you?
>
LOL :)
Just got the info that you have published an new release with FAT32 support
> for the internal flash memory.
>
> The idea of a self-starting formatting tool is the most convenient
> solution I can think of...I have
> already formatted the flash of my pico pi (I need to backup what is on
> flash of my pi pico w).
>
> My board is now in the state of having a FAT32 formatted flash and Zed in
> RAM.
> What is the correct doing to make the FAT32 flash "visible" to Zed?
>
If you used the recommended setup program it will be visible to zeptoed on
bootup.
If you manually set up a <simple-blocks-fat32-fs> object, then pass it to
fat32-tools::current-fs! so zeptoed can use it.
and:
>
> Will "compile-to-flash" work as before?
>
>
Yes it will because it acts on a different region of flash from FAT32
filesystems.
A big THANK YOU for implementing FAT32 for the internal flash! GREAT! :)
>
> Cheers!
> Tuxic
>
You're welcome!
Travis
>
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Thu, Jul 4, 2024, 11:59 mcctuxic ***@***.***> wrote:
Hi Travis,
(: * M * A * G * I * C * :)
:D
May be I am thinking too complicate right now and mapping
SDcard related things to the handling of the internal flash...
Is there a way to list files, move files, rename files and delete files?
Once a current filesystem is set you can execute:
fat32-tools import
and then things like:
s" /FOO.FS" included \ These can be nested.
s" /" list-dir
s" /TEST" create-dir
s" This is a test!" s" /TEST.TXT" create-file
s" This is only a test!" s" /TEST.TXT" write-file \ The file must already
exist.
s" /TEST.TXT" dump-file
s" /FOO.TXT" s" BAR.TXT" rename \ Note that this cannot move a file between
parent directories; the second argument is a name not a path.
s" /TEST/FOOBAR.TXT" s" /QUUX.TXT" copy-file
s" /OLD/FILE.TXT" remove-file
s" /OLD" remove-dir \ The directory must be empty except for . and ..
entries.
Is there a way to upload files directly from PC into
the internal FLASH32 ;) ?
Currently there isn't a convenient way of doing this, unfortunately, but I
should add one. In the long run I plan on adding USB mass storage device
class support.
(I used the zeptoforth-file, uploaded it and the Pi Pico reboots and
then there were light...hrrrrmmm....FAT32)
Cheers!
Tuxic
:)
Travis
… |
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
what follows was only a very rough and test on the surface...
Unfortunately I have to stop zeptoforthing for today ... I need
to get up early tommorow morning and go to work then.
But the weekend WILL COME! More zeptoforthing ahead! :)
It seems that certain control sequences like CTRL-A/E or CTRL-U
doesn't work anymore. I uploaded zed into the RAM...
This happens when editing files on the SDcard as well with
files of the internal FAT32 fs.
and:
If the SDcard is "mounted" as described in the docs, all
file system related commands will access the SDcard.
I think 'current-fs' must be switched back and FORTH,
but I don't know what I should pass to current-fs in case
of the internal FAT32 fs...?
Cheers!
Tuxic
…On 07/04 10:37, tabemann wrote:
On Thu, Jul 4, 2024, 11:59 mcctuxic ***@***.***> wrote:
>
> Hi Travis,
>
> (: * M * A * G * I * C * :)
>
:D
May be I am thinking too complicate right now and mapping
> SDcard related things to the handling of the internal flash...
>
> Is there a way to list files, move files, rename files and delete files?
>
Once a current filesystem is set you can execute:
fat32-tools import
and then things like:
s" /FOO.FS" included \ These can be nested.
s" /" list-dir
s" /TEST" create-dir
s" This is a test!" s" /TEST.TXT" create-file
s" This is only a test!" s" /TEST.TXT" write-file \ The file must already
exist.
s" /TEST.TXT" dump-file
s" /FOO.TXT" s" BAR.TXT" rename \ Note that this cannot move a file between
parent directories; the second argument is a name not a path.
s" /TEST/FOOBAR.TXT" s" /QUUX.TXT" copy-file
s" /OLD/FILE.TXT" remove-file
s" /OLD" remove-dir \ The directory must be empty except for . and ..
entries.
Is there a way to upload files directly from PC into
> the internal FLASH32 ;) ?
>
Currently there isn't a convenient way of doing this, unfortunately, but I
should add one. In the long run I plan on adding USB mass storage device
class support.
(I used the zeptoforth-file, uploaded it and the Pi Pico reboots and
> then there were light...hrrrrmmm....FAT32)
>
> Cheers!
> Tuxic
>
:)
Travis
>
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Thu, Jul 4, 2024 at 12:58 PM mcctuxic ***@***.***> wrote:
Hi Travis,
what follows was only a very rough and test on the surface...
Unfortunately I have to stop zeptoforthing for today ... I need
to get up early tommorow morning and go to work then.
But the weekend WILL COME! More zeptoforthing ahead! :)
Just so you know, check out:
https://github.com/tabemann/zeptoforth/blob/master/README.md#transferring-data-to-and-from-filesystems-on-boards
Now there are tools for easily transferring files back and forth between
your computer and FAT32 filesystems on your Pico. These tools send data
over serial or USB CDC connections in chunks encoded in Base64, to avoid
issues with embedded control-C characters that would otherwise cause
undesired reboots, with CRC32 checksums (along with the validity of the
Base64 itself) being used to validate each block; if a chunk is bad they
will automatically resend it.
It seems that certain control sequences like CTRL-A/E or CTRL-U
doesn't work anymore. I uploaded zed into the RAM...
This happens when editing files on the SDcard as well with
files of the internal FAT32 fs.
This sounds to me like a terminal issue, to be honest, and I have not
touched anything in ages that should affect this.
and:
If the SDcard is "mounted" as described in the docs, all
file system related commands will access the SDcard.
I think 'current-fs' must be switched back and FORTH,
but I don't know what I should pass to current-fs in case
of the internal FAT32 fs...?
Execute:
setup-blocks-fat32::my-fs fat32-tools::current-fs!
This will restore the current filesystem to the internal FAT32 filesystem.
Cheers!
Tuxic
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9961430@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis
WHAT??? :)
...I think I should call the time police now! Here is someone,
who transfers technology from the future into the present, which
result in a time paradoxon...obviously.
I already saw the black cat twice in the stairwell...
(deja vu...you know... ;) )
Seriously, Travis...HOW on earth are you able to implement
such things in such a short time?
And - of course - I will try it out as soon as possible.
But first: I need something to eat (came back from work
just before).
THANKS A LOT! GREAT!
Will report back later :)
Cheers!
Tuxic
PS: Two of the cheap RP2040 boards I ordered do not work with Zeptoforth
(but the other two of the same kind do ... so this has nothing to do
with Zeptoforth). Is there a way to erase the flash completly to
containg really nothing? May be this would help...
…On 07/04 09:05, tabemann wrote:
On Thu, Jul 4, 2024 at 12:58 PM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> what follows was only a very rough and test on the surface...
> Unfortunately I have to stop zeptoforthing for today ... I need
> to get up early tommorow morning and go to work then.
> But the weekend WILL COME! More zeptoforthing ahead! :)
>
Just so you know, check out:
https://github.com/tabemann/zeptoforth/blob/master/README.md#transferring-data-to-and-from-filesystems-on-boards
Now there are tools for easily transferring files back and forth between
your computer and FAT32 filesystems on your Pico. These tools send data
over serial or USB CDC connections in chunks encoded in Base64, to avoid
issues with embedded control-C characters that would otherwise cause
undesired reboots, with CRC32 checksums (along with the validity of the
Base64 itself) being used to validate each block; if a chunk is bad they
will automatically resend it.
> It seems that certain control sequences like CTRL-A/E or CTRL-U
> doesn't work anymore. I uploaded zed into the RAM...
> This happens when editing files on the SDcard as well with
> files of the internal FAT32 fs.
>
This sounds to me like a terminal issue, to be honest, and I have not
touched anything in ages that should affect this.
> and:
>
> If the SDcard is "mounted" as described in the docs, all
> file system related commands will access the SDcard.
> I think 'current-fs' must be switched back and FORTH,
> but I don't know what I should pass to current-fs in case
> of the internal FAT32 fs...?
>
Execute:
setup-blocks-fat32::my-fs fat32-tools::current-fs!
This will restore the current filesystem to the internal FAT32 filesystem.
> Cheers!
> Tuxic
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9961430@
> github.com>
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
short info:
I found a uf2-file called 'flash_nuke.uf2", which erases all
flash.
It is available here:
https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html#resetting-flash-memory
Cheers!
Tuxic
…On 07/04 09:05, tabemann wrote:
On Thu, Jul 4, 2024 at 12:58 PM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> what follows was only a very rough and test on the surface...
> Unfortunately I have to stop zeptoforthing for today ... I need
> to get up early tommorow morning and go to work then.
> But the weekend WILL COME! More zeptoforthing ahead! :)
>
Just so you know, check out:
https://github.com/tabemann/zeptoforth/blob/master/README.md#transferring-data-to-and-from-filesystems-on-boards
Now there are tools for easily transferring files back and forth between
your computer and FAT32 filesystems on your Pico. These tools send data
over serial or USB CDC connections in chunks encoded in Base64, to avoid
issues with embedded control-C characters that would otherwise cause
undesired reboots, with CRC32 checksums (along with the validity of the
Base64 itself) being used to validate each block; if a chunk is bad they
will automatically resend it.
> It seems that certain control sequences like CTRL-A/E or CTRL-U
> doesn't work anymore. I uploaded zed into the RAM...
> This happens when editing files on the SDcard as well with
> files of the internal FAT32 fs.
>
This sounds to me like a terminal issue, to be honest, and I have not
touched anything in ages that should affect this.
> and:
>
> If the SDcard is "mounted" as described in the docs, all
> file system related commands will access the SDcard.
> I think 'current-fs' must be switched back and FORTH,
> but I don't know what I should pass to current-fs in case
> of the internal FAT32 fs...?
>
Execute:
setup-blocks-fat32::my-fs fat32-tools::current-fs!
This will restore the current filesystem to the internal FAT32 filesystem.
> Cheers!
> Tuxic
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9961430@
> github.com>
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Fri, Jul 5, 2024 at 10:07 AM mcctuxic ***@***.***> wrote:
Hi Travis
WHAT??? :)
...I think I should call the time police now! Here is someone,
who transfers technology from the future into the present, which
result in a time paradoxon...obviously.
I already saw the black cat twice in the stairwell...
(deja vu...you know... ;) )
:D
Seriously, Travis...HOW on earth are you able to implement
such things in such a short time?
I saw a need for it so I implemented it. Implementing CRC32 and Base64
turned out to be quite easy, for starters, and the protocol design was
pretty simple.
I was originally considering implementing ZMODEM, but from looking into it
that would have been far more complex (and overkill), and would run into
issues because it expects an 8-bit clean connection, and the zeptoforth
console is not 8-bit clean by default (because it traps control-C to
trigger a reboot and control-T to initiate "attention" sequences like
control-T z for sending the main task an interrupt exception). Note that
there is a way to make the zeptoforth console 8-bit clean, but that runs
into the opposite problem, where if you want to interrupt send_file.fs or
recv_file.fs the only way to do so would be to manually power-cycle your
Pico.
And - of course - I will try it out as soon as possible.
But first: I need something to eat (came back from work
just before).
THANKS A LOT! GREAT!
Will report back later :)
Cheers!
Tuxic
You're welcome!
PS: Two of the cheap RP2040 boards I ordered do not work with Zeptoforth
(but the other two of the same kind do ... so this has nothing to do
with Zeptoforth). Is there a way to erase the flash completly to
containg really nothing? May be this would help...
If you have a 2 MB RP2040 board such as a Pico you can erase its flash
completely by pressing BOOTSEL while applying power, mounting the Mass
Storage device that shows up, and copying the UF2 file you can download
from https://datasheets.raspberrypi.com/soft/flash_nuke.uf2 to it. This
will erase both zeptoforth dictionary storage and zeptoforth blocks
storage. However, this file will most likely not work with an RP2040 board
with greater than 2 MB flash (I have not tried this though; I do not have
such a board on hand).
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9969521@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
I tested to send a file via recv-file.fs and send-file.sh from my
Linux to a standard (original) Raspberry Pi Pico W, which was placed
on a Maker Pi Pico board.
The setup was as follows:
zed loaded into flash
FAT32 formatting of the flash via "send me a formatter".fs :)
reboot
SDcard with a FAT32 filesystem "mounted" via the code given in
'Getting started'
s" /" list-dir shows the directory of the SDcard
10 edit: I filled in some stuff like enable-line and the setup
of the SDcard in case I need to reboot, so I only need to do a
10 load
reboot
connect via picocom -b 115200 /dev/ttyACM0
10 load
everything seems fine - I could list the directory of the SDcard
then I proceeded with the steps decribed in the README file
to transfer files from the PC to the Pico.
I left picocom ctrl-a ctrl-q, which leave picocom without resetting
the tty.
I started send-file.sh from the commandline as described and transfered
README.md to the Pico.
Send-file.sh reports no errors.
I connected to the Pico via picocom as described above.
The README.md had overwritten block 10 instead of being
written to the SDcard.
(I have a backup of block 10 so no worries! 8) )
Cheers!
Tuxic
…On 07/05 10:49, tabemann wrote:
On Fri, Jul 5, 2024 at 10:07 AM mcctuxic ***@***.***> wrote:
> Hi Travis
>
> WHAT??? :)
>
> ...I think I should call the time police now! Here is someone,
> who transfers technology from the future into the present, which
> result in a time paradoxon...obviously.
> I already saw the black cat twice in the stairwell...
> (deja vu...you know... ;) )
>
:D
> Seriously, Travis...HOW on earth are you able to implement
> such things in such a short time?
>
I saw a need for it so I implemented it. Implementing CRC32 and Base64
turned out to be quite easy, for starters, and the protocol design was
pretty simple.
I was originally considering implementing ZMODEM, but from looking into it
that would have been far more complex (and overkill), and would run into
issues because it expects an 8-bit clean connection, and the zeptoforth
console is not 8-bit clean by default (because it traps control-C to
trigger a reboot and control-T to initiate "attention" sequences like
control-T z for sending the main task an interrupt exception). Note that
there is a way to make the zeptoforth console 8-bit clean, but that runs
into the opposite problem, where if you want to interrupt send_file.fs or
recv_file.fs the only way to do so would be to manually power-cycle your
Pico.
> And - of course - I will try it out as soon as possible.
> But first: I need something to eat (came back from work
> just before).
>
> THANKS A LOT! GREAT!
> Will report back later :)
> Cheers!
> Tuxic
>
You're welcome!
> PS: Two of the cheap RP2040 boards I ordered do not work with Zeptoforth
> (but the other two of the same kind do ... so this has nothing to do
> with Zeptoforth). Is there a way to erase the flash completly to
> containg really nothing? May be this would help...
If you have a 2 MB RP2040 board such as a Pico you can erase its flash
completely by pressing BOOTSEL while applying power, mounting the Mass
Storage device that shows up, and copying the UF2 file you can download
from https://datasheets.raspberrypi.com/soft/flash_nuke.uf2 to it. This
will erase both zeptoforth dictionary storage and zeptoforth blocks
storage. However, this file will most likely not work with an RP2040 board
with greater than 2 MB flash (I have not tried this though; I do not have
such a board on hand).
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9969521@
> github.com>
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Sat, Jul 6, 2024, 09:34 mcctuxic ***@***.***> wrote:
Hi Travis,
I tested to send a file via recv-file.fs and send-file.sh from my
Linux to a standard (original) Raspberry Pi Pico W, which was placed
on a Maker Pi Pico board.
The setup was as follows:
zed loaded into flash
FAT32 formatting of the flash via "send me a formatter".fs :)
reboot
SDcard with a FAT32 filesystem "mounted" via the code given in
'Getting started'
s" /" list-dir shows the directory of the SDcard
10 edit: I filled in some stuff like enable-line and the setup
of the SDcard in case I need to reboot, so I only need to do a
10 load
reboot
connect via picocom -b 115200 /dev/ttyACM0
10 load
everything seems fine - I could list the directory of the SDcard
then I proceeded with the steps decribed in the README file
to transfer files from the PC to the Pico.
I left picocom ctrl-a ctrl-q, which leave picocom without resetting
the tty.
I started send-file.sh from the commandline as described and transfered
README.md to the Pico.
Send-file.sh reports no errors.
I connected to the Pico via picocom as described above.
The README.md had overwritten block 10 instead of being
written to the SDcard.
(I have a backup of block 10 so no worries! 8) )
Cheers!
Tuxic
extra/common/recv_file.fs and extra/common/send_file.fs always use the
current filesystem set with fat32-tools::current-fs! . Note that after
being loaded extra/common/setup_blocks_fat32.fs installs code that calls
this with the in-flash FAT32 filesystem on bootup.
It sounds like you probably had extra/common/setup_blocks_fat32.fs loaded
and you accidentally rebooted at some point (which is as easy as hitting
control-C) so on reboot it reset the current filesystem to be the one in
block storage.
Alternatively, if you had not rebooted, you may have simply forgotten to
call fat32-tools::current-fs! with the SDHC card's filesystem.
Travis
… |
Beta Was this translation helpful? Give feedback.
-
On 07/06 10:27, tabemann wrote:
On Sat, Jul 6, 2024, 09:34 mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> I tested to send a file via recv-file.fs and send-file.sh from my
> Linux to a standard (original) Raspberry Pi Pico W, which was placed
> on a Maker Pi Pico board.
>
> The setup was as follows:
> zed loaded into flash
> FAT32 formatting of the flash via "send me a formatter".fs :)
> reboot
> SDcard with a FAT32 filesystem "mounted" via the code given in
> 'Getting started'
> s" /" list-dir shows the directory of the SDcard
> 10 edit: I filled in some stuff like enable-line and the setup
> of the SDcard in case I need to reboot, so I only need to do a
> 10 load
> reboot
> connect via picocom -b 115200 /dev/ttyACM0
> 10 load
> everything seems fine - I could list the directory of the SDcard
> then I proceeded with the steps decribed in the README file
> to transfer files from the PC to the Pico.
> I left picocom ctrl-a ctrl-q, which leave picocom without resetting
> the tty.
> I started send-file.sh from the commandline as described and transfered
> README.md to the Pico.
>
> Send-file.sh reports no errors.
>
> I connected to the Pico via picocom as described above.
> The README.md had overwritten block 10 instead of being
> written to the SDcard.
> (I have a backup of block 10 so no worries! 8) )
>
> Cheers!
> Tuxic
>
extra/common/recv_file.fs and extra/common/send_file.fs always use the
current filesystem set with fat32-tools::current-fs! . Note that after
being loaded extra/common/setup_blocks_fat32.fs installs code that calls
this with the in-flash FAT32 filesystem on bootup.
It sounds like you probably had extra/common/setup_blocks_fat32.fs loaded
and you accidentally rebooted at some point (which is as easy as hitting
control-C) so on reboot it reset the current filesystem to be the one in
block storage.
Alternatively, if you had not rebooted, you may have simply forgotten to
call fat32-tools::current-fs! with the SDHC card's filesystem.
Travis
Hi Travis,
Oh yes! That explains it! I have rebooted A LOT today ;) :) 8)
As always: Thank you for your help!
Cheers!
Tuxic
…
>
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Sat, Jul 6, 2024 at 12:50 PM mcctuxic ***@***.***> wrote:
On 07/06 10:27, tabemann wrote:
> On Sat, Jul 6, 2024, 09:34 mcctuxic ***@***.***> wrote:
Hi Travis,
Oh yes! That explains it! I have rebooted A LOT today ;) :) 8)
As always: Thank you for your help!
Cheers!
Tuxic
One note ─ you cannot mix the use of the in-flash FAT32 filesystem and
manual blocks storage (e.g. with 10 EDIT) because they live in the same
space (in-flash FAT32 filesystems are built on top of blocks storage, as
you know), and using one will corrupt the other in many cases. In this
case, you are lucky that you did not render your in-flash FAT32 filesystem
unusable by corrupting its structures. Also,
extra/common/setup_blocks_fat32.fs on its initial load (but not on
subsequent reboots) will erase all of blocks storage prior to initializing
a new master boot record and a new FAT32 partition if it does not detect a
valid master boot record in sector 0 (i.e. the first half of block 0) of
blocks storage.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9975879@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
Tuxic,
One thing is you should git pull the latest and recompile zeptoed. It turns
out that using 40 bytes "segments" in zeptoed was a really bad idea, such
that zeptoed crashed when I tried to load README.MD with it even though
README.MD is 27K and by default zeptoed allots 64K for itself. Also,
zeptoed is dog slow with long lines (after I had temporarily changed the
heap size to 128K), which are the case with README.MD (as I made each
paragraph a single line). As a result I changed the "segment" size to 256
bytes, and it no longer crashes when loading, and it is noticeably faster
(albeit still slow when dealing with long lines).
Travis
…On Sat, Jul 6, 2024 at 1:04 PM Travis Bemann ***@***.***> wrote:
On Sat, Jul 6, 2024 at 12:50 PM mcctuxic ***@***.***> wrote:
> On 07/06 10:27, tabemann wrote:
> > On Sat, Jul 6, 2024, 09:34 mcctuxic ***@***.***> wrote:
>
> Hi Travis,
>
> Oh yes! That explains it! I have rebooted A LOT today ;) :) 8)
> As always: Thank you for your help!
>
>
> Cheers!
> Tuxic
One note ─ you cannot mix the use of the in-flash FAT32 filesystem and
manual blocks storage (e.g. with 10 EDIT) because they live in the same
space (in-flash FAT32 filesystems are built on top of blocks storage, as
you know), and using one will corrupt the other in many cases. In this
case, you are lucky that you did not render your in-flash FAT32 filesystem
unusable by corrupting its structures. Also,
extra/common/setup_blocks_fat32.fs on its initial load (but not on
subsequent reboots) will erase all of blocks storage prior to initializing
a new master boot record and a new FAT32 partition if it does not detect a
valid master boot record in sector 0 (i.e. the first half of block 0) of
blocks storage.
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9975879@
> github.com>
|
Beta Was this translation helpful? Give feedback.
-
On Sat, Jul 6, 2024 at 6:46 PM Travis Bemann ***@***.***> wrote:
Tuxic,
One thing is you should git pull the latest and recompile zeptoed. It
turns out that using 40 bytes "segments" in zeptoed was a really bad idea,
such that zeptoed crashed when I tried to load README.MD with it even
though README.MD is 27K and by default zeptoed allots 64K for itself. Also,
zeptoed is dog slow with long lines (after I had temporarily changed the
heap size to 128K), which are the case with README.MD (as I made each
paragraph a single line). As a result I changed the "segment" size to 256
bytes, and it no longer crashes when loading, and it is noticeably faster
(albeit still slow when dealing with long lines).
If you have done this already, I highly suggest you do it again, as I have
made more fixes to zeptoed.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9975879@
>> github.com>
>
>
|
Beta Was this translation helpful? Give feedback.
-
On 07/06 08:33, tabemann wrote:
On Sat, Jul 6, 2024 at 6:46 PM Travis Bemann ***@***.***> wrote:
> Tuxic,
>
> One thing is you should git pull the latest and recompile zeptoed. It
> turns out that using 40 bytes "segments" in zeptoed was a really bad idea,
> such that zeptoed crashed when I tried to load README.MD with it even
> though README.MD is 27K and by default zeptoed allots 64K for itself. Also,
> zeptoed is dog slow with long lines (after I had temporarily changed the
> heap size to 128K), which are the case with README.MD (as I made each
> paragraph a single line). As a result I changed the "segment" size to 256
> bytes, and it no longer crashes when loading, and it is noticeably faster
> (albeit still slow when dealing with long lines).
>
If you have done this already, I highly suggest you do it again, as I have
made more fixes to zeptoed.
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/111/comments/9975879@
>>> github.com>
>>
>>
...Timemachine I said...Timemachine :)
Thanks for the info, Travis! :)
Cheers!
Tuxic
…
--
Reply to this email directly or view it on GitHub:
#111 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
...I am speechless... (Did I mentioned this before...? ;) )
You are using a time-machine...aren't you?
Just got the info that you have published an new release with FAT32 support for the internal flash memory.
The idea of a self-starting formatting tool is the most convenient solution I can think of...I have
already formatted the flash of my pico pi (I need to backup what is on flash of my pi pico w).
My board is now in the state of having a FAT32 formatted flash and Zed in RAM.
What is the correct doing to make the FAT32 flash "visible" to Zed?
and:
Will "compile-to-flash" work as before?
A big THANK YOU for implementing FAT32 for the internal flash! GREAT! :)
Cheers!
Tuxic
Beta Was this translation helpful? Give feedback.
All reactions