Micropython vs Forth

[minf...@arcor.de]

MicroPython claims to be a lean and efficient implementation of the Python 3 programming language that includes a small subset of the Python standard library and is optimised to run on microcontrollers and in constrained environments. Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM.
(source https://micropython.org/)

Standard Forth is smaller and faster but its barebones wordsets are aimed at CPU abstraction and creating application-specific DSLs in a DYI fashion. Code sharing is essentially hampered by this philosophy.

My estimation: C/C++ are already predominant in the classic Forth application domains. With the rise of powerful embedded interpreters like MicroPython, there is no room anymore for standard Forth. Learning standard Forth has become a waste of time.

Your opinion?

[minf...@arcor.de]

oops: DIY

[Andrew Haley]

minf...@arcor.de wrote:
> Am Mittwoch, 13. September 2017 09:52:27 UTC+2 schrieb minf...@arcor.de:
>> MicroPython claims to be a lean and efficient implementation of the Python 3 programming language that includes a small subset of the Python standard library and is optimised to run on microcontrollers and in constrained environments. Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM.
>> (source https://micropython.org/)
>>
>> Standard Forth is smaller and faster but its barebones wordsets are
>> aimed at CPU abstraction and creating application-specific DSLs in

>> a [DIY] fashion. Code sharing is essentially hampered by this

>> philosophy.
>>
>> My estimation: C/C++ are already predominant in the classic Forth
>> application domains. With the rise of powerful embedded
>> interpreters like MicroPython, there is no room anymore for
>> standard Forth. Learning standard Forth has become a waste of time.
>>
>> Your opinion?

My opinion is that your opinion makes no sense. Code sharing isn't
hampered by the Forth philosophy, and embedded systems need real-time
performance which Python can't provide. While it is true that
clueless Forth programmers can generate languages with magic parsing
words and programs that are incomprehensible to everyone except
themselves, it's not compulsory and clueful Forth programmers don't do
that.

Andre.

[dxf...@gmail.com]

It's always been the case the more control you
have over a process the better off you will be.
Would you be happy using micropython? How long
before you found it restrictive? Even if you
were prepared to be just a user, you'll be
at the mercy of the developers. What happens to
your investment when they get tired of supporting
micropython and decide to move on?

There's a line in Starting Forth where Brodie
says few programmers who learn Forth go back to
other languages. It's as true today as when he
wrote it. It's about control and whether you
really have it.

[minf...@arcor.de]

I think this is true for one-man-shows (I am simplifying of course).

When you have to develop and support systems with limited
and varying engineering teams, it is difficult and error-prone
to confront them with an esoteric programming language in their work.

[Cecil Bayona]

Every language is esoteric until you learn it. Python is fine if you
have large capable CPUs and you are mostly playing with programming but
for a real embedded application cost matters and if you want a low cost
CPU with fewer resources then Python is totally out of the picture, if
you need decent performance then again Python is out of the picture.

As far as a group of persons working on a project Forth works fine as it
allows individuals to work on their part of the project without having
the complete software available so a little planning ahead of time like
in all software environments to divvy out the software into pieces
managed by individual team members. It's easier as Forth easily allows
one to setup the conditions that ones piece of software requires.

That description of Python is by persons with a marketing point of view,
efficient compared to what? Python might work for simple IOT software on
upper end M3 or M4 ARM CPUs but anything less than that it won't work at
all.

As an example, I wrote an application in Forth using a MSP430 CPU, it
has 16KB of Flash, it's a PID temperature controller for an oven used to
solder SMT boards. It controls the temperature of the oven, ramping the
temperatures to match a set recommended profile, send the status and
temperature readings to a PC with a USB port, control and read devices
using I2C and SPI ports, and controls the heater elements and a cooling
fan. With Forth I have a lot of memory left over for future features
with Python that would not be possible at all unless I use a M3 ARM CPU
at least, and Python has garbage collection so at times the CPU goes
away unpredictably for a while while it's doing garbage collection, I
can't have that going on as the temperature software stops running and
causes a temperature glitch. Python would work fine for the PC software
that gathers the data, commands the oven controller to start a cycle,
and display the data as the information on the USB port is buffered so
garbage collection is not fatal but it is annoying.

--
Cecil - k5nwa

[Brad Eckert]

Minimization is the art of Zen. Complexity is cheaper than it used to be, but it will always contain hidden costs. Forth as a practice is the pursuit of simplicity. 256 kB of code space is hardly simple. 32kB of code is very large for Forth, including the application.

Forth is a language for building your own application specific language. This makes Forth harder for pointy headed bosses because this new language is only familiar to the programmer who wrote it. So, there needs to be more discipline within the group to craft a holistic system. That's different from everyone coding modules in C or whatever and integrating afterwards.

[JUERGEN]

Is there an example of a real application or even a real-time application you can give written in Micropython?? If there are sufficient ressources - any language you like ( or not ) will do. As you are implying any other language is better, why do you ask the question here? You have made up your mind already.

[hughag...@gmail.com]

It is wrong to assume that ANS-Forth is Forth.
ANS-Forth is just a marketing gimmick from Forth Inc. --- it should not be considered to be Forth at all.

One of the many problems with ANS-Forth is that it assumes that the same standard can work for both micro-controllers and desktop-computers.
My Straight Forth is designed only for desktop-computers. It assumes a 64-bit cell, for one thing.
Also, it provides code that returns information from the dictionary.
For example, given an xt, VOCNO@ returns the vocabulary, IMMEDIATE@ returns whether it is immediate or not, etc.
Also, VOCNO! IMMEDIATE! etc. set these attributes for the word given an xt.
Obviously, accessing the dictionary attributes doesn't can't be done on a micro-controller.
Straight Forth is designed to be a host for Forth cross-compilers that target micro-controllers.
This is why it needs to access the dictionary attributes of a word given an xt.

I'm not qualified to design a standard for a micro-controller Forth. I'll leave that to people with more micro-controller experience.
I can write a cross-compiler though. Any standard for micro-controller Forth that arises can be supported.
I'm dubious that there is a need for a standard for micro-controller Forth, but maybe so.
I don't care if there is a standard for micro-controller Forth or not.

As for MicroPython, I consider that to be a joke.
You will need a 32-bit processor, and you won't be able to support hard-real-time applications.
What is the point of using an ARM Cortex, but not being able to do applications that a 65c02 could handle?
MicroPython will be used primarily in education. H.S. students will program a robot to wave to the crowd at the science-fair.
The student should get a 'C' for that. To get a 'B' or an 'A' the student would need to use a micro-controller.
I don't have any experience with micro-controllers myself --- whether I could get an 'A' myself remains to be seen.

[minf...@arcor.de]

This is no joke question!

Development and service engineers and service mistakes (the travelling costs to customers alone are horrendous) by far outweigh hardware costs.

[minf...@arcor.de]

Am Mittwoch, 13. September 2017 17:46:31 UTC+2 schrieb JUERGEN:

mPython stands representative for embedded interpreters here.
There are applications for it, although publicly known mostly for the pyboard
(and others). See https://forum.micropython.org/index.php
Another older example would be Lua.

And no, we have not decided yet, but thinking in this direction.
Hence my "poll of opinions".

[dxf...@gmail.com]

Maybe it is impossible to use Forth in your
situation if there's hostility to it. OTOH
neither is it good catering to the least common
denominator in terms of ability as that just
encourages mediocre outcomes.

[Liang Ng]

Welcome to Fifth 5gws.epizy.com

I started using Linux in the 1990s. I found GNURoot Debian, a Linux virtual machine on Android in 2015. GNURoot can run standard Debian ARM Distribution. But I needed a GUI to make it work.

Eventually I realized that I can use Reverse Polish Notation to simplify web programming, as a front end to JavaScript and PHP (script translation).

I think the idea of using RPN/Forth as a "universal intermediary script" to "translate" into ANY programming language is probably a novel idea.

If you use Forth/RPN/Fifth as an "intermediary script", then it becomes meaningless really to compare programming languages!! Because you can translate ALL programming languages into Forth/RPN/Fifth!!

I am now experimenting this idea with beginners as well as professional programmers -- there are simply too many programming languages to learn -- and it seems Fifth is perhaps the only practical solution to simplify and "unite" them all!!

[Paul Rubin]

JUERGEN <epld...@aol.com> writes:
> Is there an example of a real application or even a real-time
> application you can give written in Micropython??

Micropython is pretty new but you can think of Micropython vs Forth as
similar to BASIC vs Forth. Yes it makes things easier, and it's easier
to learn. Yes it's slower and uses more memory. It's a trade-off like
anything else. It does come out on top sometimes.

It doesn't need 256k of flash. More like 100k, admittedly still very
large compared to Forth. It runs with some pain on the BBC Microbit.
The GC pauses might get in the way of high frequency realtime stuff, but
how many of us write stuff like that? The idea of it being a problem
with a slow thermal PID like a soldering iron controller doesn't come
across as plausible. They used to do that stuff with mechanical
thermostats/actuators and steam valves, fer cryin' out loud.

Yes the MCU you need to run Micropython costs more than a minimal Forth
MCU. That's significant if you're shipping millions (or anyway 10000's)
of units of the product. How many of us do that? The MSP430 is pretty
cool but it's getting squeezed out by 32-bit parts.

[minf...@arcor.de]

Who spoke of hostility?? There is no emotion in it but practical reasoning
for industry applications.

[minf...@arcor.de]

Am Mittwoch, 13. September 2017 17:15:53 UTC+2 schrieb Cecil - k5nwa:
> ... and Python has garbage collection so at times the CPU goes

> away unpredictably for a while while it's doing garbage collection, I
> can't have that going on as the temperature software stops running and
> causes a temperature glitch. Python would work fine for the PC software
> that gathers the data, commands the oven controller to start a cycle,
> and display the data as the information on the USB port is buffered so
> garbage collection is not fatal but it is annoying.
>

This is plainly oversimplified. Like a mantra the supposed threat of execution
stalls by GC pops up when considering high level languages in time constrained
applications.

Yes, GC is a factor with heavy dynamic data flow that fills up the heap,
e.g. typical in communication or web applications.

But no, GC is no factor when you don't have dynamic data, e.g. can use static
circular buffers.

And GC can be controlled proactively to occur only at non-critical times
(see Python's gc module).

[minf...@arcor.de]

See also this 2 years old article:
http://www.edn.com/electronics-blogs/embedded-basics/4440447/Using-MicroPython-for-real-time-software-development

[Mark Wills]

You're right.

The innovation that is taking place around the orbit of Python is frankly
staggering.

And all the software is free.

What has Forth done lately?

Case in point, the Pycom LoPy: a 32 bit MCU with built in WiFi, Bluetooth
(lo energy and classic modes), and Lora. 2 x UART, 2 x SPI, I2C, I2S,
micro SD card, 8x12 bit ADCs, 4x16 bit timers with PWM and input capture,
DMA on all peripherals, and 24 GPIOs.

Oh: and a real-time clock.

512K RAM, 4MB of flash, hardware floating point acceleration, and uPython
with multi-threading (including locking, blocking/non-blocking etc).

Runs from -40 to +85 C operating range. At 3V3 it pulls 10uA when asleep
and can wake up on interrupt.

This board weighs 7 grams and runs MicroPython. All the software is free.

Cost? 29 euros. https://pycom.io/product/lopy/

Forth, as cool and as neat as it is, cannot compete with this.

It's not about the language; it's about cost, competitive edge, and
time to market.

I did in a day (yesterday) in MicroPython what would have taken me more
than two weeks in Forth. I built a data repeater that repeats a number
of digital and analogue IOs over the air (Lora, on 868Mhz) to an RTU
that is 5km away. And that included unpacking the hardware!

In Forth, I'd be reading data sheets for months just to figure out how
the Lora radio works, and how to turn off the other hardware.

So, with Forth, it's not really the *language* itself, it's the lack
of any eco-system built around Forth. The innovation and eco-system in the
Python world is an unstoppable juggernaut. It's also now the fastest
growing language in the world, according to Stack Overflow.

Why is that? Is it because the language is so great? No. I'm personally
not a fan of some of its esoteric syntax. It's because it's the most
ubiquitous programming glue in the world. Nothing can beat it because of
the sheer volume of free software and libraries that is available for it.

The disadvantage is: those libraries are someone else's work, so you're
exposing yourself to risks in terms of bugs in the various Python
libraries and frame works (case in point: Django). *However*, the
libraries are open source, all being worked on/updated/improved so it's
not that different to developing a library in a closed software shop.
The advantage is, there could be 100 programmers working on the the library
that you are using, and it costs *you* nothing. You just reap the
benefits.

Who is going to develop a LoRaWAN gateway stack in Forth? Anyone?

Okay then, what about an MQTT client? Any takers? (You'll need a TCP/IP
stack to build it on first).

Anyone?

CLF is a Forth echo-chamber. As much as I love the langauge, there is a
massive, scary amount of innovation going on out there, that costs $0.00.

I'll give a final example.

National infrastructure security: So, monitoring water pumping stations,
electricity sub-stations etc.

Some of these sites are fitted with CCTV which is *horrendously* expensive.
Why? Because it requires an always-on data connection to stream video
(albeit low frame-rate) back to a security monitoring station, and it
requires humans to sit there 24/7 and watch the screens.

I can now produce a CCTV system that waits until it detects a human
face before raising an alarm. Only at that point does it need to send
video back to a control room. I can reduce my data bandwidth by 99%
and I don't need a room full of meat bags to sit there watching TV
all day.

This is real, pervasive, money saving innovation. It's easy to sell
something if you can prove it saves money.

The cost of this facial recognition software?

Nothing. It's free Python software.

https://www.youtube.com/watch?v=88HdqNDQsEk

Forth is decades behind, and doesn't have a large enough user-base to
attract any development effort.

Unfortunate, but that's where we are.

[minf...@arcor.de]

Thank you for this report and your taking time to write it !!

[foxaudio...@gmail.com]

Sad commentary Mark, but true IMHO.
My observations after exiting the Forth universe for more than a decade and returning:

1. There is something about the easy access to low level detail that seems to cause the Forth programmer to languish at the low levels. ( I am guilty here)

2. With my business hat on I see one of the big innovations in technology to be not tech. but
legal. The open-source business model has allowed companies to work in a new way that fosters
the kind of explosion that you are talking about. It's not PYTHON per se, but rather the freedom
to use it. So the innovation is the change in how money is extracted in the process.
Giga bytes of Code are FREE but oh... you want a smart CCTV system, well that's gonna cost you!

So perhaps Forth is not so behind in software but rather more in how it is offered to the world
in the 21st century.

My 2 cents

[hughag...@gmail.com]

On Thursday, September 14, 2017 at 12:02:18 AM UTC-7, Mark Wills wrote:
> The innovation that is taking place around the orbit of Python is frankly
> staggering.

> ...

> Forth, as cool and as neat as it is, cannot compete with this.
>

> So, with Forth, it's not really the *language* itself, it's the lack
> of any eco-system built around Forth. The innovation and eco-system in the
> Python world is an unstoppable juggernaut. It's also now the fastest
> growing language in the world, according to Stack Overflow.
>
> Why is that? Is it because the language is so great? No. I'm personally
> not a fan of some of its esoteric syntax. It's because it's the most
> ubiquitous programming glue in the world. Nothing can beat it because of
> the sheer volume of free software and libraries that is available for it.
>
> The disadvantage is: those libraries are someone else's work, so you're
> exposing yourself to risks in terms of bugs in the various Python
> libraries and frame works (case in point: Django). *However*, the
> libraries are open source, all being worked on/updated/improved so it's
> not that different to developing a library in a closed software shop.
> The advantage is, there could be 100 programmers working on the the library
> that you are using, and it costs *you* nothing. You just reap the
> benefits.

> ...

> CLF is a Forth echo-chamber. As much as I love the langauge, there is a
> massive, scary amount of innovation going on out there, that costs $0.00.

Mark Wills is right about some things, and wrong about other things.

It is not strictly true that there is a lot of innovation being done in Python.
The innovative software is done in C. Python is just a wrapper around it. Python is glue.

There is no innovative software done in Python. The Python programmers are mostly script-kiddies.
They have as much innovation as a beagle. They are followers, not leaders.
The assumption behind Pythonic code is that somebody smart (not you) already knows how to write your program,
and your goal is to write it following their rules so your code looks exactly the same as everybody else's.
Being innovative in Python is against the rules. Everybody will scream: "That is not Pythonic code! Who told you to write your program that way?"

So Mark was wrong when he said that innovative programming is done in Python --- he was oriented 180 degrees away from the truth.

The difference between Forth and Python is that in Forth the innovation is done in Forth and in Python the innovation is done in C.
Of course, the Gforth programmers will disagree. They say that in Gforth the innovation is done in C ---
they want Gforth to be a scripting language similar to Python --- glue for C code-libraries.

When I worked at Testra, they built the MiniForth processor so their motion-control boards would run twice as fast and cost half as much.
Imagine if I told them: "Wonderful! Hopefully somebody smart will retarget GCC for your processor soon.
And, hopefully somebody smart will get MicroPython running on your processor soon.
And, hopefully somebody smart will write a code-library in C that does motion-control and uses MicroPython as a wrapper.
Then I will spring into action and write a MicroPython program that does motion-control for your laser etcher.
Of course, I will claim to be a heap big innovator when I do this, and demand a hefty paycheck..."

On the other hand, Mark was right when he said:
"So, with Forth, it's not really the *language* itself, it's the lack of any eco-system built around Forth."

The Forth culture (at least, as represented by ANS-Forth) is corrupt:
---------------------------------------------------------------------
Virtually every Forth application needs some kind of array structures. The reason that some general-purpose one might be "little used"
is because it's so easy to make a version that does *exactly* what the application needs rather than some generic definition. ...
The objective is to master the toolset and be able to think clearly about exactly what kind of arrays will be useful in your application
and then build exactly that kind.
---------------------------------------------------------------------

This is stupid! Your application doesn't need a customized array that is somehow better than a generic array.
There is no employer who will pay anybody to implement an array.
There is no employer who will wait for you to start writing your application program while you implement an array.
Implementing an array is not too difficult --- what about a self-balancing binary-tree?

Also stupid is this: "Virtually every Forth application needs some kind of array structures."
She says that because the array is the only data-structure that she knows how to implement.
She doesn't actually know how to implement an array anyway, because she uses CREATE DOES> for this.
My ARY is superior in every way to a CREATE DOES> array.

Also, even if ARY became standard (never will happen), nobody would care. I wouldn't care!
The reason is that I almost never use arrays anyway. I use linked-lists for almost everything.
My LIST.4TH allows data-structures to be built at run-time and to grow and shrink dynamically.
Both ARY and the CREATE DOES> arrays require the array to be defined at compile-time of a fixed size and dimension.

It is possible to have arrays built at run-time that grow and shrink dynamically. Factor has "sequences" that do this.
This is complicated though, and in Factor it requires GC.
My LIST.4TH is actually inspired by Factor's sequences. I was impressed by how almost all Factor code uses the same data-structure.
I wrote LIST.4TH so that almost all ANS-Forth code could use this data-structure.
In Straight Forth I have "chains" as the data-structure that is supposed to be used by almost all code.
It is possible to implement other data-structures, but this is needed less often then people suppose.
If most programs use a common data-structure, then code-libraries can be provided that work with it.
Having some commonality in how data is stored, is a huge help in making code-libraries useful.

[Paul Rubin]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> embedded systems need real-time performance which Python can't
> provide.

I wonder about this. It's obviously false that 100% of embedded systems
need real-time performance which Python can't provide, since lots of
embedded systems aren't particularly realtime. So it's some amount less
than 100%. For example, maybe it's 90%. On the other hand, maybe it's
10%. I don't have a really clear read on which.

I know many things that used to be done with careful software timing
(bit banging serial i/o, PWM, stuff like that) are now often built into
the MCU hardware. So that gets rid of some realtime burden on the app
code right there.

For some other stuff, maybe programmers underestimate the latency
tolerance, like for the temperature controlled soldering iron someone
mentioned. IMHO doing that in Python would be fine, despite the
possibility of a millisecond GC pause here or there. Of course there
apps that can't stand a millisecond delay, but how often is that an
issue?

I mentioned I bought this board recently:

https://www.adafruit.com/product/3501

I still haven't had time to mess with it but it seems fine for most of
the embedded things I've ever imagined using Forth for.

[Paul Rubin]

dxf...@gmail.com writes:
> Would you be happy using micropython? How long before you found it
> restrictive? Even if you were prepared to be just a user, you'll be at
> the mercy of the developers.

That's different from Forth exactly how? Micropython is free to
download and modify: can you say that of most of the fancier Forths that
are out there?

> What happens to your investment when they get tired of supporting
> micropython and decide to move on?

What investment? If you already use Python, then Micropython is just
another implementation.

[Andrew Haley]

Paul Rubin <no.e...@nospam.invalid> wrote:
>
> For some other stuff, maybe programmers underestimate the latency
> tolerance, like for the temperature controlled soldering iron someone
> mentioned. IMHO doing that in Python would be fine, despite the
> possibility of a millisecond GC pause here or there.

Of course, if your computer is many orders of magnitude faster than
you need, there won't be a problem. For a temperature-controlled
soldering iron any kind of computer is overkill.

Andrew.

[dxf...@gmail.com]

On Friday, September 15, 2017 at 5:52:38 PM UTC+10, Paul Rubin wrote:

> dx..@gmail.com writes:
> > Would you be happy using micropython? How long before you found it
> > restrictive? Even if you were prepared to be just a user, you'll be at
> > the mercy of the developers.
>
> That's different from Forth exactly how? Micropython is free to
> download and modify: can you say that of most of the fancier Forths that
> are out there?

The premise behind Forth is that it's simple
enough for an adept programmer to modify.
You provide the support.

>
> > What happens to your investment when they get tired of supporting
> > micropython and decide to move on?
>
> What investment? If you already use Python, then Micropython is just
> another implementation.

Whose users are dependent upon someone else
developing and maintaining the system. Python
and others are free because they come with no
warranty or guarantee of support. All you can
count on is what exists today because nobody is
going to support your older arduino, rpi, pyboard
etc. for free.

[Cecil Bayona]

Its an oven not a soldering iron, which is way more complex, the
temperature must be controlled to a precise profile where there
temperature ramps to different temperatures at a controlled rate so the
parts on the PCB are not stressed due rapid temperature changes. It
required to talk to IO Ports, RS232C, WiFi, I2C, and SPI devices, that
in itself weeded out a lot of the software.

Its a project that over the years I have implemented with various CPUs
and software as a sort of test bench to compare CPUs and software to see
the difficulty in implementing the task and compare the CPUs and
software. The software that has been tried is C, Pascal, Forth, Tcl/Tk,
and Python, the results were that all that software worked fine for
implementing the task, the Python version was simple to implement but
had glitches where the CPU would go away and therefore get a glitch in
the temperature but I only tried Python on one hardware platform which
also had the glitches when running a Forth implementation so the problem
might not be in Python.

Still though it does not take much of a computer to implement a PID
loop, and talk to a PC which was part of my point. You can use an
inexpensive CPU with Forth, with Python it will take a way more
expensive part to run. I have a Forth implementation on a STM8 board
that cost less than $2 from China and it worked well.

On the other side there are some inexpensive $3 boards available that
can run Micro-Python using the esp8266 CPUs, maybe it's a bad software
implementation but that is where I noticed these pauses every so often
that made it not a workable system. The advantage of the esp8266 board
was it had WiFi so no wires to connect to the PC a nice improvement and
maybe the cause of the problem with the unanticipated pauses. I have not
tried Python on an ARM board to see how well it works but I assume it
will do better than the esp8266, Arm boards can be had cheaply, an
inexpensive F411R Nucleo board is $13 and it's fast and has 512KB of
flash and an M4 CPU.

There are points on both sides, with Python and it's vast arrays of
libraries allow a complex task can be done quickly, with Forth some of
the simpler task can be done with rather inexpensive devices. Use
whatever is appropriate to the task.

One more complication, Tcl/Tk worked well on a small ARM board, no
noticeable pauses and it has a rich set of libraries also but it like
Python has much higher demand on resources.

--
Cecil - k5nwa

[minf...@arcor.de]

It is amazing what innovations are happening in the controller world.
F.ex. boards running JS:
https://tessel.hackster.io/

Let the hardware cost 50$. Unless you are producing high volumes of
your devices, reduced development and software engineering costs by far
outweigh the hardware, even if you use only a fraction of the controller
possibilities.

For me it looks like Forth's niche is more and reduced to absolute
minimalistic requirements.

But then of course, one must not neglect that Forth as a programming
language has also other application fields than embedded systems.

[Cecil Bayona]

On 9/15/2017 2:45 PM, minf...@arcor.de wrote:
> Am Freitag, 15. September 2017 18:51:49 UTC+2 schrieb Cecil - k5nwa:

>> Its an oven not a soldering iron, which is way more complex, the
>> temperature must be controlled to a precise profile where there
>> temperature ramps to different temperatures at a controlled rate so the
>> parts on the PCB are not stressed due rapid temperature changes. It
>> required to talk to IO Ports, RS232C, WiFi, I2C, and SPI devices, that
>> in itself weeded out a lot of the software.
>>

True, the cost keeps coming down on the hardware in my case the oven
controller I thinking of maybe selling the product, people who make
their own PCBs are for the most part cost conscious individuals using a
$50 controller makes it a non-viable product, using a $2 or $6
controller makes the project viable and I can then make a profit on the
sale, we are talking small quantities of units sold but it must sell
cheaply otherwise there is no point in bothering with it.

In this case expenses are important but there is more to the story, this
is were personality gets into the picture. There are so many CPUs
available and I would love to work with various CPUs but it's just not
practical so recently I came to the decisions that as nice as various
processors are I can't possibly support them all so I'm limiting myself
to a fewer number of CPUs, MSP430, ARM, and esp8266 CPUs so of the
others are out such as the AVR, PIC, dsPIC families even though they are
quite useful.

Why these three devices, three is still too many but I have my reasons.

The MSP430 simply because that is such a nice CPU, it's a lot of fun to
work with it so it's a personal choice because I really like the CPU. So
this is the fun choice.

The ARM because moderate cost boards ($5 to $50) are available with high
performance. This is the processor that if I limited myself to one CPU
would overall be the best choice in terms of economics versus performance.

The esp8266 because of its low cost while having decent performance,
it's the new kid on the block so the software is raw around the edges,
it has an incredible amount of on-board hardware for peanuts ($2 to $6).

I was force to retire due to health so my income is limited, I can't
afford expensive boards for simple projects as cost is important.
Personally for simple projects smaller CPUs will do just fine and the
cost is low $2 to $6 for perfectly good boards. But for this discussion
or for one of a kind even ARM boards can be acquired for not too much,
my favorite ARM board is the Nucleo F411R it's $13 and loaded with
capabilities including software choices.

--
Cecil - k5nwa

[minf...@arcor.de]

Am Freitag, 15. September 2017 22:22:39 UTC+2 schrieb Cecil - k5nwa:
> I was force to retire due to health so my income is limited, I can't
> afford expensive boards for simple projects as cost is important.
> Personally for simple projects smaller CPUs will do just fine and the
> cost is low $2 to $6 for perfectly good boards. But for this discussion
> or for one of a kind even ARM boards can be acquired for not too much,
> my favorite ARM board is the Nucleo F411R it's $13 and loaded with
> capabilities including software choices.

I wish you all the best! I believe that one cannot make money out of
electronic hardware or software alone. Competition is too high.
Try this and you'll probably end in self-exploitation. Mostly the
surplus values of services or excellent complete products count
(who can have clever interior boards).

There are exceptions like best-selling smartphone apps. But first
you must have the genial idea and then be ultra-fast and business-minded
to market it with profit before it is copied.

At least it is not so easy to reverse-engineer a Forth program. ;-)

[hughag...@gmail.com]

Cecil is right that controlling an oven is more difficult than you might suppose.

A long time ago, before I worked as a programmer, I worked in a bakery. This was a large bakery that made bread to be sold in grocery stores.
The controller either didn't work very well. Moving the temperature too quickly can damage the oven,
plus you over-shoot your mark and then have to adjust in the other direction.
The bakery hired a company to install a micro-controller to control the temperature. That company used a COP8 processor.

I wouldn't want wifi because wifi is flaky. If you lose control for several minutes, a lot of damage can happen.
I would use a small micro-controller (8032, MSP430, etc.) and have a battery back-up for safety.
The control-panel can have an up-arrow and down-arrow for the temperature setting, and a few other keys, plus a small display.
In this case, you are not in communication with a desktop-computer, so you are not saving the log.
The log is mostly used for diagnostics if parts are coming out of the oven messed up and adjustments need to be made.
I would hook up a laptop computer to a serial-line for that purpose.

If you can't afford a control-panel, you can leave your laptop hooked up all the time.
In this case, the micro-controller should ping the laptop computer periodically.
If there is no response, then the laptop may have crashed (Windows!), so the micro-controller should shut down the oven.
Safety is important with an oven --- damage is possible if it gets out of control --- maybe even an explosion.

I would not want the micro-controller to be over-complicated.
A 32-bit processor with an OS and MicroPython written in GCC, and wifi support, has too much opportunity for bugs.
An 8-bit processor programmed in assembly-language or Forth has a much smaller surface area for bugs to land on.

[hughag...@gmail.com]

I think you both know perfectly well that it is an oven, not a soldering-iron.

There is a lot of dishonesty on comp.lang.forth --- you just twist the facts for rhetorical purposes.

[Cecil Bayona]

It's a little more complex than a baking oven as the rate at which
temperature changes must be controlled, the PID controller it's a well
know science so no surprises, but a little STM8 controller board with
8KB of FLASH that cost $2 can do a fine job in Forth. Overshoot of
temperature is not allowed as that could destroy the circuit board one
is trying to solder or the components but that is controlled by the PID
software, it has parameters that are configured to particular oven used,
the parameters can be set in a way to not have temperature overshoots.

< https://en.wikipedia.org/wiki/PID_controller >

The controller does not need the PC at all, it is totally self contained
but a PC can ask it to transfer its status and it will comply via an
RS232 or a WiFi port sending cycle status, heater, and cooling fan
status and a stream of temperature readings for display purposes on the
PCs screen but its an option that is not needed. So there is no danger
at all if the PC dies as the controller is fully self contained, you
would want extra code to detect problems and shutdown the heater in case
of something is wrong. The PC can be used to enter a temperature profile
in the controller of what a baking cycle is to be like but all I have
ever used is one profile as the profile has to do with the solder one is
using and I always use the same solder.

I use it as a gauge to get ideas mostly on the software involved, how
easy it is to create the application and how well it runs. The process
is a lot more complex than the usual blink the LED software so it's
useful in testing a language ability to generate a modestly complex task.

--
Cecil - k5nwa

[Cecil Bayona]

A temperature controlled iron or even a baking oven is a lot simpler
than an PBC soldering oven is, it has a profile of temperature that must
be followed that includes control of the rate of change of the
temperature in both heating and cooling, and several temperature
settings to be reached for set periods of time, the final temperature
excursion after the soak cycle is critical as it must be brief (5
seconds) and the temperature must not overshoot or the components can be
damaged, even the cooling is critical and has to be controlled as too
fast a cooling will cause the solder joints to develop cracks, and
components can be physically damaged by too quick a cooling rate.

My favorite inexpensive oven to modify is the Black and Decker InfraWave
ovens, they are inexpensive, and use a lamp to generate the heat instead
of a heater element as a result they can heat up quickly and cool down
quickly, the controller can then control the actual rates by
proportionally turning the heater on and off, and control the cooling
fan speeds so the cooling rates are controlled.

Below is a URL to a picture of a typical temperature profile while
soldering a PCB board.

< https://en.wikipedia.org/wiki/Reflow_soldering >

--
Cecil - k5nwa

[hughag...@gmail.com]

On Friday, September 15, 2017 at 4:37:22 PM UTC-7, Cecil - k5nwa wrote:
> It's a little more complex than a baking oven as the rate at which
> temperature changes must be controlled, the PID controller it's a well
> know science so no surprises, but a little STM8 controller board with
> 8KB of FLASH that cost $2 can do a fine job in Forth. Overshoot of
> temperature is not allowed as that could destroy the circuit board one
> is trying to solder or the components but that is controlled by the PID
> software, it has parameters that are configured to particular oven used,
> the parameters can be set in a way to not have temperature overshoots.
>
> < https://en.wikipedia.org/wiki/PID_controller >

The baking oven needs a PID controller too. The amount of bread in the oven affects the temperature.
The bread is going through the oven on a conveyor that moves at a constant speed.
It takes time to get the oven fully loaded, and at the end of the day time is required to fully unload the oven.
Also complicating the situation is that the pans sometimes get jammed up where they enter the conveyor and the conveyor has to be temporarily stopped.
Also complicating the situation is that the bread production may get delayed, so you have gaps on the conveyor with no bread.
The oven is quite large, so temperature can vary from one end to the other, mostly depending upon where the bread is.
I would expect this to be more complicated than what you are doing.

I don't really know anything about PID --- I would have to study up on it --- it is a well-known science though, so there is plenty of information.

I would consider this to be something that an 8-bit processor could do.
I wouldn't want a 32-bit processor with an OS etc., as there is too much opportunity for bugs.
So, I'm in favor of minimalism --- an 8-bit processor with no OS rather than a 32-bit processor with Linux and MicroPython.
On the other hand, I'm not in favor of extreme minimalism as advocated by Elizabeth Rather.
It is a waste of time to write everything totally from scratch, and it is error-prone to do cut-and-paste from old programs.
Code-libraries really do make programming a lot easier!

> The controller does not need the PC at all, it is totally self contained
> but a PC can ask it to transfer its status and it will comply via an
> RS232 or a WiFi port sending cycle status, heater, and cooling fan
> status and a stream of temperature readings for display purposes on the
> PCs screen but its an option that is not needed. So there is no danger
> at all if the PC dies as the controller is fully self contained, you
> would want extra code to detect problems and shutdown the heater in case
> of something is wrong. The PC can be used to enter a temperature profile
> in the controller of what a baking cycle is to be like but all I have
> ever used is one profile as the profile has to do with the solder one is
> using and I always use the same solder.

I said you need *either* a control-panel or a laptop hooked up via a serial cable.

A control-panel is the best solution. Using a laptop as a control-panel is somewhat hokey.

The laptop is mostly useful if you want to download a log file from the controller for diagnostic purposes.
This is mostly useful if you also have a log file of the quality of the product coming out of the oven (under-done, good, over-done).

> I use it as a gauge to get ideas mostly on the software involved, how
> easy it is to create the application and how well it runs. The process
> is a lot more complex than the usual blink the LED software so it's
> useful in testing a language ability to generate a modestly complex task.

I agree that blinking an LED is not interesting. Your application is complicated enough to be interesting. Makes for a good test of skill.

Your test is mostly of whether the programmer knows what PID is or not, and I said that I don't know anything about the subject without studying.
I have at least heard of it, so I could figure it out.
Servo-mechanisms were invented during the Middle Ages --- the problem is not new.

I think that anybody who says he needs a 32-bit processor with an OS and MicroPython automatically fails the test.
A non-programmers will often want a lot of heavy support like this, and hope that the problem will solve itself somehow, without him learning what PID is.
Maybe they will find a code-library with a function called ControlOven in it, then write a one-line program to control the oven.

Anybody who says she needs to start out by designing a custom array also fails the test.
Non-programmers always think that programming is a lot more complicated than it actually is, and requires genius-programming and clever customization.
She is trying to stick with something she understands (what an array is) to avoid tackling the actual problem, which involves learning what PID is.
She is hoping that somebody smart will figure out the problem, and then she can take credit for providing an array that is "exactly right for the application."

[Cecil Bayona]

No OS, just a simple CPU with code, Forth, C, or Pascal depending on the
CPU, there is of course more than just a PID controller as a PID
controller just accepts a single task and the soldering profile consist
of several task, ramp up, soak, solder, and cool down but all of those
task are fed to the PID engine one at a time by a state machine that is
controlled by time, and present temperature, it's an interesting subject.

I keep thinking of selling the product as a complete project consisting
of a modified oven, the controller, and interface all ready to go, I
keep thinking that it will be too small a market, and you can buy small
units from china for $250 and higher but if I make a unit it will larger
so one could do several boards at a time and cheaper.

--
Cecil - k5nwa

[hughag...@gmail.com]

On Friday, September 15, 2017 at 6:55:37 PM UTC-7, Cecil - k5nwa wrote:
> No OS, just a simple CPU with code, Forth, C, or Pascal depending on the
> CPU, there is of course more than just a PID controller as a PID
> controller just accepts a single task and the soldering profile consist
> of several task, ramp up, soak, solder, and cool down but all of those
> task are fed to the PID engine one at a time by a state machine that is
> controlled by time, and present temperature, it's an interesting subject.
>
> I keep thinking of selling the product as a complete project consisting
> of a modified oven, the controller, and interface all ready to go, I
> keep thinking that it will be too small a market, and you can buy small
> units from china for $250 and higher but if I make a unit it will larger
> so one could do several boards at a time and cheaper.

For keeping the cost down, I would want to use a single-chip system such as the PIC16 that has all of its memory on-chip.
This would likely mean that you don't get Forth, C, Pascal, or anything else --- you write your program in assembly-language.
Ye olde 8051 is another option --- there are a lot of options for single-chip systems.

You can buy a control-panel for not much. What you are describing is pretty common --- an up-arrow, a down-arrow, a few other keys, and a small display.

I know PIC16 assembly-language, if you need any help with the programming...
If you can build the board with the control-panel and thermometer hooked up, and mail this to me, I can write the code.
I'll test it by holding the thermometer next to a candle --- I don't need to have the whole oven.

I'm dubious that such a thing would be a big money-maker. How are you going to advertise it? That will likely be your biggest expense.
If it does start selling, you will have provided somebody with a proof-of-concept --- they will mass-produce them at a lower cost and take the market.
You might make some money for a while, before anybody notices.
If the market is small, nobody may ever care enough to take the market from you, so you will get a trickle of money that lasts for a long time.

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> Its an oven not a soldering iron, which is way more complex, the
> temperature must be controlled to a precise profile where there
> temperature ramps to different temperatures at a controlled rate so
> the parts on the PCB are not stressed due rapid temperature
> changes. It required to talk to IO Ports, RS232C, WiFi, I2C, and SPI
> devices, that in itself weeded out a lot of the software.

Given the amount of power available, I'd have gone for something like a
beaglebone or raspberry pi, and regular CPython or maybe Erlang. In any
case, I'm still very skeptical that the GC pauses make any difference to
the PID loop, given how long it will take for heat to diffuse through a
big thing like that. It's almost more believable if it's a soldering
iron, where the heating element and thermal sensor are within a few mm
of the tip.

Which STM8 Forth did you use that talks to all those devices?

> The advantage of the esp8266 board was it had WiFi so no wires to
> connect to the PC a nice improvement and maybe the cause of the
> problem with the unanticipated pauses.

Yes, my first guess would be the radio stack pre-empting the user
application. That's why the newer esp32 has two cpu cores: the radio
stuff and the user stuff each get a core to themselves.

[Paul Rubin]

minf...@arcor.de writes:
> F.ex. boards running JS: https://tessel.hackster.io/

Also try espruino.com.

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> I keep thinking of selling the product as a complete project
> consisting of a modified oven, the controller, and interface all ready
> to go, I keep thinking that it will be too small a market, and you can
> buy small units from china for $250 and higher but if I make a unit it
> will larger so one could do several boards at a time and cheaper.

In my town the kids use toaster ovens with the thermostat temp control
that they came with. If you want something more precise, I'd expect the
MCU board to be the main cost. If you use something like a Raspberry Pi
Zero W then it has wifi and bluetooth, can run a web server, and then
you can control it from a web GUI in a phone browser. Hipsters like
that sort of thing.

[Cecil Bayona]

eForth is what I used, I tend to think that it's the wireless software
that is causing the problem. The ep32 is nice I have one but it cost way
more money, eventually it will be cheaper.


--
Cecil - k5nwa

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> MCU board to be the main cost.

Grrr. I'd expect the MCU to NOT be the main cost. It would be almost
insignificant.

The Adafruit M0 Trinket is in stock now and I might order a couple of
them just for the heck of it.

[Cecil Bayona]

The Thermocouple board and sensor is more expensive than the CPU but
there is little choice there. I have used a plain oven with thermostat
control worked fine after a few failed tries but you must give it 100%
of your attention.

--
Cecil - k5nwa

[dxf...@gmail.com]

Do you know of anyone who actually does this?
Or is it something hipsters like to talk about
on forums like this one? Many years ago I bought
some 16F84's and they're still sitting in the
drawer well past their fashion by date.

[Paul Rubin]

dxf...@gmail.com writes:
>> you can control it from a web GUI in a phone browser. Hipsters like
>> that sort of thing.
>
> Do you know of anyone who actually does this?

Who does what? Uses toaster ovens for reflow soldering? Yes, they do
that around here. Runs web servers in little wifi gizmos? Also yes,
that's the whole "internet of shit" movement (twitter.com/internetofshit).
I don't know anyone who runs a reflow toaster oven from a browser,
but it's a natural combination.

[Cecil Bayona]

As I mentioned before there are some Chinese versions that are pretty
small, the one I'm talking about I done one at home with several
different controllers with different CPU chips.

--
Cecil - k5nwa

[minf...@arcor.de]

Am Samstag, 16. September 2017 05:52:40 UTC+2 schrieb Paul Rubin:
> Cecil Bayona <cba...@cbayona.com> writes:
> > Its an oven not a soldering iron, which is way more complex, the
> > temperature must be controlled to a precise profile where there
> > temperature ramps to different temperatures at a controlled rate so
> > the parts on the PCB are not stressed due rapid temperature
> > changes. It required to talk to IO Ports, RS232C, WiFi, I2C, and SPI
> > devices, that in itself weeded out a lot of the software.
>
> Given the amount of power available, I'd have gone for something like a
> beaglebone or raspberry pi, and regular CPython or maybe Erlang. In any
> case, I'm still very skeptical that the GC pauses make any difference to
> the PID loop, given how long it will take for heat to diffuse through a
> big thing like that. It's almost more believable if it's a soldering
> iron, where the heating element and thermal sensor are within a few mm
> of the tip.
>

From a control perspective (fast heater but very slow system reaction)
PID control might not be the best solution (the control deviation takes
too long to get away, and it is integrated on top).

In such situations a small model-based parallel feedforward path makes
wonders for stabilization and control accuracy.

This is very much more important than temporary little gc delays in the controller board.
board.

[Lars Brinkhoff]

Paul Rubin wrote:
> The Adafruit M0 Trinket is in stock now and I might order a couple of
> them just for the heck of it.

Does it have a bootloader like the ATtiny85 Trinket?

I'd actually like a 4K flash M0 board if one exists, but then maybe
there would have to be an external programner.

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
> Does it have a bootloader like the ATtiny85 Trinket?

Yes, I think so, there's some documentation on the site. You have to
jump through a few hoops to rewrite that part of the flash.

> I'd actually like a 4K flash M0 board if one exists, but then maybe
> there would have to be an external programner.

What do you mean 4k flash? There's 256k on the chip. If you mean you
want external flash, try the M0 Metro or Feather Express boards. They
have 256K on the chip, and another 2MB of SPI flash that you can use
like a tiny disk. Neither have any EEPROM but there are other boards
like the Teensy LC (pjrc.com) which do have that, iirc.

[Paul Rubin]

minf...@arcor.de writes:
> In such situations a small model-based parallel feedforward path makes
> wonders for stabilization and control accuracy.

I thought the derivative term in PID took care of that? Also, in the
reflow oven, I'd expect the heater to be relatively slow compared to the
thermal mass being heated.

[minf...@arcor.de]

Difficult to answer with limited information. Heating systems are ususally
controlled with 2-point-controllers for good reason. Linear controllers
like PID tend to swinging when the actuator is much faster than the controlled
system (assuming that the heater is hot within seconds, whereas a typical oven
time constant is in the range of minutes).

BTW the D-part tends to overshooting and thus being out of control range i.o.w.
you are in a non-linear situation with a linear controller; strange things may
happen there. Although probably not with a simple oven. But Cecil said that
it is a more complex beast...

[Cecil Bayona]

The oven uses a infrared lamp instead of a slow conventional heater, the
lamp is quite fast in it's response time.

--
Cecil - k5nwa

[Raimond Dragomir]

For slow systems there is the PI controller (without D).

[minf...@arcor.de]

One option. But you'd want the oven to be hot before the evening. ;-)

[Lars Brinkhoff]

Paul Rubin:
> Lars Brinkhoff:

>> Does it have a bootloader like the ATtiny85 Trinket?

>> I'd actually like a 4K flash M0 board if one exists, but then maybe
>> there would have to be an external programner.
>
> What do you mean 4k flash? There's 256k on the chip. If you mean you
> want external flash

I mean there are versions of the M0 with 4K flash, and I'd like a board
with one of those. I want to go small.

But with just 4K flash, there may not be room for a bootloader plus a
useful application.

[Raimond Dragomir]

The D (derivative) part of the PID is usually hard to calibrate for slow systems, and
tends to be a problem, not a solution. That's why it is usually removed
completely and that is the PI controller.

Temperature is a slow system. There is nothing to do with the controller,
which is way faster. A PI controller will bring hot the owen in as much
time as it (the owen) needs to get hot. It's a power problem, not a contrller
(type) problem.

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
> I mean there are versions of the M0 with 4K flash, and I'd like a board
> with one of those. I want to go small.

Hmm ok, there is an LPC DIP part with 4k, plus those tiny WLCSP parts.

The SAMD21 used in the Trinket comes in a bunch of memory
configurations, and Adafruit used the biggest one, probably because the
cost difference between them is pretty small. There is a version with
32k of flash and 4k of ram, which seems good for a resident Forth. Of
course it might still not be small enough for you. The Trinket PCB
files are downloadable if you want to make your own board, or if you're
handy with SMT rework, maybe you could change the MCU on a Trinket. I
have no idea why the heck you would want to do this, of course.

If you really want to go small, why not an ATTiny board? There are some
even smaller than the ATTiny85.

[Lars Brinkhoff]

Paul Rubin writes:

> Lars Brinkhoff writes:
>> I mean there are versions of the M0 with 4K flash, and I'd like a
>> board
>> with one of those. I want to go small.

> If you really want to go small, why not an ATTiny board? There are
> some
> even smaller than the ATTiny85.

I have a board with an ATtiny13A, so I'm quite happy in the AVR
department.

But for Cortex-M testing, I'll probably have to settle for a Nucleo
board with a 32K part.

[Paul Rubin]

Lars Brinkhoff <lars...@nocrew.org> writes:
> But for Cortex-M testing, I'll probably have to settle for a Nucleo
> board with a 32K part.

Try this:

http://www.mouser.com/search/ProductDetail.aspx?R=LPC810M021FN8FP

[Lars Brinkhoff]

Paul Rubin wrote:
>> But for Cortex-M testing, I'll probably have to settle for a Nucleo
>> board with a 32K part.

Eeep, I mean 16K.

> Try this:
> http://www.mouser.com/search/ProductDetail.aspx?R=LPC810M021FN8FP

Right, that's what I'd like, only soldered onto a board and programmable
through USB. And a LED on there.

There are breakout boards on eBay, but they're not a complete solution.

The Nucleo looks like an ok compromise.

[Terry Porter]

On Thu, 14 Sep 2017 00:02:16 -0700, Mark Wills wrote:

snip
> The innovation that is taking place around the orbit of Python is
> frankly staggering.
>
> And all the software is free.
>
> What has Forth done lately?
>
snip

This is a bit of a rant I suppose. It's not directed at Mark Willis who
seems a sensible, level headed poster to me. I've followed up with Mark
because he put his pro Micropython opinion clearly, and he asked "What
has Forth done lately?"

That depends on where you are I suppose ?

(Note, I only do embedded with Forth, on the PC I program in Perl, and
I'd never be interested in Perl on a Microcontroller.)

In my world, Forth doesn't stand still, it's the smoothest and easiest
development environment I've ever had, and as electronics tech, who reads
chip specs for fun and entertainment, Forth is exactly what I want.

Here is a one example:-

While I'm developing with Mecrisp-Stellaris Forth (by Matthias Koch) on
STM32F051 ARM I can examine the hardware in real time, by entering a Word
such as "RCC_AHBENR." on my serial terminal connected to the device.

There is no delay, no compile, no upload, no 'drag and drop', it's
instant to a Human like me, and this is what I see :-

RCC_AHBENR. <enter>

RCC_AHBENR (read-write) $005E0000
I I I I I F
T O O O O O L S
S P P P P P C I R D
C E D C B A R T A M
E E E E E E C F M A
N N N N N N E E E E
|2| |2| |2|1|1|1| N N N N
~|~|~|~|~|~|~|4|~|2|~|0|9|8|7|~|~|~|~|~|~|~|~|~|~|6|~|4|~|2|~|0
0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

If I entered "RCC." I'd get a list of every register in the RCC, in the
same format as above.

or this to see what MODE's the GPIOA bits are set to:-

GPIOA_MODER. <enter>

GPIOA_MODER (read-write) $28280000
15|14|13|12|11|10|09|08|07|06|05|04|03|02|01|00
00 10 10 00 00 10 10 00 00 00 00 00 00 00 00 00

or this to read the GPIOA bit logic states:-

GPIOA_IDR. <enter>

GPIOA_IDR (read-only) $0000BFFA
1|1|1|1|1|1|
5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
1 0 1 1 1 1 1 1 1 1 1 1 1 0 1 0

Where I haven't yet made a custom legend like RCC_AHBENR. I get a default
template legend like GPIOA_MODER and GPIOA_IDR above.

This is the kind of design environment I love, it's fast, realtime and
endlessly adaptable by me. It's Forth.

I can generate every memory mapped register for any STM32F automagically
with only a CMSIS-SVD file using svd2forth.
http://128.199.141.78/register-generator.html#svd2forth

I've put in as much time looking at Micropython as I suspect the
Micropython fans have put into looking at Forth, and frankly, I can't see
what all the Micropython fuss is about.

I've been doing embedded since 1976 (National PACE 16 bit CPU and
Teletype with paper punch) and I look into every new thing in embedded
out of interest.

In fact I'm not attracted to Micropython at all.

To me, Micropython is a massive application, complex, slow, unfinished
and unwieldy.
In no way is Micropython even *remotely* similar to Forth for embedded
development, in my opinion.

I can run Mecrisp-Stellaris on my STM32F051's with one external
component, a power supply decoupling filter capacitor. No extra support
components are needed apart from a pcb. It overclocks to 96 Mhz and
above, and it cost $0.56 USD in a 32 pin QFN at a one off price a few
years ago.

The STM32F051 peripherals include 5-channel DMA controller, One 12-bit,
1.0 µs ADC, One 12-bit DAC channel,Two fast low-power analog comparators,
Up to 18 capacitive sensing channels, Up to 11 timers,Calendar RTC,two
I2C interfaces,two USARTs, two SPIs,CRC calculation unit,Serial wire
debug. All for $0.56.

I get 27 I/O pins on this 32 Pin QFN package that measures 5x5x1.2 mm,
and about 6 of them fit on my thumbnail.

I don't need a Lopy with wifi, 512K RAM, and 4MB of flash for $60 AUD
to make a cat5e tester, or a 24v lead acid battery charge meter.

If I need Ethernet, Wifi, or camera support etc, I'll just use a RPi or
better.

Oh, one more thing, I'm not interested in all the Python libraries or
being able to 'build' things in a day with Micropython. If I can build it
in a day with Micropython, so can my competitors.

I've spent the last couple of years learning about STM32F, reading specs,
testing the peripherals, understanding the hardware, making every mistake
at least twice.
I've written lots of Forth programs using only the datasheets for
information, (but svd2forth helped that process a lot by providing all
the register and bitfield words I needed).
When things didn't work I used Assert Words to make sure that registers
actually did contain the values I wanted and in this way I gained a
decent understanding of the STM32F peripherals I have used.
I figure that in another 5 years I may be minimally competent with Forth
and STM32F0.

Try doing that in a day.

If you don't think that's massive fun, educational, and hones a sharp
problem solving edge, then perhaps Micropython *is* for you ;-)



--
Mecrisp-Stellaris Unofficial User Doc: http://128.199.141.78/index.html

[hughag...@gmail.com]

On Tuesday, September 19, 2017 at 5:14:27 PM UTC-7, Terry Porter wrote:
> I can examine the hardware in real time, by entering a Word
> such as "RCC_AHBENR." on my serial terminal connected to the device.
>
> There is no delay, no compile, no upload, no 'drag and drop', it's

> instant to a Human like me...

>
> This is the kind of design environment I love, it's fast, realtime and
> endlessly adaptable by me. It's Forth.

This has always been Forth's primary advantage in the micro-controller world.
The spec sheets for the hardware are usually not accurate. The programmer has to figure out what the hardware does by experimentation.

In many cases, C's generated code is faster than Forth's generated code.
Getting a program to work is the first problem though, and the most difficult problem.
The speed of the generated code is usually not a big issue, especially on modern processors that are 10* faster than what we had 20 years ago.

I agree that MicroPython is a terrible idea --- I wouldn't use it.

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
> I've put in as much time looking at Micropython as I suspect the
> Micropython fans have put into looking at Forth, and frankly, I can't
> see what all the Micropython fuss is about.

I suspect most Micropython fans have never heard of Forth. Have you
tried Python or Micropython at all? Maybe on your PC if not embedded.

You can try an embedded version here: http://micropython.org/live/

There's an MCU board running a small servo and actuator circuit, with a
live webcam pointed at the hardware. You can type Micropython commands
to make the stuff move around, and watch the movements on the live video
stream.

> There is no delay, no compile, no upload, no 'drag and drop', it's
> instant to a Human like me, and this is what I see :-

Python also has that interactivity, of course.

> I can run Mecrisp-Stellaris on my STM32F051's

You should be also able to run Micropython on that series, at least on
the bigger models. The data sheet even says "Its 256Kbytes on-chip
Flash memory and 32 Kbytes SRAM allow Java stack implementation", heh.

> All for $0.56.

You probably need around a $2 part for micropython these days. How many
units of your thing will you have to ship for the difference to matter,
and outwdigh a difference in development productivity in either
direction? Are you going to actually ship that many?

> If I can build it in a day with Micropython, so can my competitors.

The situation to watch out for is that you can do it in a week with
Forth while your competitors can do it in a day with Micropython.

> I figure that in another 5 years I may be minimally competent with Forth
> and STM32F0. Try doing that in a day.

I'm not a hardware guy and I'm squicked by the concept of spending 5
years learning the ins and outs of one piece of hardware. I'd rather
just buy a small board (Trinket M0 is my current interest), connect my
stuff up to it, and write the code. Closer to a weekend than 5 years, I
hope.

[Lars Brinkhoff]

Terry Porter wrote:
> In my world, Forth doesn't stand still, it's the smoothest and easiest

> development environment I've ever had, and as electronics tech [...]

That's the thing. Forth seems to appeal more to electrical engineers
than typical software developers. Maybe hardware design requires a
different mindset more in line with Forth, or maybe the software
engineering curriculum has warped the minds of young programmers.

[minf...@arcor.de]

My observation too. Forth can be honed to being the master tool for masters
of direct board engineering. But how many masters do you have in your team?
What happens when the master(s) retire or leave the company?

It's way easier to find new "adepts" for mPython or such.

BTW like Forth, mPython runs on the bare metal without an OS inbetween.
I read somewhere that there are also Lua-enabled boards, prominently Arduinos.

[Terry Porter]

On Wed, 20 Sep 2017 01:56:34 -0700, minforth wrote:

> Am Mittwoch, 20. September 2017 08:34:12 UTC+2 schrieb Lars Brinkhoff:
>> Terry Porter wrote:
>> > In my world, Forth doesn't stand still, it's the smoothest and
>> > easiest development environment I've ever had, and as electronics
>> > tech [...]
>>
>> That's the thing. Forth seems to appeal more to electrical engineers
>> than typical software developers. Maybe hardware design requires a
>> different mindset more in line with Forth, or maybe the software
>> engineering curriculum has warped the minds of young programmers.
>
> My observation too. Forth can be honed to being the master tool for
> masters of direct board engineering. But how many masters do you have in
> your team? What happens when the master(s) retire or leave the company?

What happens when companies with no 'masters of direct board engineering'
run out of other peoples designs to copy and actually need to produce
something original ?

>
> It's way easier to find new "adepts" for mPython or such.

I'm sure it is, but as they say ... 'easy start ... hard finish' ;-)

>
> BTW like Forth, mPython runs on the bare metal without an OS inbetween.

So did Dartmouth Basic :)

> I read somewhere that there are also Lua-enabled boards, prominently
> Arduinos.

There are all kind of languages running on embedded these days. I
recently tried Armpit_Scheme-070 on a STM32F4 Discovery, and while it
looked great, it wouldnt run properly.

Im a Perl user, and when I move from Perl, it will be to Lisp, I'm not
stopping over in Lua or Python land on the way there.

[Terry Porter]

On Tue, 19 Sep 2017 21:49:34 -0700, Paul Rubin wrote:

> Terry Porter <te...@tjporter.com.au> writes:
>> I've put in as much time looking at Micropython as I suspect the
>> Micropython fans have put into looking at Forth, and frankly, I can't
>> see what all the Micropython fuss is about.
>
> I suspect most Micropython fans have never heard of Forth. Have you
> tried Python or Micropython at all?

I looked into it, but there are no binary images, only a dfu bootloader
file that requires a hardware mod to the board before it can be uploaded.

https://micropython.org/download ..............
Firmware for other boards
These boards are not officially supported but should be fully functional:
STM32F4 Discovery board : stm32f4disc-20170526-v1.9.dfu
...................

Frankly this is a ancient method as all Discovery boards use their
onboard SWD for flashing and it's done in 5 seconds with swdutils, no
hardware mods are needed.

If Micropython had a binary image I could find for a STM32F4, I'd have
flashed and tried it long ago.

>> There is no delay, no compile, no upload, no 'drag and drop', it's
>> instant to a Human like me, and this is what I see :-
>
> Python also has that interactivity, of course.

No it doesn't, you snipped the part where I said this MCU has 64K of
flash, and 8K of ram but Micropython wants 4x the Flash and 2x the Ram to
even install. Micropython can't run at all on my MCU.

> You should be also able to run Micropython on that series, at least on
> the bigger models.

No, the maximum Flash on the STM32F051 series is 64KB.

>> All for $0.56.
>
> You probably need around a $2 part for micropython these days. How many
> units of your thing will you have to ship for the difference to matter,
> and outwdigh a difference in development productivity in either
> direction? Are you going to actually ship that many?

I'm already as productive as I need to be with Forth, you're advocating
Micropython to solve a problem I don't have, using a programming language
I don't need.

>
>> If I can build it in a day with Micropython, so can my competitors.
>
> The situation to watch out for is that you can do it in a week with
> Forth while your competitors can do it in a day with Micropython.

I think cost of production and number of units sold along with time to
market, is of greater importance. Why do you assume that Micropython can
do what I need ?

>
>> I figure that in another 5 years I may be minimally competent with
>> Forth and STM32F0. Try doing that in a day.
>
> I'm not a hardware guy and I'm squicked by the concept of spending 5
> years learning the ins and outs of one piece of hardware. I'd rather
> just buy a small board (Trinket M0 is my current interest), connect my
> stuff up to it, and write the code. Closer to a weekend than 5 years, I
> hope.

The Trinket has 5 gpio pins available and uses the ATSAMD21E18 which
looks like a great chip to me.

The really excellent thing about the ATSAMD21E series is that they have a
decent looking SVD. https://github.com/avrxml/svd
This means that I can probably generate all the register and bitfield
Words for Mecrisp-Stellaris for it.

The ATSAMD21E16 is a 32 bit ARM Cortex M0, costing ($2.95 USD from
Mouser.com) for the 32 pin, 64K flash QFN package and is similar to my
STM32F051 in 32 pin QFN ($3.55 USD each from Mouser.com).

M

[Lars Brinkhoff]

minf...@arcor.de writes:
>> Forth seems to appeal more to electrical engineers than typical
>> software developers.
>

> My observation too. Forth can be honed to being the master tool for
> masters of direct board engineering. But how many masters do you have
> in your team? What happens when the master(s) retire or leave the
> company?

You don't need to be a master to use Forth, but it certainly helps to
have a mentor.

I think any programmer worth his or her salt should be able to learn
Forth. If they can't, they're not very good. But perhaps it's more
likely they don't want to learn something that looks unfamiliar.

[Andrew Haley]

minf...@arcor.de wrote:
> Am Mittwoch, 20. September 2017 08:34:12 UTC+2 schrieb Lars Brinkhoff:
>> Terry Porter wrote:
>> > In my world, Forth doesn't stand still, it's the smoothest and easiest
>> > development environment I've ever had, and as electronics tech [...]
>>
>> That's the thing. Forth seems to appeal more to electrical engineers
>> than typical software developers. Maybe hardware design requires a
>> different mindset more in line with Forth, or maybe the software
>> engineering curriculum has warped the minds of young programmers.
>
> My observation too. Forth can be honed to being the master tool for
> masters of direct board engineering. But how many masters do you
> have in your team? What happens when the master(s) retire or leave
> the company?

Embedded systems are too important to be left to off-the-shelf Python
programmers. There are important safety and security aspects, as we
have discovered from recent IOT disasters. Dijkstra was on the money:

Don't blame me for the fact that competent programming, as I view it
as an intellectual possibility, will be too difficult for "the
average programmer" -- you must not fall into the trap of rejecting
a surgical technique because it is beyond the capabilities of the
barber in his shop around the corner.

Beyond that, given that skilled professionals are needed, there's the
question of whether a skilled professional will be comfortable with
Forth. I'll not deny that some never will, and of course that might
be a problem.

Andrew.

[minf...@arcor.de]

I don't object and I am neither selling Python nor kicking Forth into the dust.
But if you had products spread around the globe and have to hire service
engineers say in Kazakhstan f.ex., you better keep their entry level low.

90% of this thread is turning around hobbyists and one-man-shows.

[Raimond Dragomir]

> I don't object and I am neither selling Python nor kicking Forth into the dust.
> But if you had products spread around the globe and have to hire service
> engineers say in Kazakhstan f.ex., you better keep their entry level low.
>
> 90% of this thread is turning around hobbyists and one-man-shows.

Did you really expect something else?

[Terry Porter]

How many programmers know enough about electronics to understand a MCU
technical pdf ?

Perhaps the lack of electronics experience drives them to seek out
languages that hide all the technical stuff under a comfortable layer of
abstraction ?

Or perhaps all the new and hot popular languages such as uPython offer
promises that are too hard to resist ?

By the way Lars, I found your 'forth-mode' very interesting, I'd love to
be able to use it with Mecrisp-Stellaris on something like a STM32
Discovery board.

[Terry Porter]

I imagine a product where the service engineer in Kazakhstan only needs a
elcheapo 'three flying geese' android tablet to connect to the non
working product via a terminal and break into the Forth diagnostics Words
that you so thoughtfully designed into your egg sorting machine.

From there he can discover that the dust blowing from in from Southern
Kazakhstan has got in to the bearings of the cheap stepper motor you used
in the product when he runs 'stepper-test'. Now he can dismanltle the
motor, clean the bearings and regrease them with Yak fat.

Done.

>
> 90% of this thread is turning around hobbyists and one-man-shows.

Didn't you just describe Forth ?

[Mark Wills]

On Wednesday, 20 September 2017 11:30:21 UTC+1, Terry Porter wrote:

> I'm already as productive as I need to be with Forth, you're advocating
> Micropython to solve a problem I don't have, using a programming language
> I don't need.
>

Forgive me, but are you?

From what you've posted above, you are using Forth to explore a particular
processor, and that's absolutely fine. But what are you doing with the
hardware? What applications are you writing?

I am only interested in making money. I've been self employed since about
2000, so I tend to think in terms of what is going to continue to feed
my family! Further more, if I can do something fast, that means I can
bill the customer quicker, and potentially get more work from him, or
move onto the next job.

In microPython, I can interface to a GPS unit over a serial port,
a GPRS modem over another serial port, and implement a vehicle tracking
system in a day.

I can't do that in Forth.

In Forth, there's way to open a serial port.

Again, it's *not* the language, it's the software or libraries that are
available to the programmer in that language. For the Forth programmer,
the number of libraries that is available is practically zero. There's
a few, like various flavours of object libraries etc, but if I want to
query an SQL database, or FTP a file onto a server, or grab a HTTP page,
or open a serial port, or send TCP or UDP packet, then forget it.

There's no software libraries for Forth, because it needs a platform
upon which to gain some traction, then it would give people a platform
around which to coalesce. Unfortunately that hasn't happened.

I too have been having some fun with Forth in embedded environments.
I've been using FlashForth on the ATMEGA328P and have been very impressed
indeed. That particular platform does have some FlashForth libraries
that you can use, for I2C etc. I developed a driver for the Hitachi
LCD units, which was fun, but I'd rather not have to do it myself.
Consider, on the Arduino (same processor) in C I just type:

<#include wire.h>
<#include lcd.h>

void setup() {
LCD lcd();
lcd.clearScreen();
lcd.setCursor(0,3);
lcd.print("Hello Mother!");
}

When we can get to that point on an embedded hardware platform, we'll
have something to shout about.

Until then, all we have is an absolutely *incredible* mind-blowingly
good programming language - Forth; but no eco-system to do anything
with.

And that's very unfortunate.

[Lars Brinkhoff]

Terry Porter wrote:
>> I think any programmer worth his or her salt should be able to learn
>> Forth. If they can't, they're not very good. But perhaps it's more
>> likely they don't want to learn something that looks unfamiliar.
>
> How many programmers know enough about electronics to understand a MCU
> technical pdf ?

I don't think you need that to learn Forth.

But around here, I think most good programmers would understand MCU
datasheets and manuals. Granted, I don't now how they teach software
development elsewhere.

> By the way Lars, I found your 'forth-mode' very interesting, I'd love
> to be able to use it with Mecrisp-Stellaris on something like a STM32
> Discovery board.

Great, I hope you find it useful!

[minf...@arcor.de]

Not really, I asked for opinions. There are still some few really smart people
with a wealth of lifelong professional experience here in c.l.f. whose views
are worth while listening.

C.l.f. has become only a shadow of its past. Luckily in my age I am above
feeling galled at some uncivilized utterings of some uneducated participants
here. And chapeau to the inventor of killfiles. ;-)

[dxf...@gmail.com]

The past is often seen better than it was :)
I recall J. Wavrik complaining at the
uneducated responses he received from ANS-TC
and c.l.f alike after giving advice similar to
that of other mathematicians.

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
> Perhaps the lack of electronics experience drives them to seek out
> languages that hide all the technical stuff under a comfortable layer of
> abstraction ?

I'd hope Forth also puts the messy stuff under comfortable abstractions.
Why would anyone not want to do that?

> Or perhaps all the new and hot popular languages such as uPython offer
> promises that are too hard to resist ?

uPython is just a Python implementation that happens to be written for
small size. There are many Python implementations just as there are
many Forth implementations. Python has been around since the 1990s so I
wouldn't call it "new" any longer. I've been using it since the 2000s
and am pretty familiar with its strengths and limitations. So I think I
can appreciate uPython without being taken in by unrealistic promises
about it.

I can't speak for others but for most of the Python code that I write,
above some moderate amount of complexity, I could not get done in Forth
or even C in any reasonable amount of time. But, it might be reasonable
to say that those are also not realistic MCU applications.

You might like Hedgehog Lisp if you want to program MCU's in Lisp:

https://github.com/sbp/hedgehog

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
> If Micropython had a binary image I could find for a STM32F4, I'd have
> flashed and tried it long ago.

Hmm, I haven't looked into it but I thought there were downloads
for most of the popular boards including the STM Discovery.

> No it doesn't, you snipped the part where I said this MCU has 64K of
> flash, and 8K of ram but Micropython wants 4x the Flash and 2x the Ram
> to even install. Micropython can't run at all on my MCU.

I don't think it strictly needs 4x the flash. I can believe 2x,
depending on what you're doing with it.

> No, the maximum Flash on the STM32F051 series is 64KB.

I see, though there are larger parts in the STM320x1 series, up to 256k.

> I think cost of production and number of units sold along with time to
> market, is of greater importance. Why do you assume that Micropython
> can do what I need ?

I don't know what you need and am not presuming. I know that a lot of
embedded developers don't care much about BOM cost per unit since
they're making small quantities and NRE dominates the project cost. I'm
also persuaded that Python can get a lot of ideas to market faster, if
you don't mind the larger hardware demands. Whether those are things
you work on, I have no idea.

Someone quoted Dijkstra, who also said (Turing award lecture, 1972):

"With a few very basic principles at its foundation, it [LISP] has
shown a remarkable stability. Besides that, LISP has been the carrier
for a considerable number of in a sense our most sophisticated
computer applications. LISP has jokingly been described as “the most
intelligent way to misuse a computer”. I think that description a
great compliment because it transmits the full flavour of liberation:
it has assisted a number of our most gifted fellow humans in thinking
previously impossible thoughts."

I've written a lot of Python and a reasonable amount of Lisp, and I
think it's reasonable to say they have a comparable feel. See:

https://norvig.com/python-lisp.html

> The Trinket has 5 gpio pins available and uses the ATSAMD21E18 which
> looks like a great chip to me.

Note there's an ATSAMD51 on the way, which has a Cortex M4 core and
is also affordable:

https://www.adafruit.com/product/3382

> The really excellent thing about the ATSAMD21E series is that they
> have a decent looking SVD.

What is that? It looks like a big XML file describing the pinout etc.

[Terry Porter]

On Thu, 21 Sep 2017 00:19:11 -0700, Paul Rubin wrote:

> Terry Porter <te...@tjporter.com.au> writes:

snip

>> The really excellent thing about the ATSAMD21E series is that they have
>> a decent looking SVD.
>
> What is that? It looks like a big XML file describing the pinout etc.

It's a System View Descrption file. C compiler creators use them to
generate headers for their packages etc.

I use them to generate Forth memory mapped words, Forth Register Bitfield
Words and assembler equate files.

See: http://128.199.141.78/register-generator.html#svd2forth and
http://128.199.141.78/svd2gas.html

It's a excellent resource as modern MCU's have literally hundreds of
registers and thousands of bitfields.

SVD's taught me to appreciate XML.

[Terry Porter]

On Thu, 21 Sep 2017 00:01:31 -0700, Paul Rubin wrote:

> Terry Porter <te...@tjporter.com.au> writes:
>> Perhaps the lack of electronics experience drives them to seek out
>> languages that hide all the technical stuff under a comfortable layer
>> of abstraction ?
>
> I'd hope Forth also puts the messy stuff under comfortable abstractions.

No it doesn't. I can easily do that tho, it's my choice.

> Why would anyone not want to do that?

I'm a electronics technician, I love the hardware and all the technical
stuff.

You're a programmer and find the stuff I love, messy, which is cool, we
just have a love for different disciplines.

snip

> I can't speak for others but for most of the Python code that I write,
> above some moderate amount of complexity, I could not get done in Forth
> or even C in any reasonable amount of time. But, it might be reasonable
> to say that those are also not realistic MCU applications.

To me, all applications are different, different hardware, different
pinouts, different pcb's, different problems.

I guess I love the challenge of problem solving, and my mind loves the
way that Forth enables my mental processes in this regard.

Time isn't a factor for me, I can't put a time on solving a problem I've
never solved before. I design stuff that you won't get any Google hits on.

>
> You might like Hedgehog Lisp if you want to program MCU's in Lisp:
>
> https://github.com/sbp/hedgehog

Thanks for the link, it looks interesting but dead the last 4 years.

[Julian Fondren]

Dead and abandoned. I was interested in it the moment it was announced
-- on reddit, so this must have been more than six years ago -- and
went through some exercises with it, including some tests of its odd
multitasking features and a run through of Crenshaw's "let's build a
compiler". I reported some bugs within a week to the company behind it
and the response I got back was "yeah the guy who built that is more
interested in working on an ML-like replacement for it."

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
> my STM32F051... Overclocks to 96 Mhz and above, and it cost $0.56 USD

> in a 32 pin QFN at a one off price a few years ago.

FWIW, the cheapest STM32F051 that I see on digikey.com in qty 1 is the
STM32F051K4U6 (16k flash) and it costs $2.33 in single qty, $1.144 in
qty 1000. On the other hand, you can get STM8's in the 50 cent range
(8k flash, 1k ram) which is very impressive. Supposedly a stripped down
STM8 eForth uses around 5k of the flash, which leaves enough for a
reasonable user program.

[Terry Porter]

On Sat, 23 Sep 2017 01:58:26 -0700, Paul Rubin wrote:

> Terry Porter <te...@tjporter.com.au> writes:
>> my STM32F051... Overclocks to 96 Mhz and above, and it cost $0.56 USD
>> in a 32 pin QFN at a one off price a few years ago.
>
> FWIW, the cheapest STM32F051 that I see on digikey.com in qty 1 is the
> STM32F051K4U6 (16k flash) and it costs $2.33 in single qty, $1.144 in
> qty 1000.

The price has gone up. Mouser.com sell the same chip I use (STM32F051K8)
at $3.55 each USD.

> On the other hand, you can get STM8's in the 50 cent range
> (8k flash, 1k ram) which is very impressive. Supposedly a stripped down
> STM8 eForth uses around 5k of the flash, which leaves enough for a
> reasonable user program.

By all accounts, the STM8 is a excellent chip and still very popular, but
I'm a STM32F user now and I'm not throwing away my 5 years experience
with that brand. Besides I bought 500 units of my chip, and they have
64KB flash :)

[Lars Brinkhoff]

Paul Rubin writes:
> Supposedly a stripped down STM8 eForth uses around 5k of the flash,
> which leaves enough for a reasonable user program.

Thomas' stm8ef takes 5k for the full Forth. And 3.5k for a stripped
down version. Even less if you sacrify the interpreter.

[Liang Ng]

Referring to my work 5GL / Fifth Generation Graph Language, I suppose the greatest strength in Forth does not lie in "comparing" it to other "high level" languages, but as an "intermediary script language", which clear has tremendous application in a world where too many too complicated programming languages have been invented, and continue to be.

I came across Forth when I was looking for a programming language that works best on a mobile phone, with a limited display area. I did not want punctuations.

I only wanted that a language that allows me to modify a web page, like JavaScript but with a simpler syntax. I was checking out Lisp before finding Forth.

To cut the long story short, I implemented a script processor in both JavaScript and PHP, that takes a list of arguments with the function name at the end, suffixed with colon, e.g. 1 2 plus:

I use the colon suffix as I did not have time to look at Forth parser, and I could process the list with colon and space separated string functions easily in JavaScript and PHP.

Next, I discovered that I can store the output of each "function" ("words" in Forth) as a json object with the function name as index. With this, I can have a stack machine, or in fact, randomly accessing all results in the json array, which I call JSIOM (Json Input Output Memory).

I have since moved on to write a thin wrapper for three.js, a WebGL library, to make OpenGL programming as simple as the old Logo programming, using a Forth like syntax.

Through this exercise, I believe a language with Forth like syntax can be used as a intermediary script to translate any existing programming language.

The long term benefit of this would be, of course, to provide an attractive avenues for younger programmers to learn Forth, starting with 2D and 3D web applications.

The next phase of 5GL / Fifth will be to develop Forth drivers, interfacing with high level Fifth code. This would be in huge demand as we can implement both high level (Fifth) and low level code (Forth) for 3D applications using languages of the same syntax -- in fact, the same language BY DEFINITION.

Reference: 5gws.epizy.com

[Cecil Bayona]

4K for a Direct Threaded eForth on the STM8 with about 180 words.

--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> 4K for a Direct Threaded eForth on the STM8 with about 180 words.

I stand corrected and that's really cool (thanks also to Lars). I
wonder why the STM8 is not more popular.

[Cecil Bayona]

The can be had pretty cheap that is why I tried it some time back. Here
is a board for less than $1 with free shipping.

<
https://www.aliexpress.com/item/STM8S103F3P6-system-board-STM8S-STM8-development-board-minimum-core-board/32425140241.html?spm=2114.search0104.3.17.M6YysF&aff_platform=aaf&cpt=1506204943114&sk=zj6qB6AIM&aff_trace_key=b73f0a43ebab40de8748333b5cfa1d45-1506204943114-06325-zj6qB6AIM&terminal_id=02f99b00d37b49f6a463d946121bb447
>

There is a board that I can't presently find the link, a STM8 board,
with several LED, push buttons, 3 7 segment LEDs, a relay, and a serial
port for less than $2

--
Cecil - k5nwa

[Paul Rubin]

Cecil Bayona <cba...@cbayona.com> writes:
> https://www.aliexpress.com/item//32425140241.html

Yes I do remember seeing that, in connection with the STM8 eForth. Does
the eForth speak directly to the USB port, so you can connect to it with
a terminal emulator program and type stuff? Otherwise using a
usb-to-serial cable is ok I guess. The chip doesn't have USB but I know
for the ATTiny85 they simulate it by bit banging.

> There is a board that I can't presently find the link, a STM8 board,
> with several LED, push buttons, 3 7 segment LEDs, a relay, and a
> serial port for less than $2

See here, there are a bunch of those board descriptions that can be
searched for on AliExpress:

https://github.com/TG9541/stm8ef

I might order a few for fun and I'd consider using them if I wanted to
do something completely on the cheap. But right now I'm not trying to
build anything in any volume, so using Trinkets is not a problem, and
they're much more convenient.

Wow: STM8S001J3M3 (8k flash, 1k ram, 128b eeprom and it looks like
there's a built-in uart?) is 68 cents in singles, 29 cents in 1k, in a
SOIC-8. That makes Forth a possibility in various small cheap gadgets.
Too bad none of the higher capacity parts are available in such small
packages.

[hughag...@gmail.com]

On Friday, September 15, 2017 at 4:37:22 PM UTC-7, Cecil - k5nwa wrote:
> On 9/15/2017 5:37 PM, hughag...@gmail.com wrote:
> > Cecil is right that controlling an oven is more difficult than you might suppose.
> >
> > A long time ago, before I worked as a programmer, I worked in a bakery. This was a large bakery that made bread to be sold in grocery stores.
> > The controller either didn't work very well. Moving the temperature too quickly can damage the oven,
> > plus you over-shoot your mark and then have to adjust in the other direction.
> > The bakery hired a company to install a micro-controller to control the temperature. That company used a COP8 processor.
>
> It's a little more complex than a baking oven as the rate at which
> temperature changes must be controlled, the PID controller it's a well
> know science so no surprises, but a little STM8 controller board with
> 8KB of FLASH that cost $2 can do a fine job in Forth. Overshoot of
> temperature is not allowed as that could destroy the circuit board one
> is trying to solder or the components but that is controlled by the PID
> software, it has parameters that are configured to particular oven used,
> the parameters can be set in a way to not have temperature overshoots.

When I said there could be over-shoot, I was referring to a baking oven that uses natural-gas --- your PID controller doesn't "allow" this to happen ---
but it may happen anyway because of various real-world parameters that you aren't taking account of.
The PID algorithm assumes a smooth and predictable acceleration and deceleration, but that isn't how the real-world works. ;-)

I've been reading up on PID a little bit. Is it true that this only needs addition and multiplication, but not division?
I want to support PID on my processor, but I don't want a DIV instruction unless it is needed.

[Lars Brinkhoff]

Paul Rubin writes:
> Does the eForth speak directly to the USB port, so you can connect to
> it with a terminal emulator program and type stuff?

I don't think the eForth console is available through USB.

> Otherwise using a usb-to-serial cable is ok I guess. The chip doesn't
> have USB but I know for the ATTiny85 they simulate it by bit banging.

The stm8ef README.md mentions 2- and 3-wire communication through an
UART, and 2-wire communication through the SWIM debug interface.

[Terry Porter]

Probably a similar reason to why the Z80 isn't more popular in PC's ;-)

The STM8 has obviously *been* very popular, but I can think of a few
reasons why it's not more popular *now* :- 9 years old, 8 bit, 16Mhz,
limited Flash, 130nM tech, 10 bit ADC, no DAC.

Nevertheless, Thomas' stm8ef Forth looks really nice, and I like the STM8
ISA. If I was interested in 8 bits, which I'm not, I would want to use
the STM8 and stm8ef.

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
>> wonder why the STM8 is not more popular.
> Probably a similar reason to why the Z80 isn't more popular in PC's ;-)

Well, I mean popular compared with the AVR which is much more expensive
for what you get. And I don't think there's an AVR or much of anything
else with comparable features in a SOIC-8.

> Nevertheless, Thomas' stm8ef Forth looks really nice, and I like the STM8
> ISA. If I was interested in 8 bits, which I'm not, I would want to use
> the STM8 and stm8ef.

I ordered a few of those 60 cent boards just for laughs. The order went
through but then AliExpress blocked me so I can't order anything else
from them without jumping through hoops that I'm unwilling to, oh well.
I also ordered a STM32F103C8T6 board (64k flash, 20k ram) for around
$1.50 and a few other things, and a $1.30(?) STM8 board with 16k flash
and 2k ram. No idea what to do with any of them but the whole bunch was
around $10 USD, so whatever.

I really like the Gemma M0 (same as Trinket except circular board) now
that I've tried it. You plug it in and it simulates a USB flash drive
and serial console at the same time, so you can drag and drop files to
it, and at the same time you have a Python REPL you can interact with.
When you drag a file called "main.py" to it, the code in it runs
automatically, and it also runs that file when you reset. It's
ridiculously easy. That's not a Python vs Forth thing at all, since it
would be great if a Forth distro could be set up like that. I'd be
happy to buy you or Mathias a Trinket or two if you've got any interest
in porting Mecrisp.

Dumb hardware question: how much difference does it make to have 5y
experience with a narrow product line like the STM32F103? To use some
other chip, especially from the same manufacturer, can't you just use
the new pinout in your CAD file, make a few software changes, and be on
your way after maybe getting over a snag or two? From a software
perspective I can't really tell the difference between one board and
another.

[Terry Porter]

On Sun, 24 Sep 2017 15:11:05 -0700, Paul Rubin wrote:

> Terry Porter <te...@tjporter.com.au> writes:
>>> wonder why the STM8 is not more popular.
>> Probably a similar reason to why the Z80 isn't more popular in PC's ;-)
>
> Well, I mean popular compared with the AVR which is much more expensive
> for what you get. And I don't think there's an AVR or much of anything
> else with comparable features in a SOIC-8.

Ahh, in that case probably because the mega popular Arduino uses the AVR ?

>
>> Nevertheless, Thomas' stm8ef Forth looks really nice, and I like the
>> STM8 ISA. If I was interested in 8 bits, which I'm not, I would want to
>> use the STM8 and stm8ef.
>
> I ordered a few of those 60 cent boards just for laughs. The order went
> through but then AliExpress blocked me so I can't order anything else
> from them without jumping through hoops that I'm unwilling to, oh well.
> I also ordered a STM32F103C8T6 board (64k flash, 20k ram) for around
> $1.50 and a few other things, and a $1.30(?) STM8 board with 16k flash
> and 2k ram. No idea what to do with any of them but the whole bunch was
> around $10 USD, so whatever.

The STM32F103C8T6 is everywhere, it's cheap, very fast, packed with
peripherals and supported by Mecrisp-Stellaris and my register generator
'svd2forth'. It will leave the STM8 for dead in every way I think.

> I'd be happy to buy you or Mathias a Trinket or two if you've got any
interest in porting Mecrisp.

I don't believe that will happen as Matthias tell me that 'Atmel chips
have a 256 bytes at once write cycle. Not good for dictionary usage'

>
> Dumb hardware question: how much difference does it make to have 5y
> experience with a narrow product line like the STM32F103?

In embedded, I wouldn't call STM32F a 'narrow product line' as the core
is ARM Cortex-M and all the zillions of other ARM Cortex-M MCU's are very
similar, only the peripherals vary, but they have a lot of similarities.

In my case, what's important to me is my development environment, as I
have to be easily able to code, test, debug etc, and I have all that for
STM32F.

With STM32F, I only need a SWD programmer, which comes with every
Discovery Board (only need the one) and I can flash and debug.

> To use some
> other chip, especially from the same manufacturer, can't you just use
> the new pinout in your CAD file, make a few software changes, and be on
> your way after maybe getting over a snag or two? From a software
> perspective I can't really tell the difference between one board and
> another.

Sure, It's not hard (easy infact) to jump between different STM32F models
(or even different Cortex-M chips), for instance I've used the STM32F103
a fair bit, but mainly use the STM32F051.

Mecrisp-Stellaris has binaries that load and run on 17 different STM32Fx
chips (and 17 other manufacturers):-
http://128.199.141.78/supported-hardware.html

I bought a Ti Tiva Conected Launchpad the other week, the MCU is a
tm4c1294 (120MHz 32-bit ARM Cortex-M4 CPU; 1MB Flash, 256KB SRAM, 6KB
EEPROM) and yet I felt at home on it, and of course, Mecrisp-Stellaris
looked and worked almost identically.


Cheers,
Terry

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
> Ahh, in that case probably because the mega popular Arduino uses the AVR ?

Yeah, but I wonder how that happened. Even the PIC is way more popular
than the STM8, and the STM8 is much nicer. I never even heard of the
STM8 til pretty recently though.

> The STM32F103C8T6 is everywhere, it's cheap,

Digikey sells it for $6 in onesies, $3 in reels of 2400! What's going
on, are there better places to get this stuff? Do you know if there's a
straightforward Mecrisp install for those Chinese boards?

> I don't believe that will happen as Matthias tell me that 'Atmel chips
> have a 256 bytes at once write cycle. Not good for dictionary usage'

Ok, but there is enough ram to not have to write the dictionary to flash
til the user types "save" or there's enough to fill a block or
something. Any idea about the Kinetis parts found in the small
Teensies? MKL26Z64VFT4 in the Teensy LC, MK20DX256VLH7 in the Teensy
3.2. Those boards are on the expensive side but you don't have to wait
months to get them from China.

> I bought a Ti Tiva Conected Launchpad the other

> week... Mecrisp-Stellaris looked and worked almost identically.

Cool, I still have a couple of the original Stellaris boards that I want
to put Mecrisp on sometime. But I like tiny little Trinket-sized boards
a lot better. The Espruino Pico http://www.espruino.com/Pico is another
nice one, that uses a STM32F401CDU6. I haven't bought one yet. It
comes with Javascript on board! I'd rather use Micropython ;-).

[Terry Porter]

On Wed, 20 Sep 2017 10:21:59 -0700, Mark Wills wrote:

> On Wednesday, 20 September 2017 11:30:21 UTC+1, Terry Porter wrote:
>
>> I'm already as productive as I need to be with Forth, you're advocating
>> Micropython to solve a problem I don't have, using a programming
>> language I don't need.
>>
>>
> Forgive me, but are you?

I believe so.

>
> From what you've posted above, you are using Forth to explore a
> particular processor, and that's absolutely fine. But what are you doing
> with the hardware? What applications are you writing?

I only make very small embedded gear, mainly for industrial,
instrumentation and automotive. 64KB of flash is massive for my projects
even using C.

Here is a example. Guy comes to me wanting a 'drag bike, second stage
clutch release timer'.

He has a nitro fuelled Harley drag bike that does the standing quarter
mile in something like 9 seconds. He needs to control the second clutch
which needs to be engaged up to a couple of seconds after the bike takes
off from the line when the first clutch is engaged.

He wants a box with dip switches he can set and forget, he doesn't want
usb, bluetooth, or any thing he can't understand and easily adjust.

I built a small box, bank of dip switches, FET, attach wires and
schematic of how to connect, and it's done.

I don't need a library to provide a spin timer, scan dip switches, or
operate a FET, these are the kinds of simple things I do.

Forth allows me to do this kind of thing so fast, it's probably illegal
;-)

>
> I am only interested in making money. I've been self employed since
> about 2000, so I tend to think in terms of what is going to continue to
> feed my family! Further more, if I can do something fast, that means I
> can bill the customer quicker, and potentially get more work from him,
> or move onto the next job.

I've been self employed most of my life, and making money is also a
necessity for me. Fortunately I have a small non embedded business that
pays most of my bills, but I suppliment it with custom (small) embedded
solutions.

>
> In microPython, I can interface to a GPS unit over a serial port,
> a GPRS modem over another serial port, and implement a vehicle tracking
> system in a day.
>
> I can't do that in Forth.

Will your solution involve buying ready made boards from adafruit, wiring
them together and than wondering how covert your lunchbox sized vehicle
tracking system will be ?

Or will it involve a custom hardware on a pcb you design and lay out
along with a design for the case or enclosure ? Will it work from 12 or
24 volts and withstand automotive charging spikes or is it battery
powered ?

How much time will you spend coding diagnostics for the production
process, or component changes depending on component supply problems?

Hell, I couldn't even design and make a decent waterproof, automotive
grade enclosure for it in a day, besides, aren't those kind of tracking
devices made cheaply (and nastily) in China now ?

>
> In Forth, there's way to open a serial port.

? what word(s) are missing above ?

>
> Again, it's *not* the language, it's the software or libraries that are
> available to the programmer in that language. For the Forth programmer,
> the number of libraries that is available is practically zero. There's a
> few, like various flavours of object libraries etc, but if I want to
> query an SQL database, or FTP a file onto a server, or grab a HTTP page,
> or open a serial port, or send TCP or UDP packet, then forget it.

If I wanted to any of those things, I'd use embedded Linux and something
like a RPi as I have done on a few occasions.

For me, every project is different and I always write my own code, design
my own pcb's and enclosure etc. I have a good collection of libraries
that I use for my projects, but theyre pretty simple, ADC routines etc.

>
> There's no software libraries for Forth, because it needs a platform
> upon which to gain some traction, then it would give people a platform
> around which to coalesce. Unfortunately that hasn't happened.

I don't see that as a disadvantage, I want my choice of hardware, my own
development system and the rest I'll do myself.

Before I used Forth, I used machine code, assembly, basic, and C. I
didn't have any libraries then either, and I didn't want any.

>
> I too have been having some fun with Forth in embedded environments.
> I've been using FlashForth on the ATMEGA328P and have been very
> impressed indeed. That particular platform does have some FlashForth
> libraries that you can use, for I2C etc. I developed a driver for the
> Hitachi LCD units, which was fun, but I'd rather not have to do it
> myself.

Flashforth is excellent, I first used it about 5 years ago and made up
some hand wired PIC18 and PIC24 series units to test it. I'm a PIC fan,
not so much a Atmel fan, and I've moved onto 32 bit STM32F MCU's now and
I like it there.

> Consider, on the Arduino (same processor) in C I just type:
>
> <#include wire.h>
> <#include lcd.h>
>
> void setup() {
> LCD lcd(); lcd.clearScreen(); lcd.setCursor(0,3); lcd.print("Hello
> Mother!");
> }

That looks easy, no argument, but I'd enjoy doing the code for that with
Forth if I had a application that needs a LCD display. Besides, Mecrisp
users have written plenty of LCD code I can reuse or learn from.

>
> When we can get to that point on an embedded hardware platform, we'll
> have something to shout about.

I'm already 90% happy with Forth, and I have the development environment
I always wanted when I used C.

I have Gcc and Gdb with libopenCM3, debugging with GDB over SWD etc, but
nowdays I find I don't want to use C, I have grown to love the
simplicity, versatility and speed of project development using Forth.

>
> Until then, all we have is an absolutely *incredible* mind-blowingly
> good programming language - Forth; but no eco-system to do anything
> with.

I don't need or want any eco-system for Forth, I *need* a really good
development system where I can rapidly develop solutions. I build what I
need, and it's always different.

So far, Forth is the best system I've seen for this. I don't use Windows,
Linux or Osx, if any solutions require them, they're not for me.

>
> And that's very unfortunate.

Sorry, I just don't see it that way, but it's only my opinion, I'n not
saying your're wrong.

[Paul Rubin]

Terry Porter <te...@tjporter.com.au> writes:
> I have Gcc and Gdb with libopenCM3, debugging with GDB over SWD etc, but
> nowdays I find I don't want to use C, I have grown to love the
> simplicity, versatility and speed of project development using Forth.

What does your edit-compile-debug cycle look like with Mecrisp on that
ST ARM? How do you deal with source control, configuration of the Forth
program on the MCU, etc.? I'm skeptical that it can be nearly as
convenient as the Trinket.

In the case of the guy wanting the motorcycle clutch controller, how
many units did you make? If it was just one (or a handful), did it
matter in the slightest whether the MCU cost 60 cents vs 10x that amount?

You designed a custom PCB and made the enclosure yourself instead of
ordering one? How much time did you spend on that? Do you etch the
boards yourself or send them out? Was there a reason to not just use a
proto board if you don't use a ready-made board? Any of the Adafruit
Feather boards with some prototyping area could have probably done
everything you wanted. Or the Espruino Pico has a built-in FET that
could kick a solenoid if that's what you were doing. Then something
like one of these:

http://www.budind.com/sealed_aluminum.php

and maybe some potting material, and you're off to the races.

[Terry Porter]

On Mon, 25 Sep 2017 23:38:51 -0700, Paul Rubin wrote:

> Terry Porter <te...@tjporter.com.au> writes:
>> I have Gcc and Gdb with libopenCM3, debugging with GDB over SWD etc,
>> but nowdays I find I don't want to use C, I have grown to love the
>> simplicity, versatility and speed of project development using Forth.
>
> What does your edit-compile-debug cycle look like with Mecrisp on that
> ST ARM?

There is no 'compile cycle', I edit and debug and repeat until it's done.

Flashing C binaries and running GDB on the target is glacial in
comparison as far as I'm concerned.

> How do you deal with source control,

The question is very interesting and illuminates your impression of
Forth, which I think you see as limited and perhaps a bit behind the
times :)

I use Fossil SCM for source control, but I could use anything. I like
Fossil because it also has a webserver, wiki, bugtracker and is designed
by the Sqlite author.
https://www.fossil-scm.org/

> configuration of the Forth
> program on the MCU, etc.?

MCU config is a big part of every program, and with 470 Registers and
1100 BitFields in a lowly Cortex-M0, config begins with developing a
intimate knowledge of the hardware. After that, it's just code.

> I'm skeptical that it can be nearly as
> convenient as the Trinket.

I spent a while developing my ideal Forth embedded design environment
and it works very well for me. It's crafted exactly for me, to provide
exactly what I want, not what someone else thinks I want.

Starting a new project with my system takes under 0.3 of a second.

I create a directory and type 'forthme' in it and 0.3 of a second later,
the directory looks like this:-

/test-project% tree -a
.
|-- .fossil-settings
| |-- binary-glob
| |-- crnl-glob
| |-- ignore-glob
| `-- ignore-glob.no-warn
|-- .fslckout
|-- Makefile
|-- README-test-project.txt
|-- STM32F051K8.txt
|-- STM32F0xx.svd
|-- STM32F0xx.svd.uf.svd
|-- e4thcom-ttyUSB0.sh
|-- e4thcom-ttyUSB1.sh
|-- e4thcom-ttyUSB2.sh
|-- edit-README-test-project.txt
|-- edit-all-files-test-project.sh
|-- edit-template.xml.sh
|-- edit-test-project.fs
|-- edit-test-project.preload.fs
|-- edit-test-project.sch.sh
|-- f051-legends.fs
|-- flowcharts
|-- gafrc
|-- lib -> /home/tp/projects/programming-languages/forth/mecrisp-
stellaris/library
|-- memmap.fs
|-- misc-files
|-- mk.template.xsl
|-- pdf
|-- pics
|-- register-reference.fs
|-- registers.xsl
|-- rpi-ssh.sh
|-- schematics
| `-- test-project.sch
|-- sphinx
|-- svdcutter.xsl
|-- svduf.xsl
|-- template.xml
|-- test-project.fs
|-- test-project.preload.fs
|-- test-project.txt
|-- text
`-- z-WARNING-DESTROY-test-project.fossil.sh

9 directories, 40 files

That 0.3 seconds includes populating the new project directory and
versioning it. All the files have the directory name (the project name)
and they're all added to Fossil and commited before I enter a line of
code. In fact it's all done before my heart has had time for one beat.

I can now start typing Forth code into a automagically opened terminal
onto the actual hardware I'll be using and editing the project templates
to suit. This includes the memory mapped Forth register words for the
MCU, a schematic diagram, possibly a Sphinx Ebook for the product.

It's all done with one sh script, no Java, no Eclipse, no delay.

>
> In the case of the guy wanting the motorcycle clutch controller, how
> many units did you make?

Only one.

> If it was just one (or a handful), did it
> matter in the slightest whether the MCU cost 60 cents vs 10x that
> amount?

The MCU cost is always irrelevant to me, the main cost is my time. The
better I know the hardware and my design envoronment, the faster I am.

>
> You designed a custom PCB and made the enclosure yourself instead of
> ordering one?

I always make my own.

> How much time did you spend on that?

That's confidential, but I made a profit. It was a fast and easy job for
me.

> Do you etch the
> boards yourself or send them out?

Design and etch myself.

> Was there a reason to not just use a
> proto board if you don't use a ready-made board?

Of course, it was a purpose designed device and had to fit in a specific
place on the drag bike. Protoboards are in no way suitable for a custom
hardware product in my opinion. They're for hobbysists who don't have the
experience or equipment to make their own gear.

In my world, protoboards exist so that protoboard sellers have a product
to sell.

> Any of the Adafruit
> Feather boards with some prototyping area could have probably done
> everything you wanted.

No, nothing off the shelf does *everything* I want and it never will.

> Or the Espruino Pico has a built-in FET that
> could kick a solenoid if that's what you were doing.

I have plenty of FET's, I'm an electronics tech. I just reach for my
parts draws and I have a FET of my choice in 10 seconds.

I'll choose the device based on power dissipation, maximum drain current,
operating voltage etc, and it's different for every job.

The STM32F051 is a million times overkill for that little timer, but at
$0.6 USD each I can afford to waste 99.9% of it :)

> Then something
> like one of these:
>
> http://www.budind.com/sealed_aluminum.php

I'm sure someone who doesn't have a decent machine shop as I do would
find them handy if the size fits their needs, but I have always made my
own custom enclosures.

That way I get what I need, right away, no waiting no delay.

>
> and maybe some potting material, and you're off to the races.

Maybe not, I didn't need to encapsulate it, and he may need it serviced
sometime.

[Terry Porter]

On Tue, 26 Sep 2017 08:27:39 +0000, Terry Porter wrote:

The usual nonsense ... :)

That tree listing was all munged when I read it after the upload, ...
then I remembered I'd already started a page on this topic some time ago.

At least here, the tree listing is readable, and there is a Fossil SCM
pic showing what I mean. No more screen dumps from me on Usenet!

http://128.199.141.78/devenv.html

[Coos Haak]

Op Tue, 26 Sep 2017 08:27:39 -0000 (UTC) schreef Terry Porter:

> On Mon, 25 Sep 2017 23:38:51 -0700, Paul Rubin wrote:
>
>> Terry Porter <te...@tjporter.com.au> writes:
>>> I have Gcc and Gdb with libopenCM3, debugging with GDB over SWD etc,
>>> but nowdays I find I don't want to use C, I have grown to love the
>>> simplicity, versatility and speed of project development using Forth.
>>
>> What does your edit-compile-debug cycle look like with Mecrisp on that
>> ST ARM?
>
> There is no 'compile cycle', I edit and debug and repeat until it's done.

Somewhere 'compiling' is missing.

groet Coos