Replies: 13 comments
-
On Sat, Jul 6, 2024 at 11:43 PM mcctuxic ***@***.***> wrote:
Hi Travis,
I updated my local CVS repo of Zeptoforth . I have a bookmark in Dillo (a
small web browser ideal for browsing local documents in html) pointing to
the docus of Zeptoforth in this local repo.
With ext32-tools the word "list-file" is listed. The module is loaded and
imported on my Pico W.
I can list the root of my SDcard successfully, so I think everything is
set up correctly.
s" numbers.fth" file? . -1 ok
works but
s" numbers.fth" list-file unable to parse: list-file
does not.
lookup list
list-range list list-dir list-range
list
ok
is list-file in another module I did not load? Is list-file missing? Do I
need an additional cup of coffee ? ;)
Cheers!
Tuxic
FAT32-TOOLS::LIST-FILE is not in a build yet (for significant bugfixes I
tend to try to get new builds out ASAP, but I am less timely TBH with
relatively minor feature additions), so to get it you'll need to build
zeptoforth from source if you want it now.
Travis
… Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis, *** NO HURRY! *** Don't overheat your timemachine! :) :) :) Cheers! |
Beta Was this translation helpful? Give feedback.
-
On Sun, Jul 7, 2024 at 12:23 AM mcctuxic ***@***.***> wrote:
Hi Travis,
*** NO HURRY! *** *Don't overheat your timemachine!* :) :) :)
I didn't recognized, that list-file was added after the last release.
Cheers!
Tuxic
zeptoforth 1.6.1 is out, which includes FAT32-TOOLS::LIST-FILE.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9977713@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
On 07/07 09:08, tabemann wrote:
On Sun, Jul 7, 2024 at 12:23 AM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> *** NO HURRY! *** *Don't overheat your timemachine!* :) :) :)
> I didn't recognized, that list-file was added after the last release.
>
> Cheers!
> Tuxic
>
zeptoforth 1.6.1 is out, which includes FAT32-TOOLS::LIST-FILE.
Travis
> Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9977713@
> github.com>
>
Hi Travis,
...I made all jokes about "Back to the future", "Time
machines", "Deja vu/The Matrix" and the reversal of the vector of
cause and effect by crossing the lightspeed barrier already it seems.
Would you accept a BIG THANK YOU! instead ? :)
One minor thing though: Uploads via
utils/codeload3.sh -B 115200 -p /dev/ttyACM0 serial extra/common/zeptoed_all.fs
(for example) seem no longer to work and got stuck right in the
beginning with "cannot upload file". The name of the involved module is
created in the wordlist though. This happens while compiling to RAM as while
compiling to flash.
It seems not to be a terminal related thing, since switching back to the
previous version solves this while using the same setup of
kitty/picocom.
…
--
Reply to this email directly or view it on GitHub:
#112 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Mon, Jul 8, 2024 at 10:02 AM mcctuxic ***@***.***> wrote:
On 07/07 09:08, tabemann wrote:
> On Sun, Jul 7, 2024 at 12:23 AM mcctuxic ***@***.***> wrote:
>
> > Hi Travis,
> >
> > *** NO HURRY! *** *Don't overheat your timemachine!* :) :) :)
> > I didn't recognized, that list-file was added after the last release.
> >
> > Cheers!
> > Tuxic
> >
> zeptoforth 1.6.1 is out, which includes FAT32-TOOLS::LIST-FILE.
>
> Travis
>
> > Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9977713@
> > github.com>
> >
>
Hi Travis,
...I made all jokes about "Back to the future", "Time
machines", "Deja vu/The Matrix" and the reversal of the vector of
cause and effect by crossing the lightspeed barrier already it seems.
Would you accept a BIG THANK YOU! instead ? :)
One minor thing though: Uploads via
utils/codeload3.sh -B 115200 -p /dev/ttyACM0 serial
extra/common/zeptoed_all.fs
(for example) seem no longer to work and got stuck right in the
beginning with "cannot upload file". The name of the involved module is
created in the wordlist though. This happens while compiling to RAM as
while
compiling to flash.
It seems not to be a terminal related thing, since switching back to the
previous version solves this while using the same setup of
kitty/picocom.
This sounds like you already have zeptoed compiled to flash or you are
having tty setup problems, which I have run into before. Try connecting to
/dev/ttyACM0 at 115200 baud first with GNU Screen (not picocom), doing
nothing, and disconnecting, as that often solves utils/codeload3.sh issues
for me.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9988655@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
On 07/08 08:45, tabemann wrote:
On Mon, Jul 8, 2024 at 10:02 AM mcctuxic ***@***.***> wrote:
> On 07/07 09:08, tabemann wrote:
> > On Sun, Jul 7, 2024 at 12:23 AM mcctuxic ***@***.***> wrote:
> >
> > > Hi Travis,
> > >
> > > *** NO HURRY! *** *Don't overheat your timemachine!* :) :) :)
> > > I didn't recognized, that list-file was added after the last release.
> > >
> > > Cheers!
> > > Tuxic
> > >
> > zeptoforth 1.6.1 is out, which includes FAT32-TOOLS::LIST-FILE.
> >
> > Travis
> >
> > > Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9977713@
> > > github.com>
> > >
> >
>
> Hi Travis,
>
> ...I made all jokes about "Back to the future", "Time
> machines", "Deja vu/The Matrix" and the reversal of the vector of
> cause and effect by crossing the lightspeed barrier already it seems.
>
> Would you accept a BIG THANK YOU! instead ? :)
>
> One minor thing though: Uploads via
>
> utils/codeload3.sh -B 115200 -p /dev/ttyACM0 serial
> extra/common/zeptoed_all.fs
>
> (for example) seem no longer to work and got stuck right in the
> beginning with "cannot upload file". The name of the involved module is
> created in the wordlist though. This happens while compiling to RAM as
> while
> compiling to flash.
> It seems not to be a terminal related thing, since switching back to the
> previous version solves this while using the same setup of
> kitty/picocom.
This sounds like you already have zeptoed compiled to flash or you are
having tty setup problems, which I have run into before. Try connecting to
/dev/ttyACM0 at 115200 baud first with GNU Screen (not picocom), doing
nothing, and disconnecting, as that often solves utils/codeload3.sh issues
for me.
Travis
Hi Travis,
I nuked the flash and installed zeptoforth 1.6.1. Then I uploaded
fixed32 (to RAM) and it works flawlessly.
I switched to compile-to-flash and uploaded fixed32 and zed and
everything works fine.
GREAT! :)
Cheers!
Tuxic
…
> Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9988655@
> github.com>
>
--
Reply to this email directly or view it on GitHub:
#112 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Mon, Jul 8, 2024 at 11:08 AM mcctuxic ***@***.***> wrote:
Hi Travis,
I nuked the flash and installed zeptoforth 1.6.1. Then I uploaded
fixed32 (to RAM) and it works flawlessly.
I switched to compile-to-flash and uploaded fixed32 and zed and
everything works fine.
GREAT! :)
Cheers!
Tuxic
Great that it worked, but I have never run into a problem with
utils/codeload.sh that required a *full* flash nuke (as opposed to merely
reinstalling from UF2, which will by itself nuke the dictionary portion of
flash while leaving the block storage/FAT32 filesystem portion of flash
untouched). On the other hand, I have often run into tty issues that
prevent utils/codeload.sh from uploading.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9989368@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
On Mon, Jul 8, 2024 at 11:17 AM Travis Bemann ***@***.***> wrote:
On Mon, Jul 8, 2024 at 11:08 AM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> I nuked the flash and installed zeptoforth 1.6.1. Then I uploaded
> fixed32 (to RAM) and it works flawlessly.
> I switched to compile-to-flash and uploaded fixed32 and zed and
> everything works fine.
> GREAT! :)
>
> Cheers!
> Tuxic
>
Great that it worked, but I have never run into a problem with
utils/codeload.sh that required a *full* flash nuke (as opposed to merely
reinstalling from UF2, which will by itself nuke the dictionary portion of
flash while leaving the block storage/FAT32 filesystem portion of flash
untouched). On the other hand, I have often run into tty issues that
prevent utils/codeload.sh from uploading.
Minor correction -- that should be utils/codeload3.sh. codeload.py was
Thomas Goeppel's original program in Python 2 for uploading code to STM8
boards.
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9989368@
> github.com>
>
|
Beta Was this translation helpful? Give feedback.
-
On 07/08 09:17, tabemann wrote:
On Mon, Jul 8, 2024 at 11:08 AM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> I nuked the flash and installed zeptoforth 1.6.1. Then I uploaded
> fixed32 (to RAM) and it works flawlessly.
> I switched to compile-to-flash and uploaded fixed32 and zed and
> everything works fine.
> GREAT! :)
>
> Cheers!
> Tuxic
>
Great that it worked, but I have never run into a problem with
utils/codeload.sh that required a *full* flash nuke (as opposed to merely
reinstalling from UF2, which will by itself nuke the dictionary portion of
flash while leaving the block storage/FAT32 filesystem portion of flash
untouched). On the other hand, I have often run into tty issues that
prevent utils/codeload.sh from uploading.
Travis
Hi Travis,
yes, may be my nukeing was a little too harsh. I did a restore-state
and single reboots beforehand without success.
Next time I will try your "reset with gnu screen" method!
Another question which slightly touches the current topic (I think):
I have two waveshare RP2040 zero "boards" ("post stamp" would be more
accurate...tiny!).
Both run with micropython (at least...I get a REPL).
But only one works with Zeptoforth. The second one neither creates a /dev/ttyACM<n>
nor a /dev/sd<x>1 when booting Zeptoforth...but it reacts to powering up and bootsel pressed.
Then I will get a /dev/sd<x>1 which I can mount and write to.
Both are identical and both have 2M of flash.
I cannot say for sure, whether the MCUs are original or ....not.
Is it possible, that Zeptoforth is kind of "too fast" and hangs one
of MCUs due to - let us call it "production tolerances"? (Read: Shitty QA...)
What do you think, what could be the reason for this....any idea how I
could revive the second one may be?
By the way: I nuked both boards beforehand...
Cheers!
Tuxic
… > Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9989368@
> github.com>
>
--
Reply to this email directly or view it on GitHub:
#112 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Mon, Jul 8, 2024 at 1:01 PM mcctuxic ***@***.***> wrote:
Hi Travis,
yes, may be my nukeing was a little too harsh. I did a restore-state
and single reboots beforehand without success.
Next time I will try your "reset with gnu screen" method!
I would say the first thing to do is to connect to the board with GNU
Screen and then disconnect GNU Screen -- this solves a surprisingly large
set of issues.
Second, if that doesn't work, disconnect and reconnect your board from and
to your computer.
Third, if that still doesn't work upload a UF2 file to your board -- that
will nuke your dictionary in flash, while preserving block storage.
Another question which slightly touches the current topic (I think):
I have two waveshare RP2040 zero "boards" ("post stamp" would be more
accurate...tiny!).
Both run with micropython (at least...I get a REPL).
But only one works with Zeptoforth. The second one neither creates a
/dev/ttyACM<n>
nor a /dev/sd<x>1 when booting Zeptoforth...but it reacts to powering up
and bootsel pressed.
Then I will get a /dev/sd<x>1 which I can mount and write to.
Both are identical and both have 2M of flash.
I cannot say for sure, whether the MCUs are original or ....not.
To my knowledge there are no knockoff or counterfeit RP2040's out there.
When I have had problems with boards it usually has been due to soldering
issues on my part (I have a habit of melting the BOOTSEL button on Picos
with my soldering iron), but I have had boards unceremoniously die on me on
a couple occasions. Whether that was due to quality control issues or
accidentally killing the boards with ESD, I do not know.
Is it possible, that Zeptoforth is kind of "too fast" and hangs one
of MCUs due to - let us call it "production tolerances"? (Read: Shitty
QA...)
I don't think that zeptoforth is "too fast", but I would suspect QA issues
if anything.
What do you think, what could be the reason for this....any idea how I
could revive the second one may be?
By the way: I nuked both boards beforehand...
Cheers!
Tuxic
My initial thought is that there might be a bit that is bad in the flash
built into your misbehaving board that is above the highest address used by
default by MicroPython but below the highest bit in the flash used by
zeptoforth. This could cause it to crash on bootup.
Have you tried flashing your misbehaving board with a 'full' rather than a
'full_usb' board and then connecting to it with a USB-serial dongle? You
should see if it works with this setup,
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9990369@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
On 07/08 10:40, tabemann wrote:
On Mon, Jul 8, 2024 at 11:17 AM Travis Bemann ***@***.***> wrote:
> On Mon, Jul 8, 2024 at 11:08 AM mcctuxic ***@***.***> wrote:
>
>> Hi Travis,
>>
>> I nuked the flash and installed zeptoforth 1.6.1. Then I uploaded
>> fixed32 (to RAM) and it works flawlessly.
>> I switched to compile-to-flash and uploaded fixed32 and zed and
>> everything works fine.
>> GREAT! :)
>>
>> Cheers!
>> Tuxic
>>
>
> Great that it worked, but I have never run into a problem with
> utils/codeload.sh that required a *full* flash nuke (as opposed to merely
> reinstalling from UF2, which will by itself nuke the dictionary portion of
> flash while leaving the block storage/FAT32 filesystem portion of flash
> untouched). On the other hand, I have often run into tty issues that
> prevent utils/codeload.sh from uploading.
>
Minor correction -- that should be utils/codeload3.sh. codeload.py was
Thomas Goeppel's original program in Python 2 for uploading code to STM8
boards.
Travis
No problem! I read "codeload3.sh" automatically :)
…
> Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9989368@
>> github.com>
>>
>
--
Reply to this email directly or view it on GitHub:
#112 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
On 07/08 12:53, tabemann wrote:
On Mon, Jul 8, 2024 at 1:01 PM mcctuxic ***@***.***> wrote:
> Hi Travis,
>
> yes, may be my nukeing was a little too harsh. I did a restore-state
> and single reboots beforehand without success.
> Next time I will try your "reset with gnu screen" method!
>
I would say the first thing to do is to connect to the board with GNU
Screen and then disconnect GNU Screen -- this solves a surprisingly large
set of issues.
Second, if that doesn't work, disconnect and reconnect your board from and
to your computer.
Third, if that still doesn't work upload a UF2 file to your board -- that
will nuke your dictionary in flash, while preserving block storage.
Will do so ! :)
Next time I know what to check.
Would you prefer gnu screen in general over picocom generally?
> Another question which slightly touches the current topic (I think):
>
> I have two waveshare RP2040 zero "boards" ("post stamp" would be more
> accurate...tiny!).
> Both run with micropython (at least...I get a REPL).
> But only one works with Zeptoforth. The second one neither creates a
> /dev/ttyACM<n>
> nor a /dev/sd<x>1 when booting Zeptoforth...but it reacts to powering up
> and bootsel pressed.
> Then I will get a /dev/sd<x>1 which I can mount and write to.
>
> Both are identical and both have 2M of flash.
>
> I cannot say for sure, whether the MCUs are original or ....not.
>
To my knowledge there are no knockoff or counterfeit RP2040's out there.
The RP2040 of my Pico W and of my waveshare and of the other, 16 MB
board look different. The Pins are of different size while the case
seems the same. The printing on the case is of different kind. But I
am no expert here...
When I have had problems with boards it usually has been due to soldering
issues on my part (I have a habit of melting the BOOTSEL button on Picos
with my soldering iron), but I have had boards unceremoniously die on me on
a couple occasions. Whether that was due to quality control issues or
accidentally killing the boards with ESD, I do not know.
> Is it possible, that Zeptoforth is kind of "too fast" and hangs one
> of MCUs due to - let us call it "production tolerances"? (Read: Shitty
> QA...)
>
I don't think that zeptoforth is "too fast", but I would suspect QA issues
if anything.
Yes, QA seems the culprit here.
By the way: The upload speed when compile-to-flash is set, is slower on
the 2MB waveshare boards as with my Pico W.
The other performances seem to be identical (no scientific
measurements!....It "feels" that way.)
> What do you think, what could be the reason for this....any idea how I
> could revive the second one may be?
>
> By the way: I nuked both boards beforehand...
>
> Cheers!
> Tuxic
My initial thought is that there might be a bit that is bad in the flash
built into your misbehaving board that is above the highest address used by
default by MicroPython but below the highest bit in the flash used by
zeptoforth. This could cause it to crash on bootup.
YES! That is a good idea!
Have you tried flashing your misbehaving board with a 'full' rather than a
'full_usb' board and then connecting to it with a USB-serial dongle? You
should see if it works with this setup,
...will check that after work!
Travis
Cheers!
Tuxic
… > Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9990369@
> github.com>
>
--
Reply to this email directly or view it on GitHub:
#112 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
On Mon, Jul 8, 2024 at 9:33 PM mcctuxic ***@***.***> wrote:
Hi Travis,
On 07/08 12:53, tabemann wrote:
> On Mon, Jul 8, 2024 at 1:01 PM mcctuxic ***@***.***> wrote:
>
> > Hi Travis,
> >
> > yes, may be my nukeing was a little too harsh. I did a restore-state
> > and single reboots beforehand without success.
> > Next time I will try your "reset with gnu screen" method!
> >
>
> I would say the first thing to do is to connect to the board with GNU
> Screen and then disconnect GNU Screen -- this solves a surprisingly large
> set of issues.
>
> Second, if that doesn't work, disconnect and reconnect your board from
and
> to your computer.
>
> Third, if that still doesn't work upload a UF2 file to your board -- that
> will nuke your dictionary in flash, while preserving block storage.
Will do so ! :)
Next time I know what to check.
Would you prefer gnu screen in general over picocom generally?
I normally prefer picocom because it doesn't clear the screen when I exit,
but I use GNU Screen for my build scripts and for un-wedging the TTY device
if I run into trouble with it.
> Another question which slightly touches the current topic (I think):
> >
> > I have two waveshare RP2040 zero "boards" ("post stamp" would be more
> > accurate...tiny!).
> > Both run with micropython (at least...I get a REPL).
> > But only one works with Zeptoforth. The second one neither creates a
> > /dev/ttyACM<n>
> > nor a /dev/sd<x>1 when booting Zeptoforth...but it reacts to powering
up
> > and bootsel pressed.
> > Then I will get a /dev/sd<x>1 which I can mount and write to.
> >
> > Both are identical and both have 2M of flash.
> >
> > I cannot say for sure, whether the MCUs are original or ....not.
> >
>
> To my knowledge there are no knockoff or counterfeit RP2040's out there.
The RP2040 of my Pico W and of my waveshare and of the other, 16 MB
board look different. The Pins are of different size while the case
seems the same. The printing on the case is of different kind. But I
am no expert here...
That probably is a matter of how the boards were fabricated.
> When I have had problems with boards it usually has been due to soldering
> issues on my part (I have a habit of melting the BOOTSEL button on Picos
> with my soldering iron), but I have had boards unceremoniously die on me
on
> a couple occasions. Whether that was due to quality control issues or
> accidentally killing the boards with ESD, I do not know.
>
>
> > Is it possible, that Zeptoforth is kind of "too fast" and hangs one
> > of MCUs due to - let us call it "production tolerances"? (Read: Shitty
> > QA...)
> >
>
> I don't think that zeptoforth is "too fast", but I would suspect QA
issues
> if anything.
Yes, QA seems the culprit here.
By the way: The upload speed when compile-to-flash is set, is slower on
the 2MB waveshare boards as with my Pico W.
The other performances seem to be identical (no scientific
measurements!....It "feels" that way.)
That is a matter of that some boards use different 25Q flash from other
boards. I find the Winbond 25Q flash on the Pico and the Pico W is faster
to write than the GigaDevices 25Q flash on some of the other boards.
>
> > What do you think, what could be the reason for this....any idea how I
> > could revive the second one may be?
> >
> > By the way: I nuked both boards beforehand...
> >
> > Cheers!
> > Tuxic
>
>
> My initial thought is that there might be a bit that is bad in the flash
> built into your misbehaving board that is above the highest address used
by
> default by MicroPython but below the highest bit in the flash used by
> zeptoforth. This could cause it to crash on bootup.
YES! That is a good idea!
> Have you tried flashing your misbehaving board with a 'full' rather than
a
> 'full_usb' board and then connecting to it with a USB-serial dongle? You
> should see if it works with this setup,
...will check that after work!
>
> Travis
Cheers!
Tuxic
Good luck!
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/112/comments/9993276@
github.com>
|
Beta Was this translation helpful? Give feedback.
-
Hi Travis,
I updated my local CVS repo of Zeptoforth . I have a bookmark in Dillo (a small web browser ideal for browsing local documents in html) pointing to the docus of Zeptoforth in this local repo.
With ext32-tools the word "list-file" is listed. The module is loaded and imported on my Pico W.
I can list the root of my SDcard successfully, so I think everything is set up correctly.
s" numbers.fth" file? . -1 ok
works but
s" numbers.fth" list-file unable to parse: list-file
does not.
is list-file in another module I did not load? Is list-file missing? Do I need an additional cup of coffee ? ;)
Cheers!
Tuxic
Beta Was this translation helpful? Give feedback.
All reactions