MPLAB X a PIC inhibitor! Alternatives ?

[NorthGuy]

What about libraries ?
Sometimes you need something ready

... you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Me too. I'll take well documented hardware datasheet over black-box libraries at any time.

[mikeselectricstuff]

What about libraries ?
Sometimes you need something ready

Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

This. x1000000

[technix]

What about libraries ?
Sometimes you need something ready

... you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Me too. I'll take well documented hardware datasheet over black-box libraries at any time.

Gee the “you need to use libraries” mentality...

I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible so you don’t have to deal with low level stuff. I am not seeing the point here as the vendor libraries are not that much of an abstraction, do things you are not sure, and can be bloated AF.

There was even a thread complaining about losing SWD connection on STM32 with Cube-generated library code. Neither the OP or me have any idea what was going on, since nobody bloody knows what is going on inside the vendor libraries. The library might disabled SWD during initialization and despite the application enabling it later (also in generates code) the connection is already down. And don’t get me started on the extreme bloat that is known as STM32Cube. Bloody hell. AFAIK the ASF and Harmony isn’t any much better. Float point arithmetic just for I2C baudrate calculation? I am kind of okay with this if you are using Cortex-M4F hard float ABI (so guaranteed existence and access to FPU) bit on a M0? Are you kidding me?

[Siwastaja]

I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible so you don’t have to deal with low level stuff.

They just don't have a freaking clue about what they are talking about, they have no experience, no understanding, no knowledge.

I have gone through that battle too many times in the past. It simply doesn't make sense to argue with them. I have never seen a working system made by those people, except some hello world led blinkers on a demo board. And to make that led blink through the library, they can waste weeks, it's not a problem since it's supposedly "saving time in the future".

99% of the time, what is called a "library" is simply an utter disaster, made by idiots for idiots, wrapped into huge complexity and poorly written code, but nothing fancy going on.

Although, 1% of the time, there are quite some nice things you can use.

BTW, to some degree, this even applies to PC software side. Of course, the things are more vague there, as much higher software complexity often necessitates some library usage. Still, this only makes it even more important to focus on the quality, not quantity, of the libraries.

[mikeselectricstuff]

I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible.

That says a lot about how Chinese firmware gets done-throw some libraries together instead of using any original creativity.

[picdev]

On my last project I had to work with a big protocol.
So at first I worked with the simple UART functions of mikroc .
Later I write my own uart functions with interrupt for tx and Rx , I used also buffers etc.
I wirte my own task manager and I made a lot of work from scratch.
But mikroc libraries help me to start.

Also we speak about 16bit mcus,
How about stm? Is it possible to write your own libraries on such  complicated arm MCU ?

Sent from my Redmi 4 using Tapatalk

[FrankBuss]

Float point arithmetic just for I2C baudrate calculation? I am kind of okay with this if you are using Cortex-M4F hard float ABI (so guaranteed existence and access to FPU) bit on a M0? Are you kidding me?

I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.

[Siwastaja]

How about stm? Is it possible to write your own libraries on such  complicated arm MCU ?

Not only possible, but practically mandatory for the development to be "sustainable" - the ST-provided libraries are total joke. The STM32 libraries don't offer much or any abstaction (which is the whole point of using libraries in the first place) -- instead, they wrap every configuration register access to a more complex, bloated boilerplate, you still need to exactly know what configuration registers to access in what sequences, just instead of 10 lines you use 200 lines to do the same. Needless to say, no one writes that kind of code from scratch - just writing the code to change an IO pin to an output would take minutes, and it'd be impossible to remember how all the configuration structs and functions were called - that's why it's either copy-pasted from example files, or forum posts; or autogenerated with code generation tools.

Or, like sensible people do, don't use that shit.

I can understand your notion that higher complexity requires something "better" than total "DIY". While this would be true in the ideal world, in real world, the libraries more often end up increasing complexity. And the more complex something is to begin with, the more important it becomes that this complexity is not increased even more. In practice, this means: either use very high-quality abstaction layers/libraries or do your own. In STM32, it's the latter.

But, in the end, you can, and I certainly do, write STM32 code exactly in the same manner I have been doing 8-bit AVR code since forever: look at the reference manual, configure the registers. For example, setting an IO pin as an output is:
(1) In AVR: 1 bit written in 1 register
(2) In STM32 "bare": 2 bits written in 1 register, and remember to turn the port clock on first (1 bit in 1 register).
(3) In STM32 "libraries": about 10 lines of building a configuration structs with long names and passing them to functions, you need to remember everything correctly or copy-paste it.

I'm sorry to say this but using such a complex product (especially with STM32 with dozens of pages of errata, with a lot more officially undocumented) results in so many strange issues to be debugged that you absolutely need the skills and mindset to thoroughly crawl in the mud through the reference manual - even if you used a library. And with the library, you have more code to reverse-engineer while doing this. Instead, you need to be building piece by piece, bottom up.

I like looking at the library code as a reference when I'm stuck and nothing else helps, but this rarely happens, and it rarely helps, since the libraries do not actually do much, are often limited in functionality, poorly designed, or outright broken by design.

[mikeselectricstuff]

How about stm? Is it possible to write your own libraries on such  complicated arm MCU ?

Why would it not be.
One peripheral at a time.

[mikeselectricstuff]

I like looking at the library code as a reference when I'm stuck and nothing else helps, but this rarely happens, and it rarely helps, since the libraries do not actually do much, are often limited in functionality, poorly designed, or outright broken by design.

And IME libraries are often a big mess of multiple-level #defines and macros in way too many files so it's often very difficult to figure out what they're doing - just figuring out what constant ends up being written to a register can be quicker to do by reading it back & spitting it out of a serial port than working it out by looking at the code.

[westfw]

I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.

In fact, the avr-libc "_delay_ms(float time)" is VERY EXPLICITLY DOCUMENTED to require that "time" be a compile-time constant AND that you have enabled enough optimization to make sure that the various calculations all happen at compile time:

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

(This doesn't stop it from biting someone a couple times a year...)

[mikeselectricstuff]

I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.

In fact, the avr-libc "_delay_ms(float time)" is VERY EXPLICITLY DOCUMENTED to require that "time" be a compile-time constant AND that you have enabled enough optimization to make sure that the various calculations all happen at compile time:

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

(This doesn't stop it from biting someone a couple times a year...)

And does the macro generate a compile-time warning of these conditions are not met ?

[technix]

I saw this for an ATTiny delay calculation as well. No way that this fits in 2k flash, so the compiler probably optimized it at compile time to a constant, which should be possible if you use constants as the arguments.

In fact, the avr-libc "_delay_ms(float time)" is VERY EXPLICITLY DOCUMENTED to require that "time" be a compile-time constant AND that you have enabled enough optimization to make sure that the various calculations all happen at compile time:

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

(This doesn't stop it from biting someone a couple times a year...)

And does the macro generate a compile-time warning of these conditions are not met ?

They do.

Although I am wondering for the fork that requires GCC 5, why not surround that code in attribute((optimize("-Os"))) or the like so the compiler knows that this bit of code must be optimized disregarding the command line settings?

[technix]

I recently got into a bit of squabble on a Chinese embedded developers forum regarding the use of vendor-provided libraries. The other commenter insists that you should always use as much if the vendor libraries as possible.

That says a lot about how Chinese firmware gets done-throw some libraries together instead of using any original creativity.

You kind of expect it from an engineer that is paid $5 an hour or less, and from bosses that have no intention of maintaining their products after release (not even past the 1.0-itis.) If I am tied down to a job paying $5 an hour with 72-hour weeks, how can I have the time or resource to perform the in-depth thinking and experimenting that is required for original creativity? I don't have a day job for now, not because I am not interested in work, but because the job offers I get ended up making me fell less human. I might get a teaching license if this kind of offer is still running rampant.

And way too many people try to copy others' work (hence the need of heavily fortified MCU's and the abundance of "MCU decryption services") to make quick money. Yes electronics in China are cheap, but it comes with the cost of heavily undervaluing human intelligence and violation of intellectual properties.

A lot of people in China have weak to none moral compasses, and wherever there is money there will be a lot of sort-of-rich people dragging their employees into grabbing quick money from it. Nobody bloody want to use any original creativity, since nobody values it anyway; and nobody can use original creativity, as they are prevented from having any in the first place.

[KL27x]

Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Thanks, Karel, for posting this.

I am self-taught and work in a bit of a vacuum. All this time I thought I was bad at coding for writing all my own code, rather than "simply" reading and understand and altering premade libraries. (Also, after a few hours of trying to grasp USB, I noped out of it.) 

Your post and the host of followups from other members who I look up to has made me feel a little less retarded, today.

[technix]

Apart from USB and TCP/IP-stack, you write them yourself. At least I do. If there's a bug, I can blame myself instead of others.
Besides, what you have made, you can fix. The time I need to read and understand somebody elses code, I can write it from scratch.

Thanks, Karel, for posting this.

I am self-taught and work in a bit of a vacuum. All this time I thought I was bad at coding for writing all my own code, rather than "simply" reading and understand and altering premade libraries. (Also, after a few hours of trying to grasp USB, I noped out of it.) 

Your post and the host of followups from other members who I look up to has made me feel a little less retarded, today.

USB and TCP/IP are the two big complicated protocols you may want to stick to a library with, but for everything else you might be better just start from scratch. You won't want to risk it with USB or TCP/IP, since USB libraries are hard to write without an (likely expensive) USB protocol analyzer unlike SPI or I2C that most oscilloscopes (ex. Rigol DS1054Z after the hack) can decode, a bad USB library can make the host computer crash, and a bad TCP/IP library leaves you vulnerable to hackers. All pre-made libraries have their strengths and drawbacks though, and you need to choose and discard them based on what you need.

For example I know that a good portion of Chinese STM32 engineers feel that STM32Cube+FreeRTOS is the best support library for STM32 ever and they don't even talk about coding bare metal. However I found that setup bloated and just throws it away in favor of my own stack (temporarily named DreamOS-RT but not quite linked to my own DIY OS project DreamOS.) that implementes a few modified Arduino interfaces.

[Bruce Abbott]

All pre-made libraries have their strengths and drawbacks though, and you need to choose and discard them based on what you need.

And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

A good portion of Chinese STM32 engineers feel that STM32Cube+FreeRTOS is the best support library for STM32 ever and they don't even talk about coding bare metal. However I found that setup bloated.

Bloated for sure, but who has the time and skill to write everything themselves?  Just throw more memory and a faster CPU at it!
 

[mikeselectricstuff]

And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

For often inferior values of "job done"

[Siwastaja]

And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

This is often a fallacy. It's touted often enough that people actually believe it, like it's some kind of law of physics, never questioned.

It's true with exceptionally good libraries - or in the case of extreme underlying, inevitable complexity that must be there. (TCP/IP or USB stack might be usable examples.)

However, most libraries are horribly bad and only end up wasting everyone's time. And, most of the time, they only solve trivial problems. Especially in embedded. In embedded, they often are unusable as is due to the highly hardware-dependent implementation; sidestepping this issue requires extremely good library design skills, rarely seen.

Indeed, in some cases, the design flow of "use random libraries, copypaste random code from the Internet or example files, try random things until it works" is used. This allows people with substandard skills and no experience in programming to produce something - but most of the time, they just talk big and fail to provide anything at all. Even if they eventually do provide, this design flow is not "easy" or "quick" at all. I have overseen stunts like this too many times, and it's not uncommon at all to spend weeks of combining those libraries to get a Minimum Viable Prototype (version 0) out. They just genuinely think it's inevitably that hard, and they actually believe that the libraries "helped" them and it would have been years without, since they have bought the law: "libraries make hard things less hard" without questioning its context.

Typically, I can deliver similar minimum viable software prototype in about a day or two. (Sometimes, these two-day coding session products end up being in heavy production use for years without touching ).

Can't do that with "libraries", unless you happen to find a finished example application exactly designed for that purpose. If one exists, by all means use it. Heck, if you can go out and buy the thing, do that. But I'm called in when someone needs something that doesn't exist.

Good programmers/developers/designers are rare. It's attitude like this (false sense of laziness, you think you save time, but you actually waste it, especially in the long run, since you prevent yourself from learning anything) that keeps this number low.

Real, succesful laziness keeps us innovating. How to make things quickly in the long run? The answer: don't muscle it, do it wisely! Understand what you are doing!

[hans]

And what most people need is the quickest easiest solution that gets the job done - which is why they use libraries.

In embedded, they often are unusable as is due to the highly hardware-dependent implementation; sidestepping this issue requires extremely good library design skills, rarely seen.

Indeed, software developers like to write generic solutions for problems, especially when it can be platform independent. This has brought us good things, like programming languages such as C, but perhaps also bad things, like overgeneralized solutions. Matching this with hardware often doesn't make sense, because a few examples:

1) Not every microcontroller pin is connected to the analog mux for ADCs or "output" PWM. Some libraries imply every pin can be read analog. See further.
2) More specific example: on STM32F4 not every DMA stream/channel is mapable to any request, and even multiple peripherals share the same channel, thus blocking some multi-DMA setups from working all together. Does a software library assert these limitations and perform preferably compile time checks on this? Is C expressive enough for these static checks? Woops!

Example on 1): take Arduino libraries. These are often praised for throwing together a quick prototype. Let's look at analogWrite: https://www.arduino.cc/reference/en/language/functions/analog-io/analogwrite/
The "contract" for this function, at first glance, seems to be relatively simple:

Parameters
pin: the pin to write to. Allowed data types: int.
value: the duty cycle: between 0 (always off) and 255 (always on). Allowed data types: int

Returns
nothing

But then see the following mess:

On most Arduino boards (those with the ATmega168 or ATmega328P), this function works on pins 3, 5, 6, 9, 10, and 11. On the Arduino Mega, it works on pins 2 - 13 and 44 - 46. Older Arduino boards with an ATmega8 only support analogWrite() on pins 9, 10, and 11.
The Arduino DUE supports analogWrite() on pins 2 through 13, plus pins DAC0 and DAC1. Unlike the PWM pins, DAC0 and DAC1 are Digital to Analog converters, and act as true analog outputs.
You do not need to call pinMode() to set the pin as an output before calling analogWrite().

Makes me wonder, what actually happens if you chose an invalid pin? This could happen because you upgraded from a Mega to a Due board.. The documentation doesn't say much.. well actually this happens:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/wiring_analog.c#L284
Great 1-bit analog output. In pragmatic ways; yes this is the best one can do. But this kind of undefined internal behaviour can drive a programmer crazy.
Not to say some of the side effects functions can have, e.g. this forces the I/O into "output" mode. What happens if you actually had set it up as an open-drain PWM? Is that now disabled?

If you look at e.g. CMSIS libraries; there was a question if these can be written yourself. Yes they can. It's actually not that much more complex than on a PIC microcontroller; it's just there is a bit more to do. But I don't define that as immediately "complex".
That is because these libraries internally contain almost no state whatsoever. Their functions are just 'convenient' functions to use peripherals, if they contain no spelling mistakes, errors, abuse of floats, etc. (which in my experience is not uncommon, no vendor excluded)
Maybe convenient is not the right word, let me rephrase: they contain some 'mechanical' operations to push a set of values into registers. In many cases you can still mix flags between peripherals (like interrupt flags); as long as the "bits" it's accepted. They are not dummy proof.

When you're designing a system that uses peripherals in a clever way, like a combination of UARTs, SPIs, timers, DMA, interrupts and clock control, you may dive deep into datasheets to find out what operation modes each peripheral should run. While you're at this level, you might as well push these settings into registers yourself.. it's not that much effort anymore.

And if you're really uncomfortable how a peripheral works, there is always a cheat sheet.. namely github.com and CMSIS itself. But don't take any piece of code by heart. Think critical about design decisions. Sure a floating point type will work for baud rate calculation. Maybe it was the easiest solution to a fractional baud rate division calculator. But alternative algorithms exist.
And perhaps you don't even require these run-time calculations of baud rate.. just punch your clocks into a calculator and hard code the numbers. If you're quite pragmatic and worry about documenting your chosen values, this can work reasonably well..

[Bruce Abbott]

Good programmers/developers/designers are rare. It's attitude like this (false sense of laziness, you think you save time, but you actually waste it, especially in the long run, since you prevent yourself from learning anything) that keeps this number low.

And it will always be this way because the vast majority are not good programmers/developers/designers, they are just average schmucks trying to make a living. These people will never be able to write good code themselves, but they can produce (mostly) working code using libraries. If that keeps them employed then - mission accomplished!

Real, succesful laziness keeps us innovating. How to make things quickly in the long run? The answer: don't muscle it, do it wisely!

Real, successful laziness means using other people's code rather then taking the time to write your own.

Understand what you are doing!

...is unnecessary. You only need to understand just enough to get your code to (mostly) work.

[Siwastaja]

Bruce Abbot, you have completely given up hope, without realizing it, and are just rationalizing it. I'm so sorry for you.

I'm not questioning the "just get the job done quick&dirty" attitude. I work that way. Our current company motto is "good enough", coined by me.

It's just that you are simply&plainly wrong about how to achieve that target.

While I agree it's not for everyone, becoming a decent (not necessarily great) programmer is not rocket science. I can do it, you can do it, many of those "hack something together with copypasta code" people can do it, because they do have the persistence. I know this because I have seen how difficult, slow and unrewarding it often becomes to build software that way. They only need to find the root cause to their issue and fix that, and their next project will be quicker and easier - and more satisfying. This satisfaction will also keep them in the business, making a living in the long run, too.

Personal story: before I found out that the way I'm doing this is exactly right, I also did live the phase of questioning: "I'm doing something wrong, must use moar libraries!" When I accessed HD44780 display for the first time, I spent a few hours trying to find a library and to get it to work. Nothing, did it from scratch, took maybe half an hour. Which one was quicker? Two hours - no result, or half an hour - working project?

The same happened later with the DS1820 temperature sensor. This is more complex than HD44780, I surely need to use a library to speed up my design, I just want this to work as quickly as possible! Logical motivation, makes sense. So, again, trying to find a library, tried two or three libraries, wasted a full day (maybe 10 hours), nothing works at all, can't find the reason, not enough skills to debug through the massive library code. Next day, write my own from scratch, about 6-7 hours later working just as expected. Again, which one was quicker?

The comparison is meaningless, since in these cases, the "reuse existing code" solution didn't work at all, ended up just wasting my time. I don't know how long it would have been taken to get that DS1820 to work, but watching others do the same using the copypasta method (and me helping them out to get it work), I'd expect about a week.

And I was somewhat a beginner at that point. If I redid the same test now, I could probably find out why those libraries did not work much quicker, and actually make them work in some manageable time, like a day or two. On the other hand, making the own solution has become even easier for me.

Another personal story: at the local electronics club, I have "overseen" one particular guy who started from absolute scratch about two years ago. He came and started asking about Arduinos, and I told him: forget all the libraries, here's the datasheet. Now, he's been the fastest learning guy I've ever seen. After a few months, he made his own software-controlled boost DC/DC controller. A few months later, a coffeemaker controller, with strain gauge + his self-designed amplifier circuit for it to measure the amount of coffee, RTC chip, with ESP8266 control over WiFi and all kinds of interesting features and modes. Horrible hacked up stuff held in place with hot melt glue, but a lot of innovation in no time. This innovation and quick development cycle is completely thanks to "do it from scratch, code it yourself" attitude.


Here we have this metaphor which probably sounds funny when directly translated: "go through gray rock". This, with the untranslatable "sisu", is the side of Finnish culture I don't like. It's anti-innovation and focuses on early narrow-minded decision and having huge persistence and motivation to keep going through that gray rock, while a wise man would just walk around that rock.

But sometimes it's not self evident which way is easy and sustainable in the long run, especially when you listen to others, all the mixed signals you get.

The world tells you to use libraries (quantity over quality), frameworks, trendy programming languages, complex structures, etc. It happens so widely that you suspect: "they must be right", and you start questioning your own intuition, then you stop being intuitive and start going through the rock. Don't do this, become something better!

[westfw]

most libraries are horribly bad and only end up wasting everyone's time.

I think I'm going to have to disagree, in general.
There are a lot of libraries that I'm willing to use, and have very little interest in re-writing.  libc.  floating point arithmetic.  File system code.  printf and string handling functions (except under special circumstances.)  xml parsers.  regular expression code.
These are all things that have matured to a point, and are pretty well understood.  Things that annoy people with them have been addresses in "modified" versions.   They've been used by a lot of people on a lot of systems, and ... they are pretty much the way I'd write them anyway.

They are platform independent and usefully abstract other dependencies, aiding portability.

The objectionable libraries are the supposed "Low level hardware abstraction libraries", where vendors try to wrap their proprietary and highly unique hardware features in code that is somehow easier to understand even though it is no less proprietary and no less unique, and has as a secondary unstated goal of locking your to that proprietary uniqueness.   Worse, it's at a level where there aren't widespread agreements on how things should work, or where that varies depending on the exact application; a level where Choices Are Made...

[JPortici]

maybe with "libraries" they were referring to "peripheral libraries"?

[Karel]

most libraries are horribly bad and only end up wasting everyone's time.

I think I'm going to have to disagree, in general.
There are a lot of libraries that I'm willing to use, and have very little interest in re-writing.  libc.  floating point arithmetic.  File system code.

Filesystem code I wrote it myself as well. I had a project where I only wanted to write one file, no directories, no reading.
The common FAT32 libraries are overkill for such a purpose and FAT32 is actually quiet simple to implement.
This combined with my own code to access SD-cards created a fast, lean and robust piece of software.
This is important if you want to do commercial high volume projects and want to keep hardware cost and power consumption low.