Unfortunately it looks like there is no Mecrisp for Arduino or the AVR CPUs. I did find FlashForth.

If I am looking for minimal start up time, would FlashForth be recommended?

The others I've seen seem rather non-standard and even odd. I don't have time to figure out new stuff. I have a very simple project I need to get running.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On 28/03/2023 9:36 am, Lorem Ipsum wrote:
> Unfortunately it looks like there is no Mecrisp for Arduino or the AVR CPUs. I did find FlashForth.
>
> If I am looking for minimal start up time, would FlashForth be recommended?
>
> The others I've seen seem rather non-standard and even odd. I don't have time to figure out new stuff. I have a very simple project I need to get running.

FlashForth isn't bad. The Mega will give you approx 43K of free flash to play
with compared to 23K for the UNO. Should be easy to pick up as @ ! etc works
on flash, ram. Biggest culture shock I found was FOR NEXT as opposed to DO LOOP.
Also FlashForth won't let you re-use the same name, requiring one to erase before
re-loading (e.g. using a MARKER word). I've been working on a fork that's a bit
more normal in that respect.

On Monday, March 27, 2023 at 7:37:07 PM UTC-4, dxforth wrote:
> On 28/03/2023 9:36 am, Lorem Ipsum wrote:
> > Unfortunately it looks like there is no Mecrisp for Arduino or the AVR CPUs. I did find FlashForth.
> >
> > If I am looking for minimal start up time, would FlashForth be recommended?
> >
> > The others I've seen seem rather non-standard and even odd. I don't have time to figure out new stuff. I have a very simple project I need to get running.
> FlashForth isn't bad. The Mega will give you approx 43K of free flash to play
> with compared to 23K for the UNO. Should be easy to pick up as @ ! etc works
> on flash, ram. Biggest culture shock I found was FOR NEXT as opposed to DO LOOP.
> Also FlashForth won't let you re-use the same name, requiring one to erase before
> re-loading (e.g. using a MARKER word). I've been working on a fork that's a bit
> more normal in that respect.

Oh, that sucks, the reuse thing. I was looking at parsing the input with the Forth interpreter. That would require using # as a new word. Any code using # inside <# #> could be early in the program, and # defined later. But that won't work I suppose. Doesn't really matter. It was just a thought.

I suppose I could get used to FOR NEXT, but I can't think why that would require no DO LOOP. Let the user decide which to use. I don't recall what the differences are. DO uses a start parameter and a limit. I don't recall what FOR NEXT does. Is the conditional at opposite ends of the loop in the two constructs?

I don't recall what MPE costs. But maybe I should bite the bullet. It's such a tiny job. I guess I could use whatever the Arduino is usually programmed in.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On 28/03/2023 12:21 pm, Lorem Ipsum wrote:
> On Monday, March 27, 2023 at 7:37:07 PM UTC-4, dxforth wrote:
>> On 28/03/2023 9:36 am, Lorem Ipsum wrote:
>>> Unfortunately it looks like there is no Mecrisp for Arduino or the AVR CPUs. I did find FlashForth.
>>>
>>> If I am looking for minimal start up time, would FlashForth be recommended?
>>>
>>> The others I've seen seem rather non-standard and even odd. I don't have time to figure out new stuff. I have a very simple project I need to get running.
>> FlashForth isn't bad. The Mega will give you approx 43K of free flash to play
>> with compared to 23K for the UNO. Should be easy to pick up as @ ! etc works
>> on flash, ram. Biggest culture shock I found was FOR NEXT as opposed to DO LOOP.
>> Also FlashForth won't let you re-use the same name, requiring one to erase before
>> re-loading (e.g. using a MARKER word). I've been working on a fork that's a bit
>> more normal in that respect.
>
> Oh, that sucks, the reuse thing. I was looking at parsing the input with the Forth interpreter. That would require using # as a new word. Any code using # inside <# #> could be early in the program, and # defined later. But that won't work I suppose. Doesn't really matter. It was just a thought.

FWIW here's a link to my fork (called UnoForth to avoid confusion):

https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

List of changes from FlashForth is given at the beginning of the source file.
Includes hex files for UNO, Mega, Leonardo.

> I suppose I could get used to FOR NEXT, but I can't think why that would require no DO LOOP. Let the user decide which to use. I don't recall what the differences are. DO uses a start parameter and a limit. I don't recall what FOR NEXT does. Is the conditional at opposite ends of the loop in the two constructs?

IIRC DO LOOP exists as a loadable extension. FOR NEXT in FlashForth uses a count. Assuming
10 then R@ in the loop goes from 9 to 0. If count is zero, the loop is not entered. It's
the equivalent of eForth's:

.... FOR AFT ... THEN NEXT ...

i.e. the AFT THEN is built-in. Conditional is at NEXT and AFT is an unconditional branch
that's run just once.

> I don't recall what MPE costs. But maybe I should bite the bullet. It's such a tiny job. I guess I could use whatever the Arduino is usually programmed in.
Forth Inc has SwiftX for AVR. I didn't think MPE made one (?)

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:
> Unfortunately it looks like there is no Mecrisp for Arduino or the AVR
> CPUs. I did find FlashForth.

There is also amForth, but if this is for the RS232 converter, at this
point I wouldn't use an Arduino. It is obsolete imho, and the Mega is
stupid expensive. You'll have already gotten an email from me about
what I'd use instead.

On Monday, March 27, 2023 at 10:12:19 PM UTC-4, dxforth wrote:
> On 28/03/2023 12:21 pm, Lorem Ipsum wrote:
> > On Monday, March 27, 2023 at 7:37:07 PM UTC-4, dxforth wrote:
> >> On 28/03/2023 9:36 am, Lorem Ipsum wrote:
> >>> Unfortunately it looks like there is no Mecrisp for Arduino or the AVR CPUs. I did find FlashForth.
> >>>
> >>> If I am looking for minimal start up time, would FlashForth be recommended?
> >>>
> >>> The others I've seen seem rather non-standard and even odd. I don't have time to figure out new stuff. I have a very simple project I need to get running.
> >> FlashForth isn't bad. The Mega will give you approx 43K of free flash to play
> >> with compared to 23K for the UNO. Should be easy to pick up as @ ! etc works
> >> on flash, ram. Biggest culture shock I found was FOR NEXT as opposed to DO LOOP.
> >> Also FlashForth won't let you re-use the same name, requiring one to erase before
> >> re-loading (e.g. using a MARKER word). I've been working on a fork that's a bit
> >> more normal in that respect.
> >
> > Oh, that sucks, the reuse thing. I was looking at parsing the input with the Forth interpreter. That would require using # as a new word. Any code using # inside <# #> could be early in the program, and # defined later. But that won't work I suppose. Doesn't really matter. It was just a thought.
> FWIW here's a link to my fork (called UnoForth to avoid confusion):
>
> https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw
>
> List of changes from FlashForth is given at the beginning of the source file.
> Includes hex files for UNO, Mega, Leonardo.
> > I suppose I could get used to FOR NEXT, but I can't think why that would require no DO LOOP. Let the user decide which to use. I don't recall what the differences are. DO uses a start parameter and a limit. I don't recall what FOR NEXT does. Is the conditional at opposite ends of the loop in the two constructs?
> IIRC DO LOOP exists as a loadable extension. FOR NEXT in FlashForth uses a count. Assuming
> 10 then R@ in the loop goes from 9 to 0. If count is zero, the loop is not entered. It's
> the equivalent of eForth's:
>
> ... FOR AFT ... THEN NEXT ...
>
> i.e. the AFT THEN is built-in. Conditional is at NEXT and AFT is an unconditional branch
> that's run just once.
> > I don't recall what MPE costs. But maybe I should bite the bullet. It's such a tiny job. I guess I could use whatever the Arduino is usually programmed in.
> Forth Inc has SwiftX for AVR. I didn't think MPE made one (?)

Yes, I just visited the MPE site and they have no AVR forth that I can find.. I remember when they didn't support ARMs and I tried to talk Stephen into making one on his dime. At that time, they didn't want to pay for it and were waiting for a customer to foot the bill. I tried to explain that ARM was going to be the next big thing. I don't think I convinced him, but maybe I planted the seed. lol

They seem to be very ARM oriented now.

I will take a look at Swift Forth. I can't believe I forgot them. Thanks.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

On Monday, March 27, 2023 at 11:53:06 PM UTC-4, Paul Rubin wrote:
> Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> > Unfortunately it looks like there is no Mecrisp for Arduino or the AVR
> > CPUs. I did find FlashForth.
> There is also amForth, but if this is for the RS232 converter, at this
> point I wouldn't use an Arduino. It is obsolete imho, and the Mega is
> stupid expensive. You'll have already gotten an email from me about
> what I'd use instead.

What do you call "stupid"? I have no idea why you would think the Arduino is "obsolete". I'll look at your email.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:
> What do you call "stupid"? I have no idea why you would think the
> Arduino is "obsolete". I'll look at your email.

"Stupid expensive" = idiom for something way more expensive than needed
for this purpose. The Arduino Mega's main feature is a huge number of
i/o pins. I guess there are some control applications for which it
isn't obsolete, but for this type of communications app it's a poor fit
nowadays. The email suggested using a Raspberry Pi Pico with a
Waveshare RS232 board. I have one of the boards on order and have an
email question pending with the manufacturer, so I'll send you an update
when something happens. The board should arrive around the end of the
week.

On Tuesday, March 28, 2023 at 4:43:11 AM UTC-4, Paul Rubin wrote:
> Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> > What do you call "stupid"? I have no idea why you would think the
> > Arduino is "obsolete". I'll look at your email.
> "Stupid expensive" = idiom for something way more expensive than needed
> for this purpose.

Yes, I know what it means. Your comment still requires explanation.

> The Arduino Mega's main feature is a huge number of
> i/o pins. I guess there are some control applications for which it
> isn't obsolete, but for this type of communications app it's a poor fit
> nowadays.

You have odd ideas of what fits and what doesn't. I don't have maximum requirements, only minimum... well, some are maximum, like price, size, weight.. I don't want anything that has to be shipped on a pallet, so the Auduino Mega is fine for this task. I have no reason to reject a board on I/O count. What you are thinking, is that it must be expensive, while it is not. Again, I have requirements of price, but the Arduino Mega is well under my limit. No need to optimize that which does not add useful value.

> The email suggested using a Raspberry Pi Pico with a
> Waveshare RS232 board. I have one of the boards on order and have an
> email question pending with the manufacturer, so I'll send you an update
> when something happens. The board should arrive around the end of the
> week.

I didn't realize the Pico used the oddball ARM chip, without the usual rPi Linux. That might work ok.

Please don't assume I am not discussing this with others.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

On 28/03/2023 7:43 pm, Paul Rubin wrote:
> ...
> The email suggested using a Raspberry Pi Pico with a
> Waveshare RS232 board.

I never considered Pico but googling I found a video of it being used
with Forth. I gather the chip has 264K ram and 2MB flash which sounds
plenty. OTOH it doesn't have the add-on boards Arduino is famous for?
Also not sure how the on-chip peripherals compare with AVR. Can you
give a summary?

Locally Pico boards sell for $AU15 inc. post which is dirt cheap.
I assume these are legit - unlike Arduino clones with counterfeit
ATmega328P ? How hot does the Pico run? I notice some sellers include
a heatsink!

In article <u00ah8$3kei$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>On 28/03/2023 7:43 pm, Paul Rubin wrote:
>> ...
>> The email suggested using a Raspberry Pi Pico with a
>> Waveshare RS232 board.
>
>I never considered Pico but googling I found a video of it being used
>with Forth. I gather the chip has 264K ram and 2MB flash which sounds
>plenty. OTOH it doesn't have the add-on boards Arduino is famous for?
>Also not sure how the on-chip peripherals compare with AVR. Can you
>give a summary?
>
>Locally Pico boards sell for $AU15 inc. post which is dirt cheap.
>I assume these are legit - unlike Arduino clones with counterfeit
>ATmega328P ? How hot does the Pico run? I notice some sellers include
>a heatsink!
>

A new development is noforth for the pico boards, to
be pubished shortly.
The 10 i/o processors is a bonus. For example I could reserve
one of those processors to generate a midi signal at the exact
specs, with buffering and no need for interrupts.

https://home.hccnet.nl/anij/nof/noforth.html

This is mature, with dozens of tested projects (click on
'Egel project') This goes back to the 8051.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Wednesday, March 29, 2023 at 6:09:48 AM UTC-4, none albert wrote:
> In article <u00ah8$3kei$1...@dont-email.me>, dxforth <dxf...@gmail.com> wrote:
> >On 28/03/2023 7:43 pm, Paul Rubin wrote:
> >> ...
> >> The email suggested using a Raspberry Pi Pico with a
> >> Waveshare RS232 board.
> >
> >I never considered Pico but googling I found a video of it being used
> >with Forth. I gather the chip has 264K ram and 2MB flash which sounds
> >plenty. OTOH it doesn't have the add-on boards Arduino is famous for?
> >Also not sure how the on-chip peripherals compare with AVR. Can you
> >give a summary?
> >
> >Locally Pico boards sell for $AU15 inc. post which is dirt cheap.
> >I assume these are legit - unlike Arduino clones with counterfeit
> >ATmega328P ? How hot does the Pico run? I notice some sellers include
> >a heatsink!
> >
> A new development is noforth for the pico boards, to
> be pubished shortly.
> The 10 i/o processors is a bonus. For example I could reserve
> one of those processors to generate a midi signal at the exact
> specs, with buffering and no need for interrupts.
>
> https://home.hccnet.nl/anij/nof/noforth.html
>
> This is mature, with dozens of tested projects (click on
> 'Egel project') This goes back to the 8051.

Interesting. I'm not clear on how this is ported to a new board. I suppose all the rPi pico boards will have the same console port. The hardware I would be using with the pico would use pins 1, 2 and 6, 7 for the application UARTs. Can a different port be used for the console?

It's not clear how to get to other pins when the waveshare serial port is attached. This may not be a good mate to this project. The Pico board only seems to have two UARTs. Several places to connect to them, but only two UARTs. Likewise, many pins, but only two SPI and two I2C.

BTW, if you'd like to make your web page more readable, you might not use the colors you are using, or maybe none at all. The grey is hard for me to read, and the orange text is nearly impossible. While colors are pretty, black text on white background is much more readable.

Any idea when noforth for the pico will be out?

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

On 29/03/2023 9:09 pm, albert wrote:
> In article <u00ah8$3kei$1@dont-email.me>, dxforth <dxforth@gmail.com> wrote:
>> On 28/03/2023 7:43 pm, Paul Rubin wrote:
>>> ...
>>> The email suggested using a Raspberry Pi Pico with a
>>> Waveshare RS232 board.
>>
>> I never considered Pico but googling I found a video of it being used
>> with Forth. I gather the chip has 264K ram and 2MB flash which sounds
>> plenty. OTOH it doesn't have the add-on boards Arduino is famous for?
>> Also not sure how the on-chip peripherals compare with AVR. Can you
>> give a summary?
>>
>> Locally Pico boards sell for $AU15 inc. post which is dirt cheap.
>> I assume these are legit - unlike Arduino clones with counterfeit
>> ATmega328P ? How hot does the Pico run? I notice some sellers include
>> a heatsink!
>>
>
> A new development is noforth for the pico boards, to
> be pubished shortly.
> The 10 i/o processors is a bonus. For example I could reserve
> one of those processors to generate a midi signal at the exact
> specs, with buffering and no need for interrupts.
>
> https://home.hccnet.nl/anij/nof/noforth.html
>
> This is mature, with dozens of tested projects (click on
> 'Egel project') This goes back to the 8051.

Thanks. Look forward to seeing the article when it's published.
It's a pity the Pico doesn't come in a form factor similar to Arduino
which would make it easier to develop with.

dxforth <dxforth@gmail.com> writes:
> Also not sure how the on-chip peripherals compare with AVR. Can you
> give a summary?

I have the impression that the AVR has better analog stuff but other
than that I'm not sure. The AVR can run at more voltages. The Pico
includes a built in DC to DC converter to give the right voltages to its
RP2040 chip.

> Locally Pico boards sell for $AU15 inc. post which is dirt cheap.

The bare board is US $4 in the US (plus shipping), and the version with
header pins pre-soldered is $5. There is another version that has a
wireless comms chip on board. The wireless chip does wifi and
bluetooth, but until recently the board was described as wifi-only,
since software support for bluetooth was not there yet. But, I think
bluetooth software has started to appear.

It is computationally a far more powerful board than any version of the
AVR. It has two ARM 125 MHz Cortex M0+ cores, 264K of ram, and two
programmable I/O processors (they are very minimal, like glorified
PWM's) that can be used for various timing constrained protocols as an
alternative to software bit banging.

I thought I remembered reading that Mecrisp Forth runs on it? It also
runs Micropython is a more modern interactive programming environment,
though resource hungry in comparison to Forth. The board has plenty of
resources though.

Lorem Ipsum <gnuarm.deletethisbit@gmail.com> writes:
> Yes, I know what it means. Your comment still requires explanation.

The Mega imho is overkill for the application, almost in the same way
that a mini PC is overkill.
> I didn't realize the Pico used the oddball ARM chip, without the usual
> rPi Linux. That might work ok.
>
> Please don't assume I am not discussing this with others.

It's fine, I don't want to send you a proposal to make the gadget until
I've tested the serial board and am comfortable with the idea of using
it. It's a $9 board, affordable even for a cave dweller like me, so I
don't mind having one to play with in any case. With luck I should have
it tomorrow.

On 30/03/2023 12:27 pm, Paul Rubin wrote:
>
> I thought I remembered reading that Mecrisp Forth runs on it? It also
> runs Micropython is a more modern interactive programming environment,
> though resource hungry in comparison to Forth. The board has plenty of
> resources though.

Yes - that was the Forth used in the video. The abundance of memory
and 32-bits is what makes it attractive to develop with. Curious what's
involved in rebuilding that forth. I've never stayed with a forth long
enough that there wasn't something I wanted to change. But then that's
the nature of Forth, for good or ill.

On Wednesday, March 29, 2023 at 9:31:29 PM UTC-4, Paul Rubin wrote:
> Lorem Ipsum <gnuarm.del...@gmail.com> writes:
> > Yes, I know what it means. Your comment still requires explanation.
> The Mega imho is overkill for the application, almost in the same way
> that a mini PC is overkill.

Ok, but that's a pointless statement. The Arduino Mega meets all the requirements and so is perfectly suitable for the job. I don't know why you can't see this. I think you get fascinated by the toys and have trouble seeing this as an engineering job. If I needed a #6 screw to hold something in place, but only have #10 screws, which will work, I use the #10 screws and don't complain about it being "overkill".

While the miniPC is very much overkill, it's a perfectly acceptable solution if I can meet the price, size and power goals. None of those are well defined, so right now, the miniPC is actually at the head of the list, because it meets all the requirements, including being available to buy.

> > I didn't realize the Pico used the oddball ARM chip, without the usual
> > rPi Linux. That might work ok.
> >
> > Please don't assume I am not discussing this with others.
> It's fine, I don't want to send you a proposal to make the gadget until
> I've tested the serial board and am comfortable with the idea of using
> it. It's a $9 board, affordable even for a cave dweller like me, so I
> don't mind having one to play with in any case. With luck I should have
> it tomorrow.

Good luck.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

On Wednesday, March 29, 2023 at 8:27:55 PM UTC-5, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
> > Also not sure how the on-chip peripherals compare with AVR. Can you
> > give a summary?
> I have the impression that the AVR has better analog stuff but other
> than that I'm not sure. The AVR can run at more voltages. The Pico
> includes a built in DC to DC converter to give the right voltages to its
> RP2040 chip.
> > Locally Pico boards sell for $AU15 inc. post which is dirt cheap.
> The bare board is US $4 in the US (plus shipping), and the version with
> header pins pre-soldered is $5. There is another version that has a
> wireless comms chip on board. The wireless chip does wifi and
> bluetooth, but until recently the board was described as wifi-only,
> since software support for bluetooth was not there yet. But, I think
> bluetooth software has started to appear.
>
> It is computationally a far more powerful board than any version of the
> AVR. It has two ARM 125 MHz Cortex M0+ cores, 264K of ram, and two
> programmable I/O processors (they are very minimal, like glorified
> PWM's) that can be used for various timing constrained protocols as an
> alternative to software bit banging.
>
> I thought I remembered reading that Mecrisp Forth runs on it? It also
> runs Micropython is a more modern interactive programming environment,
> though resource hungry in comparison to Forth. The board has plenty of
> resources though.

My zeptoforth also fully supports the Raspberry Pi Pico and at least partially
supports other RP2040-based boards (with some caveats - I have encountered
boards with GigaDevices flash which, while strictly-speaking compatible with
zeptoforth, provide poor flash-writing performance, and on boards other than
the Pico things such as LED's are not necessarily fully supported or require
compiling a "platform" constant to tell zeptoforth which board is in use). It
provides full preemptive multitasking with SMP support and supports most of
the hardware on the Pico with the notable exception of USB (even though I
plan on changing this in the near future). It is fully-featured out of the box,
and also comes with code for things such as controlling displays that can be
loaded by the user.

As for comparing and contrasting Mecrisp-Stellaris and zeptoforth, I must
admit that Matthias Koch is a compiler wizard and I envy his register-assigning
compiler (zeptoforth is also an inlining native code compiler, but does not
exude so much compiler-fu). Also, Mecrisp-Stellaris on the RP2040 executes
solely out of RAM, while zeptoforth on the RP2040 makes major use of XIP
mode to execute out of a RAM cache for the external Quad SPI flash (even
though the zeptoforth kernel is copied into RAM); this enables zeptoforth to
execute with larger codebases but makes Mecrisp-Stellaris faster because it
does not have to contend with XIP cache misses. Note that both zeptoforth
and Mecrisp-Stellaris can compile to RAM in addition to flash, in the case of
zeptoforth and Mecrisp-Stellaris on platforms other than the RP2040, or
flash mirrored into RAM, in the case of Mecrisp-Stellaris on the RP2040. In
general, Mecrisp-Stellaris is more suited to smaller systems than zeptoforth,
since it has a smaller kernel and is not as reliant on a large library of code
outside its kernel. This is why zeptoforth will never support STM32F0 MCU's
and most likely will never support STM32F1 MCU's (even though it could
possibly support some larger Chinese clones of the STM32F103 which
provide more flash than the original STM32F103 in the future).

As for some notes about hardware support for zeptoforth on RP2040-based
boards:

WiFi support on the Pico W is specifically not supported, because a CYW43
driver for it has not been written, and may never be written due to licensing
issues with Damien George's CYW43 driver (which includes necessary binary
blobs). Even if I ever do write a CYW43 driver, it will most likely have to be
under Damien George's onerous licensing terms, separate from the rest of
zeptoforth in a different repository (and left to the user to compile/load on
their own).

There is a limited WiFi driver for the Wio RP2040, but the ESP8285's WiFi radio
on the Wio RP2040 is so unreliable that I simply cannot say that I support it.
If it were not for that I spent over a month trying to get the thing to work and
do not want to consider that effort completely wasted, I would simply delete
my WiFi driver for it. Note that this WiFi driver has to be manually loaded by
the user. Also note that if you do try to use this driver, it gets very poor
performance and closing connections is completely broken thanks to a major
firmware bug ─ attempting to close a connection will cause the ESP8285 to
crash and become unresponsive until its watchdog reboots it, losing any
state it had before.