Author Topic: starting with STM32 CMSIS  (Read 12970 times)

0 Members and 2 Guests are viewing this topic.

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #50 on: July 24, 2019, 10:57:31 am »
I agree on the cargo cult "overlibrarization" problem existing, but I don't think it's connected to any particular language. I don't genuinely think that the super crappy STM32 code depending on bloated, hard-to-use libraries have anything to do with C. Quite the opposite - they are not using C features which would help reducing such code, instead depend on autogeneration. C actually makes writing such bloated mess awkward - yet they still managed to fuck it up.

Quite the opposite - the "higher" we go, the more absurd the library cargo cult becomes. From a C viewpoint, many modern C++ developer can't wipe their own butt without linking with a massive bloated library which is harder to use, understand and maintain than just to wipe your butt yourself to begin with.


The interactivity thing is a total mystery to me. If I want to interactively toggle IO pins, I buy a computer equipped with IO (for a modern, cheap example: Raspberry Pi), so it's not only interactive through UART, it's usable as a standalone unit, can get to the Internet, and then I can toggle the pins interactively from shell, Python script or whatever floats my boat.

With a microcontroller, I'm developing an actual production unit, and if my production unit needs to have a UART command parser, I definitely need it to be my custom one, not a stock Forth interpreter capable of running any arbitrary code.

I do see a very limited use case of verifying PCB schematic by toggling pins on the very first unit the first time to see what happens. This would be a bit faster with the Forth interactive interpreter (minutes) than writing my usual initial C testbench (maybe 30-60 minutes).

We can probably agree that 'poor C programmers' can produce horrible code, but 'poor Forth programmers' produce the absolute worst code ever written by man.

I used to be very happy with C, I found it easy to read and easy to write. Now I use Forth instead not because Forth is 'better' but because *I* prefer it.

I have always agreed with your advice here on this forum that new C programmers start at the beginning, no libraries, read the tech manuals, understand how it all works.

Forth Interactivity:
Firstly I must say that modern systems with SWD/JTAG debugging via GDB are fast and awesome. I personally refused to use Forth until my development system was as fast or faster than the above because I loathe slow design environments.

1) You have a complex RTC chip, or it may be in your MCU, either way the Ref Manual is ambiguous about something and you can't get a certain thing to work the way you need to. This is a common issue, the manual may be Chinese and 'converted' to English poorly etc.
 Forth allows you to quickly 'play around with the RTC config' by writing and reading registers in real time, until you find out what really happens, (at which point the manual usually begins to make obvious sense). It is very fast with no compile, flash, try, redo cycles.

2) You want to adjust a timing loop, the scope is connected all you need to do is play around with numbers in a register. Forth allows you to do this in real time and 'get a feel for the hardware'. I know you can do this with GDB etc, but it's utterly trivial in Forth.

3) The prototype is ready and many configuration numbers have been estimated but it still needs fine tuning on the actual Turbo Encabulator as the inverse phase detector values are uncertain. With Forth you can use a Android Tablet running a Serial Terminal and enter the values in by hand at the actual machine in the gearbox factory. You don't need to drag your design environment over there just to do the fine tuning.

4) You've just been given a project and you have a hundred ways to make it, a hundred different parts you could use and you're racked with indecision at this point. At least this has always been a common experience for me, that first step before anything exists.
Forth allows you to breadboard and be interacting with the hardware in minutes, testing timing, getting a feel for that new chip you haven't had time to test but which might be *perfect* for this new project. I find that first step is the hardest and so I just make sure I test *something* anything that will do the job, and once I start, things seem to naturally fall in place.

Not one line of C code has to be written, compiled, flashed or whatever.

I guess the summary is:
C users select the hardware, study the manuals, write the code, compile, flash, test, debug etc

Forth users just open the manuals, plug in the hardware and start interacting with it, finding what works, what doesn't ... THEN they start writing the code based on their observations.


 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #51 on: July 24, 2019, 11:08:47 am »
With Arduino, you buy a "motor control shield", with both HW&SW already designed, set up a few parameters, and call runMotor();

This is a great approach whenever the solution already exists. The important distinction is, you are not "writing a neural network", nor you are "building a motor controller". This becomes apparent the very second the finished product you are using doesn't do exactly what you need it to.

When the exact solution doesn't exist as a large building block, this design principle falls apart completely, and you are again writing in C - or in the latter example, designing your own PCB and writing your own drivers from scratch.


I totally agree, and Arduino users at this point are *well* outside their comfort and experience zone because they are not engineers.

If they were engineers, they wouldn't be using Arduino.

The cool new PCB they design looks great in all it's Kicad 3D glory, it's based on a design they found on the Internet but the motor is hunting or noise is a problem, or the regulator has bunt a TO220 size brand on the tip of their nose as they tried to locate the burning smell.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #52 on: July 24, 2019, 11:32:54 am »
I just enter this command to set GPIOA-0 as a OUTPUT :

OUTPUT   GPIOA_MODER_MODER0

or if I want Alternate Function 7 for that pin:

AF7    GPIOA_MODER_MODER0

I think you could still improve on the encapsulation (by the way, which is equally possible in almost any language...)
No need to remember that the register was named MODER, and repeat MODER twice, and no need to remember which numerical value meant "output", which was "input" and which was "analog". Abstract it away once!

I do, in C:

IO_TO_GPO(GPIOA, 0);

HI(GPIOA, 0);
LO(GPIOA, 0);

IO_TO_GPI(GPIOA, 0);
if(IN(GPIOA, 0))

IO_TO_ANALOG(GPIOA, 0);


I also do, in C:
IO_ALTFUNC(GPIOA, 0, 7);

Which sets the whole jazz, the MODER and the AF selection register.

All of this happens without any autogenerated code from my part -  my macros convert to the names used by the ST in their official header files. The defines for the above take 11 lines of code. Example definitions:

Code: [Select]
#define HI(port, idx) do{(port)->BSRR = 1UL<<(idx);}while(0)
#define LO(port, idx) do{(port)->BSRR = 1UL<<(16+idx);}while(0)

I certainly wouldn't want to bore you by being overly pedantic, but I haven't repeated MODER in the line "GPIOA_MODER_MODER0"
GPIOA = Peripheral
MODER = Register
MODER0 = Bitfield (bit 0)

I have tried other strategies, such as GPIOA_MODER0 but sadly the CMSIS-SVD naming that STM uses won' allow it due to some repetition of BITFIELD names withing the SAME REGISTERS, so I'm stuck with using the complete nomenclature above. I can't really criticize STM because of the *massive* numbers of bitfields, I mean someone HAS to screw up somewhere sometime ?

Once I would have loved your C code and system for handling MCU bitfields, but now as a Forth user, it looks very ugly and overly complex to me.
I'm not claiming it IS ugly and overly complex, it only looks like it to me because I don't want to abstract anything away, I want everything in plain sight and in what I consider to be the problem definition language of my creation.

"All of this happens without any autogenerated code from my part",  sure, but all your header files are auto-generated from CMSIS-SVD if you use ARM based chips.

I admit my initial config Words are totally technical and not fun to read, that's why they go in my config.fs file where they wont insult my eyes. Not that your C header files make pleasant reading either ;-)

Nevertheless I like "AF7    GPIOA_MODER_MODER0" very much as it's totally 100% descriptive, unambiguous and can be read by anyone who knows Forth, CMSIS-SVD and STM32F0 MCU hardware, intimately.

Thank you for pointing out in detail the C methods you use to do the same kind of things I do in Forth,


 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: starting with STM32 CMSIS
« Reply #53 on: July 24, 2019, 12:24:38 pm »
CMSIS-SVD naming that STM uses won' allow it due to some repetition of BITFIELD names withing the SAME REGISTERS, so I'm stuck with using the complete nomenclature above.

This is where language features are supposed to come to the rescue. C, for example, has this great thing called preprocessor, often overlooked as an ugly hack, but in practice, it can concatenate and create strings and work around with name issues.

I have an API which, in a write-once manner, automagically creates lookup tables which hold pointers with correct types to the data, size of said data, automagically calculated from the struct contents, and automagically created name string through preprocessor stringification.

But features are two-edged swords. Very few would disagree if I said that C++ has so many features in it that very few understands them all.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #54 on: July 24, 2019, 12:38:18 pm »
Quote
The whole line is autogenerated, it's a Bitfield Word *template* and takes the names from CMSIS-SVD. The actual Word 'name' is changed when pasted into a Forth program.
Could you explain more about how that works?  I would have thought that in order to retain the "interpreter" nature of Forth, you'd have to have all the words in the dictionary.  There are Forth "compilers" (that I'm not at all familiar with) that could do the same sort of templating or symbol translation that C++/C can do, but... that wouldn't be a Forth interpreter any more, would it?

Quote
I'm not pushing Forth here
Sure you are.  But that's fine; it makes us think...
I wish more of the "new" languages were as clearly DIFFERENT as Forth is willing to be, rather than just "well, this is like Java/C++/C/Pascal/Algol except we added a few concepts we really like, and this time the VM we're proposing will really be secure!"

Quote
I'm waiting for someone to create a 'Tethered Python', I think that may give C and Arduino a run for it's money
"Tethered"?   Adafruit is really pushing their "CircuitPython" (a derivative of MicroPython), and building boards that are capable of running it effectively (?) (at prices comparable with Arduino boards.)  Generally this means adding several megabytes of serial flash to hold the source-level libraries that a Python sketch is likely to need.  (and using at least a 48MHz ARM CM0 chip.  None of  this 8-bit nonsense.)

Python might qualify as "significantly different" from C/etc, but it's hard to tell how much is the language, and how much is the libraries.   Though perhaps the ability to write really effective libraries OUGHT to be a major reason to like a language.  I've felt that C falls apart for its inability to put data in libraries (ie "objects") effectively, and C++ seems to add feature after feature designed to allow the small subset of programmers who write really complex libraries to do so without stepping outside the bounds of the language (oh, the horror, if you should have to write part of a library in assembly language!")

I wrote a Python program that scrapes my favorite web-comic to my local disk.  So it has a constant "start page", downloads the the appropriate image and associated text, finds the "next" link, and iterates till done, plus waiting a "friendly" time (2-50 seconds) between each page, so as not to cause excessive traffic. It's 54 lines of code, including the "imports" of "well known libraries", comments, and a dozen lines of "test code that is no longer used" (but is useful for reminding me how I got the final product.)
I am ... impressed, and also horrified!

I'd love to try and explain this further, apologies in advance for the usual ambiguities, bad spelling and comprehension. Warning: LONG!

The Forth I use. Mecrisp-stellaris http://mecrisp.sourceforge.net/ comes as a binary ready to flash to the target MCU. By default it has a extensive Dictionary of Words as can be seen here: https://mecrisp-stellaris-folkdoc.sourceforge.io/words.html#id1

My CMSIS-SVD autogenerated peripheral memory map Words and my register bitfields are totally separate to Mecrisp-Stellaris and based on initial work by Ralph Doering
a few years ago.
My "svd2forth" stuff uses a XLST processor to generate the format I chose by processing any XML micro.svd file.

It's explained here: https://mecrisp-stellaris-folkdoc.sourceforge.io/register-generator.html#cmsis-svd

I develop as shown in this pic: https://mecrisp-stellaris-folkdoc.sourceforge.io/modern-forth-development-environment.html#a-modern-forth-ide

Basically I apply power to the hardware and see the Forth boot up greeting in the terminal window and  I know I'm ready to start.

So lets assume I'm interested in GPIOC-8, I can ether:
1) search the preopened bitfields template file ... too slow
2) scroll thru my preopened bitfields template file ... too hard
3) In Gvim :
   a) In insert mode, type first part of syntax and place cursor at the end of the search phrase i.e.
   : GPIOC_MODER_<-- cursor here
   b) Enter <ctrl x> <ctrl l> and up pops a list of similar words from bitfields.fs which contains every bitfield for the mcu listed.
   c) select desired line and hit enter and the following is inserted in my source
   : GPIOC_MODER_MODER8   ( %XX -- ) 16 lshift GPIOC_MODER bis! ;  \ GPIOC_MODER_MODER8    Port x configuration bits y =  0..15

Note: my system strips all comments "\ I'm a comment" from the source and uploads to the MCU at 460800 baud, (too fast to read).
4) I click on the "MAKE" icon in Gvim and my source is then uploaded to the MCU which then compiles it. I have only clicked MAKE, I haven't touched the terminal window or pasted anything to it etc. The makefile strips the comments and then uses a remote connection to GNUSCREEN to upload the code.

Any errors in the code will be flagged in RED text and the PC bell will beep to wake me up.

"GPIOC_MODER_MODER8" now appears in my Forth Dictionary in the MCU.
After this is done,  I can manually enter "INPUT GPIOC_MODER_MODER8" and hit enter in the terminal window and GPIOC-8 is instantly a INPUT.

I can also do that in the editor window but it wont take effect until the next MAKE.

To check that GPIOC-8 is now a input I can enter : "gpioc_moder." and I'll get a nice pretty printed register state as below (taken from a working system where bit 7 has been configured as a INPUT in exactly the same way.

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

Tethered Python:
Forth can run standalone on the target MCU as Mecrisp-Stellaris does. This means the MCU needs to have enough Flash to hold the 20KB Forth binary plus room for the user code. I use the STM32F051 which has 64KB Flash. A 1K line Forth program is considered long, So I have tons of room.

This is where C wins hands down because a C 'blinky' may be as small as 300 bytes but a Forth Blinky would probably need 20030 Bytes, substantially more.

However we also have 'Terthered Forths" where a HOST contains all the intelligence and is "tethered' to a TARGET chip with a cable supplying power and JTAG etc.
In this case the Forth Terminal appears to be talking to the Target, and interaction exactly like I have described above can take place when in "target' mode. GPIO's can be set, cleared tested and so on.
However the actual target code speed will be slower than if Forth was running on the target.

The payoff is that this competes with C in optimizations and code size on the target so a "Blinky" done this way in Forth would probably be a binary size of 80 bytes for the complete standalone self booting image with all the init code, interrupt vectors etc. It's also a binary file, no Forth, no terminal for your customers or competitors to play around with. You're also not bound by the GPL license regarding binaries you produce with it.

The HOST can  be instructed to produce a standalone binary file at any point and flash it to the target.

We actually have a working Tethered Forth here: https://mecrisp-across-folkdoc.sourceforge.io

The really cool thing is that the HOST is a Ti Tiva Connected Launchpad which cross compiles (using Mecrisp-Stellaris) for a Ti MSP430 TARGET :)

Now I see no reason that a 'Tethered Micro Python" shouldn't exist and work the same way, then it too can produce binary file sizes as small as it can optimize.

This would mean that small Flash chips with say 16K could be used by a Tethered Python just like C or a Tethered Forth.

Note: Mecrisp-Across, our Tethered Forth works perfectly with a virgin MSP430 straight out of a new factory tube, no code is preloaded, the chip is totally blank. In other words, no bootloader or anything.

Python Web scraper:
Awesome, I'm not a big Python fan, I don't like the whitespace terminators, but I'm not criticizing Python, I use and love some indispensable apps that are written in Python so it is clearly very capable and coder friendly.

Python is certainly the Poster Child of the Revolution these days hence my surprise that no Tethered Python for small MCU's exists that I know of.

I'm slowly learning LISP which represents my highest HLL language aspirations as a electronics technician. LISP is the closest cousin to Forth one can find in that they are both able to reprogram themselves.

By that I mean the Forth Word ": + - ; " when executed like this:

2 2 + .  ( 2 + 2 then print the result with . )

Will give zero and not 4. Why would you want to do this, I wouldn't but it demonstrates what I said above. Try that with your language of choice, can you redefine + as - ?

 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #55 on: July 24, 2019, 12:50:37 pm »
CMSIS-SVD naming that STM uses won' allow it due to some repetition of BITFIELD names withing the SAME REGISTERS, so I'm stuck with using the complete nomenclature above.

This is where language features are supposed to come to the rescue. C, for example, has this great thing called preprocessor, often overlooked as an ugly hack, but in practice, it can concatenate and create strings and work around with name issues.

I have an API which, in a write-once manner, automagically creates lookup tables which hold pointers with correct types to the data, size of said data, automagically calculated from the struct contents, and automagically created name string through preprocessor stringification.

But features are two-edged swords. Very few would disagree if I said that C++ has so many features in it that very few understands them all.

I'm definitely agreeing with you that C/C++ is complex and gets more complex as bits are tacked onto it to do everything. It's far too complex for me.

I don't need to use anything but my XLST processor to fix the problem at it's source, (and I've been tempted) but what would be the result ?

NON STANDARD CMSIS-SVD which would make my Forth Source unique and non-standard. My source code wouldn't match the technical references, it would be a abhorrence, a misshapen ugly thing that the Forth crowds would burn at the nearest stake with me beside it.

So I won't be doing that anytime soon. But really, it's not overly onerous, I just use the full CMSIS-SVD nomenclature, automatically.

Then my only problem is reading your complaints that it's too long ;-)
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #56 on: July 24, 2019, 01:01:20 pm »
If you're interested in the hardware itself why use the 'C' programming language, it's not made for hardware interaction.

The Forth programming language is made for hardware interaction yet allows the programmer to start at the bare metal and proceed to the actual Problem Definition Language as they go.

Mecrisp-Stellaris Forth happily uses CMSIS-SVD and we have a parser for all the various STM32 chips.

The syntax is consistent and takes the form of "peripheral_register_bitfield" for example to set GPIOA-10

: GPIOA_BSRR_BS10   %1 10 lshift GPIOA_BSRR bis! ;     \  Port A set bit 10

Then executing "GPIOA_BSRR_BS10" sets Port A set bit 10, providing it is set as a OUTPUT elsewhere.

This is just one way and there are many alternative choices, but no HAL, no C compiler and no assembler are required with Forth, you talk to the chip directly via a serial terminal in real time INTERACTIVELY.

All due respect, but the vast majority of embedded systems don't sit there and wait for a user to type in an obscure command so they can toggle the state of an LED.

Sure, we've all done designs which have a serial port that connects to a terminal emulator and we use that to send commands and such, but that's just it, we send commands that are parsed by the micro to do something useful. For example, a thing on my bench right now has a TEC. I can send it a command to turn the cooling off and on. I can send it another command to set the temperature set-point. The micro itself runs the cooling loop, reading the temperature on a periodic basis and then updating the current through the TEC. No user interaction required, or even wanted!

I certainly do not send it individual commands to read the temperature and then use that to update a PID controller I have elsewhere!

Another thing I am working on uses a USB-MIDI interface to take messages from the computer to set up some hardware and then if the user pushes a button or turns a knob, messages are sent back to the computer. Please, show me a USB stack written in Forth.

We extensively use Ethernet interfaces in many designs. Show me a tcp/ip stack written in Forth, and tell us why that's better than C.

The notion that we can put a Forth interpreter in the micro (how much code and data memory does this require, anyway) is interesting if we want a debug monitor, but we have JTAG and SWD and they're both superior to an interactive monitor in so many ways.

I lost interest replying to you after reading your first line.

Instead of pointless diatribe with me, perhaps you'd be better off rechecking that your workers haven't been snipping bits from your prized and inordinately expensive roll of "oxygen free, silver plated, HIFI loud speaker wire" ... again.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #57 on: July 24, 2019, 01:10:10 pm »
I have to ask, do you have any recent experience configuring modern MCU's with thousands of Bitfields ?

you argue that forth isn't an obscure language that few use because it is used in bootloaders

using the same logic the billions of people who use a computer or cellphone have recent experience configuring
modern MCU's with thousands of Bitfields

Actually Oracle had this to say about Forth "Said Oracle @ https://docs.oracle.com/cd/E63648_01/html/E63649/gpsgy.html
"The OpenBoot CLI is based on the industry-standard interactive programming language called FORTH.Combining sequences of commands to form complete programs provides the capability for debugging hardware and software."

You'd think Oracle would know ?

Using your logic the billions of people who use a computer or cellphone have recent experience programming not-Forth ?
 

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 4392
  • Country: dk
Re: starting with STM32 CMSIS
« Reply #58 on: July 24, 2019, 03:02:54 pm »
I have to ask, do you have any recent experience configuring modern MCU's with thousands of Bitfields ?

you argue that forth isn't an obscure language that few use because it is used in bootloaders

using the same logic the billions of people who use a computer or cellphone have recent experience configuring
modern MCU's with thousands of Bitfields

Actually Oracle had this to say about Forth "Said Oracle @ https://docs.oracle.com/cd/E63648_01/html/E63649/gpsgy.html
"The OpenBoot CLI is based on the industry-standard interactive programming language called FORTH.Combining sequences of commands to form complete programs provides the capability for debugging hardware and software."

You'd think Oracle would know ?

Using your logic the billions of people who use a computer or cellphone have recent experience programming not-Forth ?

just because oracle says it industry standard doesn't make not obscure, very very few people are programming forth for bootloaders 
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1663
  • Country: us
Re: starting with STM32 CMSIS
« Reply #59 on: July 24, 2019, 05:13:29 pm »
Firstly there is no such thing as a "industry standard programming language for embedded systems".

Okay, call it the de facto industry standard, then. It's clear that the majority of professional (that's what I meant by "industry") embedded development has been and is still done in C.


Quote
Some reasons why Forth will never be popular, and why C is very common in my opinion. Not in order of significance:

Standardization:

Why is this an issue for Forth? Forth has been around longer than C, so why isn't it standardized to the same degree C is? Doesn't the IEEE, ANSI, ISO, etc., care about this?


Quote
Marketing:
C is easy to market as mentioned above but Forth is not, and never will be.

Why isn't Forth easy to market? What is it about the language that make it unmarketable?

Quote
Arduino:
Arduino brought thousands of hobbyists to C.
Until the advent of Arduino, embedded was not trivial, a designer had to do the hard yards before they could even get a MCU to boot. Arduino brought artists and hobbyists flocking to their easy to use system, complete with 'libraries'. Want to run a stepper motor, no problem, grab a ULN2003, a 'sketch' and step away!

I'm not talking about hobbyists here--I'm talking about professional embedded developers, who don't typically use Arduino hardware or software. Sure, Arduino made it easy for hobbyists to get into embedded programming, but that was never an issue for professionals. Professionals will learn whatever they have to to get the job done, no matter how difficult it may be.

Quote
LIbraries:
Like Cargo Cultists, C users eagerly await the latest libraries to drop from the sky, "please God bring me a library that allows me to

Again, that may be true for amateurs, but professional developers generally don't care about libraries. Every company I've worked for in my 35 year embedded career did not use vendor libraries--we wrote our own peripheral driver code from scratch. Most vendor libraries are utter crap anyway.

Quote
Interactivity:
Only Forth is interactive, C is not. So Forth is the clear winner in the interactivity category.

Interactivity, or lack of it, has never been an issue in professional embedded development. A good debug environment provides all that's necessary here. Nowadays that's JTAG interfaces to debug capabilities built into the MCU; back in the day it was in-circuit emulators.

Quote
Why Forth will never be  be mainstream or popular, but will forever be a niche programming language in my opinion:
1) Forth is like the TAO, it is a way and is only understood when practiced.

This sounds like metaphysical mumbo jumbo. Perhaps that's why Forth has always had the reputation of being a "hippie" language in the professional development circles I've worked in.

Quote
2) Forth is easy to learn, but hard to master, it requires a different mindset.

Why is it hard to master? Perhaps that should tell you something about the design of the language...

Quote
3) Forth is a Chameleon, it is like a stealth aircraft which looks different from every angle. Even the creator of Forth said, when asked "what is Forth" ... " I can't really say, but I know it when I see it"

This, IMO, is the chief reason why Forth isn't taken seriously by the embedded community.



Quote
These are all valid forth Words (subroutines, functions etc):

And I thought Perl looked like line noise. Sheesh...

Quote
I debate 'C' Language pushers who have no real clue about Forth and attack it in order to justify their mistaken belief that 'common' also means 'best'.

Common doesn't mean best, but C has stood the test of time whereas Forth has not. C has perpetually been at the top of the professional embedded development language lists, while Forth is lost in the noise. A rounding error.
Complexity is the number-one enemy of high-quality code.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14299
  • Country: fr
Re: starting with STM32 CMSIS
« Reply #60 on: July 24, 2019, 05:48:18 pm »
Yes that was a good one. A bit of shameless advertising. ;D

Was that directed at me ?

Well, yes. No offense! I chose not to reply further, as I thought this would just all end up ruining the thread for no benefit to the OP, but the thread has seriously gone popcorn-worthy, so I'm replying now.  :popcorn: And then this is probably the polite thing to do.

Mecrisp-Stellaris is Free and Open Source Software, licensed under the GPL. It's totally Free to download and use.

I'm not 'advertizing' it, I'm announcing it's existence and benefits to those that may find it useful, specifically the OP of this topic.

Just because it's open source doesn't mean advertising doesn't apply. "Promoting" may be a better word here? Alright, promoting it will be.

Had you not introduced your post with this:
Quote
If you're interested in the hardware itself why use the 'C' programming language, it's not made for hardware interaction.
which I think was pretty off and made some of us chuckle, I would probably have not posted what I did. You're entitled to your opinions, but this one was a bit too much. ;D

The other point is that you would probably have made a better point and sparked much more interest if you had kept your initial post shorter and more neutral, even though, given the original title and questions of the OP, it was already a little off-topic IMO.

The following posts unfortunately didn't help. Looks like the thread is now ruined beyond repair, so I'm not going to discuss technical points regarding the merits of Forth further in this thread as others have. ;D

Maybe try and be a little less offensive and take things a little less personally.
I would also suggest you opened a dedicated thread instead . I'm sure that would work way better and maybe spark genuine interest instead of triggering hostile replies.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #61 on: July 24, 2019, 11:38:00 pm »
Yes that was a good one. A bit of shameless advertising. ;D

Was that directed at me ?

Well, yes. No offense! I chose not to reply further, as I thought this would just all end up ruining the thread for no benefit to the OP, but the thread has seriously gone popcorn-worthy, so I'm replying now.  :popcorn: And then this is probably the polite thing to do.

Mecrisp-Stellaris is Free and Open Source Software, licensed under the GPL. It's totally Free to download and use.

I'm not 'advertizing' it, I'm announcing it's existence and benefits to those that may find it useful, specifically the OP of this topic.

Just because it's open source doesn't mean advertising doesn't apply. "Promoting" may be a better word here? Alright, promoting it will be.

Had you not introduced your post with this:
Quote
If you're interested in the hardware itself why use the 'C' programming language, it's not made for hardware interaction.
which I think was pretty off and made some of us chuckle, I would probably have not posted what I did. You're entitled to your opinions, but this one was a bit too much. ;D

The other point is that you would probably have made a better point and sparked much more interest if you had kept your initial post shorter and more neutral, even though, given the original title and questions of the OP, it was already a little off-topic IMO.

The following posts unfortunately didn't help. Looks like the thread is now ruined beyond repair, so I'm not going to discuss technical points regarding the merits of Forth further in this thread as others have. ;D

Maybe try and be a little less offensive and take things a little less personally.
I would also suggest you opened a dedicated thread instead . I'm sure that would work way better and maybe spark genuine interest instead of triggering hostile replies.

You are indeed very polite in your response, it's so sweet the saccharin is dripping down my screen and leaving a bitter aftertaste.

Promoting Free technology isn't a bad thing. Promoting happens all the time here with free giveaways and all manner of sly commercial advertising. Do you want this forum to operate in a technical monoculture full of C users who only discuss C and whom many have no clue what CMSIS really is  ?

Maybe you do, because in your only post to the OP, you wrote "Declaring each register individually is of course possible, but it would look kind of clunky: eg: GPIOA_BSRR (well to each their own)". How have you helped the OP gain understanding of CMSIS ?

The OP, regarding CMSIS in his post: https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-cmsis/msg2550690/#msg2550690  asked "... I just need to find which register is should talk to (im assuming its something like GPIOA) but i can't find that information anywhere in the stm32f407xx.h file linked in the CMSIS and I can't find an authoritative resource anywhere online that tells me either ...".

I have TONS of information about CMSIS-SVD on my site, and I have a great deal of experience parsing CMSIS XML with XLST to provide output to suit *any* language used for embedded.

You accused me of 'promoting' when I linked it this information here, so I must disagree that this topic has drifted seriously off topic.

If the OP wants to use CMSIS on the 'bare metal' there is no better solution than Forth, or even Assembly Language. Forths advantage with CMSIS is that it is *INTERACTIVE* in real time, unlike Assembly Language ( or C). The OP said he wanted to " start programming the STM32 chips " and if he begins with CMSIS and Assembly then he is in for a very LONG and frustrating learning curve.

I have tried to explain my poor choice of words over the conceited chuckling I hear from C some users. Of course C interacts with hardware, however C is not 'interactive' in the accepted meaning of the word.

I'm not interested in garnering Forth interest, my post was about CMSIS. I couldn't care less if you don't use Forth (which has been around since the late 1960's).
If you re read vixo's post again you will see he if after information on how to use CMSIS and that my post directly addresses CMSIS at the bare metal level in this link.
https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-cmsis/msg2550690/#msg2550690

If any C (only) users here are feeling offended, foaming at the mouth and turning green while reaching for the keyboard, do yourself a favor, learn some other programming languages like LISP, Haskell or Ocaml. Expand your mind because there is a world of software and capabilities out there that you can't currently imagine.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: starting with STM32 CMSIS
« Reply #62 on: July 25, 2019, 06:17:57 am »
It is kinda true that C is not made for hardware interaction. Originally, C was designed as a high-level language, to write programs that access OS services through standard libraries. Even the built-in datatypes had random, incompatible widths, no hardware interoperability in mind. C just developed into a strange mix of high-level, and hardware interaction language, mostly inofficially, and it shows in standardization.

But does this matter? I think the actual state of things is more important than historical intent; although understanding the historical context can be interesting.

Standardization and marketing are not strong points of C. Standardization is lazy, sucky, and leaves a lot of work for non-standard extensions and outright "abuse" of standards. Now this isn't a too big of a practical problem, we just do it that way and call it a day, but purists don't like it. And marketing, what marketing? C was never very trendy.

The thing with C is, there are very few or no fanboys. I have never heard anyone calling C "elegant". Everyone says "it's just what we use" or "it's acceptable", or "good enough". No one finds it soothing or tao.
« Last Edit: July 25, 2019, 06:23:03 am by Siwastaja »
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: starting with STM32 CMSIS
« Reply #63 on: July 25, 2019, 08:50:02 am »
It is kinda true that C is not made for hardware interaction. Originally, C was designed as a high-level language, to write programs that access OS services through standard libraries. Even the built-in datatypes had random, incompatible widths, no hardware interoperability in mind. C just developed into a strange mix of high-level, and hardware interaction language, mostly inofficially, and it shows in standardization.

But does this matter? I think the actual state of things is more important than historical intent; although understanding the historical context can be interesting.

Standardization and marketing are not strong points of C. Standardization is lazy, sucky, and leaves a lot of work for non-standard extensions and outright "abuse" of standards. Now this isn't a too big of a practical problem, we just do it that way and call it a day, but purists don't like it. And marketing, what marketing? C was never very trendy.

The thing with C is, there are very few or no fanboys. I have never heard anyone calling C "elegant". Everyone says "it's just what we use" or "it's acceptable", or "good enough". No one finds it soothing or tao.

I have to agree that the actual state of things is more important than historical intent.

Back in the day, here in Australia, Borland C for DOS was everywhere in shops, along with bookshelves packed with every kind of C book. Maybe it was different elsewhere.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf