STM32 without STM Libraries

[techman-001]

That's a very good description of where forth really is much better than the alternatives.  You're taking small steps and and every step is a progression built on tested code.

The best part is you can test it interactively before you compile it and move to the next word.

Well said!

It's interesting how all Forth programs start off looking like Assembly Language and end up as a specialized language for the problem they solve.

For a (simple example) washing machine controller the Forth program may look like this :

power-on doorclosed? water-fill agitate-10-minutes drain doorclosed? water-fill spin-1-minute drain

Forth and Lisp are the only two programming languages that can 'reprogram themselves'.

[techman-001]

So I started with bare-metal programing for AVR and when you learn how to do this stuff on one MCU then it easy to transfer to another. Currently, I am working also on STM32 and I didn't have any problems when migrating to this MCU.

I think this is way to go if you want to really know your stuff. Also, If you love Linux, Makefiles and VIM there is no IDE that could give you what these 3 do.

For the last 20 years I have felt the same way, then my system of Forth, FreeBSD, Makefiles, Gvim and GnuScreen turned into a IDE all by themselves ;-)

[westfw]

It's not just that the STM library code is bloated, it's that the API strategy that they have chosen can not help but cause bloat.  I think I prefer something like Arduino, with its trivial base (that can nevertheless be optimized, if necessary), good orthogonality (one feature doesn't depend so much on other libraries), and easy extensability.(I can see how a silicon vendor would not be very satisfied with a system that didn't show off, or at least allow, the full breadth of the features they have implemented, though.)

[Karel]

My two cents.

Last year I learned myself to program the STM32 (topic here: https://www.eevblog.com/forum/microcontrollers/pic32mx-vs-stm32l4-my-first-impression/.

I use (almost) the "bare metal" method. I use the CMSIS library (which are in this case just a bunch of header files) and the MCU manual.

To setup a new project, I use STM Workbench: http://www.openstm32.org/System%2BWorkbench%2Bfor%2BSTM32

In the project settings I tell the IDE not to use the HAL.

To make it easier to setup the clocks and the pinmuxing, I use CubeMX, but only to guide me when writing the code.
I never let CubeMX generate the code.

It took me about a month to "master" the STM32 and write all the necessary libs/drivers for SPI, UART, I2C, and to understand
how to use DMA, the ADC, etc. I used the Nucleo-L452RE board for my exercises.

All the software tools come for "free" and the devkit and the programmer are ridiculously cheap.
I payed with my time though. But, at least for this brand/family, it's a one time effort.

[pkplex]

Just want to say thanks for bringing up forth. I was searching for ideas on a sane and bloat free C/C++ framework/environment/whatever to for stm32, and stumbled apon your comment on Saturday evening. Spent Sunday playing around with forth on an F0 discovery, and now I cannot understand how it is not more popular. Its brilliant.

[techman-001]

Just want to say thanks for bringing up forth. I was searching for ideas on a sane and bloat free C/C++ framework/environment/whatever to for stm32, and stumbled apon your comment on Saturday evening. Spent Sunday playing around with forth on an F0 discovery, and now I cannot understand how it is not more popular. Its brilliant.

Fantastic, and the F0 Disco is a really great intro to Cortex-M0.

Forth only appeals to certain mindsets I think, but to those 42 people .... Forth rules! 

I've just put together a new LMT01 temperature sensor binary image for Blue Pills and similar STM32F103 boards. It uses the USB interface for power and a virtual serial port, has a few handy subroutines (Words) and most of the Peripheral Registers are memory mapped ready to be read or written in real time.

I hope one can get a feel for Forth and Forth development with this image. If you try it, please let me know?

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

I'm creating exactly the same project as below for the F0 Disco right now and it should be up in a day or so.
I'll post the details here, on my Utube channel, and my Doc site.

The standalone image requires nothing else to run. Details and image at the url below.

https://mecrisp-stellaris-folkdoc.sourceforge.io/project-stm32f103-lmt01.html#stm32f103-lmt01

The image runs on a STM32F103 MCU with 64 KB of flash like so:

Code: [Select]

free (bytes)
FLASH.. TOTAL REPORTED: 131072 USED: 107932 FREE: 23140
RAM.... TOTAL PRESET: 20000 USED: 1596 FREE: 18404
It also has the MCU Signature reader:

Code: [Select]

stm32id
Die xy coords: 107741012
Wafer Number: 72
Lot_num ascii encoded  [23:0]: 0x00555285  | U R .
Lot_num ascii encoded [55:24]: 0x87237267  | . # r g
There is a accurate ms.delay using the Systick

Code: [Select]

1000 ms.delay     --> gives a 1 second blocking delay
Some Registers in real time:

Code: [Select]

rcc_cfgr.
RCC_CFGR () $001D840A
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1 0 0 0 0 1 0 0 0 0 0 0 1 0 1 0

gpioa_odr.
GPIOA_ODR (read-write) $0000A000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
Finally the temperature of a single LMT01 sensor

Code: [Select]

t
26,8 C   ok.

[voltsandjolts]

MicroPython is also worthy of mention here.
I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

[techman-001]

MicroPython is also worthy of mention here.
I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

Micro Python is interesting but has a couple of major disadvantages to Forth.

1. My just released self contained bootable Binary Image which contains the USB, temperature reading code, other utilities, thousands of register print words and so on, is only 60KB in size. Micropython needs at least 256KB of flash just for Micropython, which means it can't run on Cortex-M0 chips limited to a maximum of 64KB Flash. By comparison Mecrisp-Stellaris only needs 20KB of flash for itself.

2. In the embedded world microseconds can be vital, so a language with a garbage collector such as Python will have timeslots where the MCU is busy garbage collecting, and people have found this to be a issue in some case.

3. Anything as pretty as Python must have a evil soul 

[GeorgeOfTheJungle]

I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

Python is much nicer and higher level, and has no semicolons :-) , but the niceties come at a price. Python, Lua or JS require a serious µC to run at reasonable speeds. That is, if you need the speed. Maybe not. Maybe yes. I'm mixing C++ and Forth in my esp32s, because doing so there's some things that now I can reprogram on the fly and don't require anymore a whole recompilation+reflash. It's not a fast as C but good enough, and doesn't eat too much memory. Techman-01 is the culprit. And the hp65 I had when I was a child.

[techman-001]

I know nothing about Forth so can't do a comparison, except that Python code looks nicer to me

Python is much nicer and higher level, and has no semicolons :-) , but the niceties come at a price. Python, Lua or JS require a serious µC to run at reasonable speeds. That is, if you need the speed. Maybe not. Maybe yes. I'm mixing C++ and Forth in my esp32s, because doing so there's some things that now I can reprogram on the fly and don't require anymore a whole recompilation+reflash. It's not a fast as C but good enough, and doesn't eat too much memory. Techman-01 is the culprit. And the hp65 I had when I was a child.

You had a hp65 !!!

I could only afford a ti-SR-52. No wonder I didn't start using Forth until 2014!

Your esp32s stuff sounds pretty clever so I'm having a hard time visualizing you swinging thru the trees eating a banana 

What Forth are you running on the esp32, could it be Mitch Bradley's CForth ?

[voltsandjolts]

Micro Python is interesting but has a couple of major disadvantages to Forth.

1. ... Micropython needs at least 256KB of flash just for Micropython...

2. ... a garbage collector ..... to be a issue in some case.

3. Anything as pretty as Python must have a evil soul 

[1] I wouldn't regard 256KB FLASH requirement as a major disadvantage, although it is a trade off. But 256KB M0 micros can be purchased for a couple of bucks.

[2] Ahh, Forth has no dynamic allocation, that's nice. The Python GC is non-deterministic but can be switched off when running short bits of time critical stuff. Of course, if your whole app is time critical (within a few ms) then yes, GC could be a show stopper.

[3] Hah, by that logic, I have a heart of gold!

[techman-001]

Micro Python is interesting but has a couple of major disadvantages to Forth.

1. ... Micropython needs at least 256KB of flash just for Micropython...

2. ... a garbage collector ..... to be a issue in some case.

3. Anything as pretty as Python must have a evil soul 

[1] I wouldn't regard 256KB FLASH requirement as a major disadvantage, although it is a trade off. But 256KB M0 micros can be purchased for a couple of bucks.

[2] Ahh, Forth has no dynamic allocation, that's nice. The Python GC is non-deterministic but can be switched off when running short bits of time critical stuff. Of course, if your whole app is time critical (within a few ms) then yes, GC could be a show stopper.

[3] Hah, by that logic, I have a heart of gold!

It's a  major disadvantage only compared to Forth. I'm sure most Micropython users probably want the Ghz Cortex-M's for speed anyway ?

I forgot to add, while Assembly and C are about 3 times faster than Forth, Forth is about 30 faster than Python in my tests.

[exe]

I used ChibiOS, and found it the most intuitive so far.

[voltsandjolts]

It's a  major disadvantage only compared to Forth. I'm sure most Micropython users probably want the Ghz Cortex-M's for speed anyway ?

Standard PyBoard v1.1 is STM32F405, so approx 1MB/192KByte/168MHz and MicroPython runs well on that.

I forgot to add, while Assembly and C are about 3 times faster than Forth, Forth is about 30 faster than Python in my tests.

MicroPython has options for writing critical sections in assembly, or using the 'Viper' native code emitter, or writing Python or C modules which can be included at compile time. Pre-allocation and re-use of buffers helps reduce dynamic allocation and associated GC costs. So, in applications that have some crictical sections and are more relaxed elsewhere it works very well. Probably my favorite feature of MicroPython is that it makes a great 'glue' language that makes for 'speedy development', if not a 'speedy runtime'.

[westfw]

Forth is about 30 faster than Python in my tests.

Is that all?  That's a pretty impressive Python implementation!

[1] I wouldn't regard 256KB FLASH requirement as a major disadvantage
[2] Ahh, Forth has no dynamic allocation, that's nice.

To me it seems very odd to see those mentioned consecutively.  Or maybe it's an age thing:  to me, dynamic memory allocation seems like one of the first things that ought to show up as you get to "more powerful" processors (but garbage collections: not so much.)

I suspect that the big difference is that your successor will still be able to read your python code a year after you've left the company, while with Forth you might have a problem with your own code after a 2-week vacation :-)

[voltsandjolts]

[2] Ahh, Forth has no dynamic allocation, that's nice.

Agree with westfw; just to clarify my statement, while dynamic allocation is useful it does come with a GC cost, which may be a lot or nothing depending on how your code is written.
I just meant that in a hard realtime system, not having dynamic allocation could be better because unpredictable GC execution time is one less thing to worry about.

[jhpadjustable]

Does sbrk qualify as dynamic memory allocation? How about the malloc layer on top of it? Neither of those GC but they are most certainly performed on demand of the program at runtime, and not statically at link time. Is the term being misused in this thread or am I just that old?

[voltsandjolts]

We are discussing bare metal here, not embedded OS.

[MT]

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

Why would M3 suck compared to M0?

[techman-001]

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

Why would M3 suck compared to M0?

The STM32F103 is a OLD chip based on the Cortex-M3 first announced in 2004. In fact it is the first generation of Cortex M3 chips from ST Micro (Introduced in 2011) and they have a lot of known issues. A much better choice for new projects are either STM32F0, F0+ series or STM32F4 series. The prices are about the same for comparable parts.

STM32F103 Issues
CAN Bus * Shares memory with the usb hardware, which means that usb and canbus cannot be enabled at THE SAME TIME
Serial Comms * NO AUTOBAUD
USB * Shares memory with the canbus hardware, which means that usb and can cannot be enabled at THE SAME TIME.
USB *  must use a CRYSTAL unlike later stm32 chips which use only a internal RC clock for USB
Digital to Analogue Converter *  DOESN’T have one
GPIO I/O port registers *  Have to be accessed as 32-bit words, half-word or byte accesses are NOT allowed.
GPIO I/O port registers * Very CONFUSING to configure with CRL and CRH in comparison to Cortex-M0
I2C *  There are SIX pages of ERRATA for the I2C peripheral
DFU *  NO DFU bootloader (for flashing via USB)

[iMo]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

[techman-001]

I am a big fan of Forth. Worked a bit with amforth (atmegas), flashforth (pic18/24/dspic33), mecrisp(stm, ice40).
The major "issue" with Forth I see is, except it is "write only language" , the community (extremely limited in size) does not share code ("libraries") as it is with, say, arduino community.
Be warned.. 

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

There isn't really a Forth  'community', rather thousands of Forth users doing their own thing with their own Forth and their own disparate hardware from 6502's to ARM cpu's.

But ... because Forth probably runs on more hardware than any other OS, most code isn't compatible.

Libraries ... do you mean piles of definitions and functions/methods stacked together ? ;-)

We have plenty of those.
Here is one of mine, it's freely available to anyone. Of course they'd need to use it on a STM32Fxx and modify the code for a different clock speed.

https://mecrisp-stellaris-folkdoc.sourceforge.io/systick-library.html#systick-library

[SiliconWizard]

If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0.

Why would M3 suck compared to M0?

The STM32F103 is a OLD chip based on the Cortex-M3 first announced in 2004. In fact it is the first generation of Cortex M3 chips from ST Micro (Introduced in 2011) and they have a lot of known issues. A much better choice for new projects are either STM32F0, F0+ series or STM32F4

Oh, yeah. This is not because it's a Cortex-M3 per se though, so probably why MT asked that!
And yes, I agree the STM32F103, although very popular for some reason (a bit like the old Atmega's), is a poor choice these days. There's now myriads of better MCUs from STM. Don't neglect the L4 series also, for those aiming for lower power stuff.

It's almost like the F103 is becoming like a slow disease that's gotten contagious. It's growing everywhere, is still being cloned all over the place, dev boards for it are also growing like fungus. Please let the old chap die its own death! 

[westfw]

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

Actually, I find it quite the opposite.
Cortex-M0 doesn't support the 32bit "Thumb-2" instructions, which means that many of your traditional ARM instructions are completely missing (divide), or have severe limitations (no "AND/OR/EOR" with immediate values, LDR/STR indexed-with-offset limited to offsets <32, more.)  It's a PITA to program in assembly language, and the code produced by even good compilers is frequently big, slow, and ugly (compared to the CM3.)


Note that this is completely different than "the new ST M0 chips have less F-ed up peripherals than the ancient 32f103", which has nothing to do with CM0 cs CM3 CPUs.


Now, it does seem that CM3 has largely lost vendor interest in favor of CM4 (and CM0); I don't quite understand why that's the case - I suspect it has more to do with hardware licensing and implementation details than CPU architectural issues.  (Doesn't the M0 have a flat-rate license fee, rather than a royalty-based scheme?)

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

I suppose I would believe that the main reason that Forth tends to be looked on a more "write only" than C/C++ is that there's a large community of C/C++ programmers who have done a pretty good job of establishing acceptable and unacceptable "styles" of C/C++ programming.  And Forth is more of an "everyone is on their own" situation.
But that's still means that Forth has a problem :-(

(Assembly language has a similar problem.  Back when I worked on assembly language code for a living, the target system had well-established standards in terms of macro definitions (including complex data structures), calling conventions, formatting, name selection, and so on.  Code written in that community was pretty understandable and portable between maintainers.  Nowadays, in our modern "why would you want to program in assembly?" age, it's more of a free-for-all :-( )

[techman-001]

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

Actually, I find it quite the opposite.
Cortex-M0 doesn't support the 32bit "Thumb-2" instructions, which means that many of your traditional ARM instructions are completely missing (divide), or have severe limitations (no "AND/OR/EOR" with immediate values, LDR/STR indexed-with-offset limited to offsets <32, more.)  It's a PITA to program in assembly language, and the code produced by even good compilers is frequently big, slow, and ugly (compared to the CM3.)

Note that this is completely different than "the new ST M0 chips have less F-ed up peripherals than the ancient 32f103", which has nothing to do with CM0 cs CM3 CPUs.

Now, it does seem that CM3 has largely lost vendor interest in favor of CM4 (and CM0); I don't quite understand why that's the case - I suspect it has more to do with hardware licensing and implementation details than CPU architectural issues.  (Doesn't the M0 have a flat-rate license fee, rather than a royalty-based scheme?)

Every language can be "write only" it depends how badly (or cleverly) one writes their code.

I suppose I would believe that the main reason that Forth tends to be looked on a more "write only" than C/C++ is that there's a large community of C/C++ programmers who have done a pretty good job of establishing acceptable and unacceptable "styles" of C/C++ programming.  And Forth is more of an "everyone is on their own" situation.
But that's still means that Forth has a problem :-(

(Assembly language has a similar problem.  Back when I worked on assembly language code for a living, the target system had well-established standards in terms of macro definitions (including complex data structures), calling conventions, formatting, name selection, and so on.  Code written in that community was pretty understandable and portable between maintainers.  Nowadays, in our modern "why would you want to program in assembly?" age, it's more of a free-for-all :-( )

[Cortex M3 CPUs] suck in comparison to the Cortex-M0

I didn't write that. I wrote this, which is all about the peripherals.
Quote from: techman-001 on November 11, 2019, 07:09:01 am "If you don't have a STM32F103, good! because they suck in comparison to the Cortex-M0."

As a Forther, I have no problem with Assembly. Write it how you like.