Author Topic: Is ST Cube IDE a piece of buggy crap?  (Read 158315 times)

0 Members and 6 Guests are viewing this topic.

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #75 on: August 02, 2021, 09:42:28 pm »
So you had an issue in the clock configuration you wrote yourself. This is a strange example. For a beginner it is much safer to rely on vendor provided framework. The STM32 libraries are pretty mature.

Yes, it was in clock configuration code I wrote myself. The issue turned out to be an errata in the chip that was published by the vendor after I wrote my code. I fixed it by changing the ratio between the multipliers/dividers. The chip didn't support the full range as documented in the reference manual.
Complexity is the number-one enemy of high-quality code.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #76 on: August 02, 2021, 09:57:46 pm »
In this thread, a bit of confusion I think, though.

Do not confuse vendor *libraries* with IDEs and code-generation tools. Even if the latter can use said libraries themselves, they are two completely different things with two completely different ways of developing.

Vendor libraries usually do not abstract all that much, so for using them properly you still need to know the underlying peripherals, clocking resources, and so on. They do not promote not reading the docs. They do save you some time (usually), and make porting code to a different MCU from the same vendor easier, but that's pretty much it. They spare you knowing the exact registers and bit fields, but not knowing what can be configured and such.

For instance, you can't setup clocks using the STM32 HAL without knowing how clocks work on the MCU, what the parameters are, etc. So you still need to RTFM.

It's using the code generation tools that "abstract" all this a lot more, and will promote not reading manuals and ultimately not really knowing what you're doing. It may be OK for beginners, but using them for anything professional is NOT a good idea.

Now using vendor libraries is a different thing. You may have good reasons for using them, or not using them. But those wouldn't be the same reasons as with the above.

Another related difference is that vendor libraries almost all come with full source code. You can study it, modify it, rewrite it, or just read it to complement manuals when those are too vague about some setting. Code-generators usually do not come with source code. You have to blindly trust the vendor.
 

Offline Silenos

  • Regular Contributor
  • *
  • Posts: 52
  • Country: pl
  • Fumbling in ignorance
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #77 on: August 02, 2021, 10:01:47 pm »
What you're describing is lazy engineer syndrome.
Wait, isn't laziness one of the engineer's three major virtues?  ^-^
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #78 on: August 02, 2021, 10:22:55 pm »
What you're describing is lazy engineer syndrome.
Wait, isn't laziness one of the engineer's three major virtues?  ^-^

Well - it is, as long as you follow good practices of your particular field.

Problem is, we're talking about software here. Software is a slightly different beast, and whether it's really engineering per se is still questioned. There's been a LOT of talk about this, and very competent people who themselves claimed software development could not be called engineering. A lot to be said, and I guess, a good potential for flame wars. ;D

But taking the example of being lazy as in reusing components that are standard and proven instead of "reinventing the wheel" is a good one. Unfortunately, software reuse is, most often, very far from the equivalent of, say, using a standard screw in a mechanical design. Or using proven formulas for material strength. Etc. Yeah that opens a can of worms.
 
The following users thanked this post: Silenos

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #79 on: August 03, 2021, 08:17:36 am »
You could spend half your day with the data sheep and alternate pin function mappings just picking pin mux settings.

You could spend the other half of your day looking at the AC specifications / PLL reference manual / clock generator documentation just figuring out the PLL / clock division settings for the more important peripherals.

Once the GUI tool helps you visualize the pinmux / pinout and clocking and pick settings yeah the API calls aren't that hard but do you really want to read the DS + architecture manual + reference manuals / user guides + application notes cross referencing 200 different scattered pages to know what a given $7 MCU variant is capable of?

Oh and what is the magic sequence needed to program / sequence various internal voltage / power domain / clock settings registers to switch from internal RC oscillator at 1 MHz to external crystal + PLL depending on the MHz you want to run at?

For a timer capture how / where do you control the edge polarity, what interrupt channel is that again?

There are too many details even for a single modern MCU part to manually deal with that all 2000 different relevant register settings / capabilities / sequencing / alternative assignments by manual documentation process.

What you're describing is lazy engineer syndrome. Why bother understanding the capabilities and settings for a particular MCU when you can let some automated tool take a stab at it? IMO, any embedded engineer doing commercial work should understand the intricacies of the components he's using in his designs and not rely on automated tools to do his thinking for him.

Relying on automated tools leads to less understanding of how things work and how they interrelate. What are you going to do, for example, if you're at a customer site one day trying to debug an issue in the autogenerated clock configuration code with an irate customer breathing down your neck? I've actually been in exactly this situation and was able to resolve the issue quickly and defuse the irate customer because I thoroughly understood the clock configuration code I wrote myself.
Well... try that with a USB or network software stack. Or SSL/TLS, Lora, Wifi, LTE to name a few.

With the exact same reasoning you could also have updated the vendor provided library to a newer version which has a fix for the problem. And likely the vendor provided library you could have used already avoids the issue you missed to address in your own code. So that could have prevented your predicament from happening at all.

Nowadays you really have to manage what knowledge you need to acquire and what not. Some of the chips I work with have thousands of pages with documentation which -despite the sheer number of pages- isn't going into much detail. Acquiring full knowledge of all the inner workings within the time span of a project just isn't feasible. I have to rely on vendor provided software and patches in order to get these chips going. Fixing a problem by updating the vendor provided software is a much quicker path compared to fixing the problem myself (which I can't always avoid though).
« Last Edit: August 03, 2021, 08:20:57 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #80 on: August 03, 2021, 11:27:12 am »
Also note the huge difference between:

* Classic STM32 "Standard peripheral library".

This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this. This sudden attitude change (while technically nothing changed) is the testament of the cargo cult engineering attitudes, all driven by opinionated feelings, not facts.

But most of the STM32 examples online use this library. In reality, this library is an utter disaster, because it does not abstract anything at all, but only adds a layer of extra boilerplate for no benefits whatsoever. 1 LoC initialization becomes unwritable 20 LoC which is either copy-pasted or autogenerated, and you still need to know what every configuration bit does because they map almost 1:1 (but not exactly, for maximum confusion).


* STM32 HAL

What a horrible name. Protip: when coining a proper noun, just don't use the well-known name of the concept. For example, if you want to establish a grocery store, don't call it "Grocery store", communication will be difficult. Similarly, when coming up with a specific HAL library, don't call it HAL.

This naming thing out of the way, STM32 HAL makes perfect sense because it abstracts. It's successful in this regard, and no one questions that. That's really the argument to use it. Because it abstracts, it hides unnecessary burden from the programmer - in theory. Also because it abstracts, it can make code portable across different devices - in theory. Finally, because it abstracts, it saves time - in theory.

Now all that is left is to answer the questions:
* Which STM32 peripherals benefit from being abstracted to a linked library at all?
* Which STM32 peripherals benefit from having a manufacturer-implemented generic abstraction instead of rolling your own?
* What does "benefit" mean? Just time saving, or maybe performance, code size, maintainability? Being able to do what is needed at all?
* Is STM32 HAL well implemented?
* Is STM32 HAL really portable?
* Does STM32 HAL really save time in the big picture?

... and so on.

But people like dietert1 can not discuss such points, they can only come up with very simplistic strawmen and attack those in some one-liners. But this is unsurprising; if you don't have such thinking capabilities, being able to program will be difficult, too, and all that's left is to try random oneliners in the hope that they happen to work. HAL is agreeably great for that, and possibly even successful, assuming you never hit complex requirements but instead build "typical" projects for which the HAL was written and tested, like "replicating" devkit projects.

One of the stupidest strawmen arguments is "oh, why would you implement identical generic library yourself, you must be stupid". Of course you won't, if you think something sucks then obviously you won't replicate it, but do something different. In this case, designing a generic abstraction layer for something that have tens of thousands or millions of functional permutations, there are two approaches:

* Reduce the available functionality, i.e., artificial limitations on what you can do,
* Make the abstraction layer complex, difficult to use, and the implementation thereof difficult to write, bloated and slow, to support all available functionality.

In reality it's a mix of the two. Thankfully STM32 HAL emphasises the former, otherwise it would be even more bloated and not easy to use. (The SPL was an example of the latter.)

You can sidestep this issue completely when writing your own abstraction (or in simplest cases, not abstract at all) in per-project basis, and this is where the time saving lies. Maybe it takes 10 minutes to write UART init and simple TX/RX functions using the HAL, and maybe it took 1 week for ST to implement that part of the HAL. But this doesn't mean it takes 1 week to do it without their HAL, no, it takes like 20 minutes, completely insignificant.

Also no one's saying you shouldn't use libraries ever, at all. Don't write a TCP/IP stack. Use existing code or libraries when they actually save time and/or improve the code quality. This shouldn't be cargo cult engineering, we can do educated choices based on facts!
« Last Edit: August 03, 2021, 11:31:07 am by Siwastaja »
 
The following users thanked this post: abyrvalg

Online gf

  • Super Contributor
  • ***
  • Posts: 1132
  • Country: de
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #81 on: August 03, 2021, 12:37:11 pm »
How does actually fit libopencm3 into this picture?
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3683
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #82 on: August 03, 2021, 02:39:16 pm »
I last used source control many years ago. My main issue is having a futureproof development environment,

Use version control.  Otherwise you will have gremlins like this, period.

It isn't worth anyone's time, least of all yours to answer questions like "my project used to build but doesn't now" if you don't have version control. I'm not sure what you mean by "futureproof development" but since everyone who does software development seriously or professionally uses version control the chances that you know something that they all don't is miniscule.  You should literally do this before you write another line of code.
 

Online dietert1

  • Super Contributor
  • ***
  • Posts: 2018
  • Country: br
    • CADT Homepage
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #83 on: August 03, 2021, 02:53:45 pm »
A framework like cube with its integration of all useful tools has merits. You get libraries with source, you get visual configuration and code generators that "know" about the hardware of many different devices and how to properly use the libraries, you get application examples, you get operating system components, you get the IDE (editor, compiler, debugger). As a whole this is something unseen in the past. The approach isn't at all specific to STM32. I remember using similar frameworks from other vendors like Microchip. Certainly at some point they will include GIT.

The framework supports working without the natural language reference manuals. Instead of reading English text, you will review library sources. And the IDE will point you to references and definitions very fast. The HAL contains a complete description of what is in the reference manual, i mean once you get used to its naming conventions. One can even say it represents all reference manuals of all STM32 devices.

I have been using cube many times and found it useful. Most users of the framework will do some code review and that's it. Others will say: Component x of the framework is not after my taste or not good enough, i will modify it or replace it by something else. As i wrote in my first comment i prefer the IAR IDE and it integrates well with cube. Also i remember adding time measurements and counters to certain HAL functions as realtime debugging support. Sometimes i have been adding natural language comments to the files. And i mentioned that you can extract source from self invented application examples that you setup with the framework, e.g. to make a special library for a boot loader. Heroes watch out: You may create a piece of buggy crap.

Regards, Dieter
 

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #84 on: August 03, 2021, 03:01:56 pm »
"This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this."

Is this the libs which come with Cube IDE i.e. the HAL stuff?

Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #85 on: August 03, 2021, 03:50:13 pm »
No the Cube HAL is the successor.
The first gen ST peripheral libraries the interface functions differed per uC family which made it bothersome to say the least.
A sr SW eng spent three manmonths porting our companies own abstraction layer from STMF1 to STMF2.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #86 on: August 03, 2021, 03:51:45 pm »
"This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this."

Is this the libs which come with Cube IDE i.e. the HAL stuff?

Read more carefully. I thought I made it super clear SPL and HAL are really different and SPL is obsolete, HAL is not.

These cater to different needs, though, and are at completely different level. To rephrase it again, SPL was a totally unnecessary layer, HAL has a purpose other than obfuscation so does make sense to exist.
 

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #87 on: August 03, 2021, 04:35:10 pm »
Having been playing with this stuff for only about 9 months, I have no knowledge of ST ARM development before that.

I think a fair few people have a Cube IDE setup which they use just to generate some functions, based on the graphical config "wizard" in Cube, they copy out the generated code, and then close Cube without saving anything :) I can see why they do this; it saves a huge amount of RM reading, especially for all the various clock divider config.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #88 on: August 03, 2021, 05:29:42 pm »
Well... try that with a USB or network software stack. Or SSL/TLS, Lora, Wifi, LTE to name a few.

I have written my own TCP/IP stack (along with Ethernet and WiFi drivers) and have used the same code in projects for a dozen years now. It works and I know how it works. The last bug I fixed in it was about a decade ago.
Complexity is the number-one enemy of high-quality code.
 

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #89 on: August 03, 2021, 08:25:55 pm »
That is probably 10 man-years' of a learning curve.

It's possible if working for an employer who is not monitoring work progress, or if you work for yourself and have enough cash cows to keep you afloat while you learn all this stuff.

In practice, today, one would google for the source code and adapt whatever one can find. Writing it from scratch would be a poor use of time.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #90 on: August 03, 2021, 09:01:11 pm »
That is probably 10 man-years' of a learning curve.

You're kidding, right?

TCP is a very simple protocol. If you ever wrote code which packetizes serial stream, it's comparable complexity to TCP. There are some quirks such as CRCs and window management, but it's all is straightforward and well documented. Even the problems which you can encounter are documented in RFCs. There were decades when people tried to abuse TCP/IP, mount DoD attacks, hurt performance. So TCP/IP is investigated and known to the very details. And it's been that way at least for 30 years. Aside of that, IP packets must be encapsulated into Ethernet frames. One extra thing you need to do is to find a recipient's mac address - you broadcast a packet "who has this IP?" and receive a response. That's all there is to it.

People are afraid of what they don't know and think it's some sort of magic. But if you look at the docs, things start to look simple.
 
The following users thanked this post: Silenos

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #91 on: August 03, 2021, 09:06:36 pm »
That is probably 10 man-years' of a learning curve.

You're kidding, right?

TCP is a very simple protocol. If you ever wrote code which packetizes serial stream, it's comparable complexity to TCP. There are some quirks such as CRCs and window management, but it's all is straightforward and well documented. Even the problems which you can encounter are documented in RFCs. There were decades when people tried to abuse TCP/IP, mount DoD attacks, hurt performance. So TCP/IP is investigated and known to the very details. And it's been that way at least for 30 years. Aside of that, IP packets must be encapsulated into Ethernet frames. One extra thing you need to do is to find a recipient's mac address - you broadcast a packet "who has this IP?" and receive a response. That's all there is to it.
Not by a long shot. Modern day TCP/IP stacks have all kinds of traffic optimisations in them (for example having 2 packets in flight as the simplest form). The base is pretty simple but getting a rock solid and secure TCP/IP stack is a different story. Writing your own TCP/IP stack is nothing short than re-inventing the wheel anyway.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Kjelt, Silenos

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #92 on: August 03, 2021, 09:07:49 pm »
If you look at the source code of a commercial IP stack with multiple procols and services, ip4 and ip6 with TLS with multiple ciphers etc. You see it is not so simple especially on a uC where you have only around 32kB RAM for the IP protocol and less than 64kB ROM for that code.
And yes you can write it yourself then have to debug and still forget a couple of things that hackers will find with Kali in a couple of hours pentesting.
If you want then please start with an already tested open source codestack.
 
The following users thanked this post: Silenos

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #93 on: August 03, 2021, 09:35:23 pm »
That is probably 10 man-years' of a learning curve.

You're kidding, right?

TCP is a very simple protocol. If you ever wrote code which packetizes serial stream, it's comparable complexity to TCP. There are some quirks such as CRCs and window management, but it's all is straightforward and well documented. Even the problems which you can encounter are documented in RFCs. There were decades when people tried to abuse TCP/IP, mount DoD attacks, hurt performance. So TCP/IP is investigated and known to the very details. And it's been that way at least for 30 years. Aside of that, IP packets must be encapsulated into Ethernet frames. One extra thing you need to do is to find a recipient's mac address - you broadcast a packet "who has this IP?" and receive a response. That's all there is to it.
Not by a long shot. Modern day TCP/IP stacks have all kinds of traffic optimisations in them (for example having 2 packets in flight as the simplest form). The base is pretty simple but getting a rock solid and secure TCP/IP stack is a different story. Writing your own TCP/IP stack is nothing short than re-inventing the wheel anyway.

Yeah, that might be important if I was implementing TCP/IP for a high-volume server, but for my typical embedded projects data rates are low and the efficiency of bog-standard TCP/IP (as documented in the earliest RFCs) is more than good enough for me.
Complexity is the number-one enemy of high-quality code.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #94 on: August 03, 2021, 10:11:38 pm »
Not by a long shot. Modern day TCP/IP stacks have all kinds of traffic optimisations in them (for example having 2 packets in flight as the simplest form). The base is pretty simple but getting a rock solid and secure TCP/IP stack is a different story.

He could have optimized his stack for his own use, made it more compact and more suitable for MCU. Why do you think his stack is not rock solid? May be it is.

Writing your own TCP/IP stack is nothing short than re-inventing the wheel anyway.

I guess he had his reasons. How can you judge him without knowing anything about his circumstances?

If not for the people who "re-invent" the wheel we would still use wheels made of rock.
 
The following users thanked this post: Sal Ammoniac, Siwastaja

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #95 on: August 04, 2021, 06:00:36 am »
You would have had to work hard to get a TCP/IP stack on a "64k" CPU like e.g. a Z80, or some other device with a 64k address space. With banking (e.g. Z180; could do 1MB with the IAR compiler, large model, banking functions in/out) it gets a lot easier. Loads of people struggled with this in the early days of ethernet, and many/most of them solved it by buying in one of the various ethernet modules which give you a serial port to connect to (rubbish data rate but ok for most applications in question, and you can claim your box "does ethernet"). And now you more or less need TLS...

You would need to be a pretty serious "anorak" (as well as a very good comms programmer) to roll your own TCP/IP stack, but my main Q would be who or what is paying for your time while you are spending it on that sort of thing.

Let me give you an example. My target right here would get DHCP allright at my office but would not do it at my house. There were various differences. Same main router. Different 16-port switches; the work LAN uses a 16 port unmanaged Netgear; the home LAN uses a 16 port unmanaged Linksys POE switch which claims to do QOS (as usual zero details published and no config). Different subnets (192.168.1.* versus 5.*). Someone suggested it might be the hacked MAC# in the target board (was something like 0x01 x02... But why should this matter, when there was no conflict? Well, this Linksys "QOS" switch was doing something! I can't believe it was looking up the MAC # online to see what this product was... Changing the MAC to one of a laptop (which did get DHCP allright) made it work!
« Last Edit: August 04, 2021, 07:14:07 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #96 on: August 04, 2021, 08:03:06 am »
You would have had to work hard to get a TCP/IP stack on a "64k" CPU like e.g. a Z80, or some other device with a 64k address space. With banking (e.g. Z180; could do 1MB with the IAR compiler, large model, banking functions in/out) it gets a lot easier. Loads of people struggled with this in the early days of ethernet, and many/most of them solved it by buying in one of the various ethernet modules which give you a serial port to connect to (rubbish data rate but ok for most applications in question, and you can claim your box "does ethernet"). And now you more or less need TLS...
You can get a long way with uIP on a small platform. I have messed with that quite a bit but in hindsight it is an utter piece of rubbish. In my most recent project which needed ethernet on a microcontroller I used a Wiznet 5500 chip (they might have newer versions which also support IPv6 by now). As an added bonus the chip also acts as a firewall between your application and the tcp/ip stack.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #97 on: August 04, 2021, 09:45:08 am »
For small to medium scale production runs that is a viable solution.
Problem is the ownership and maintainability of the stack.
In case a zero day exploit is found and customer has an issue you should be able to upgrade your stack to solve it.
I do not know if this is possible with the external Wiznet solution ?

For larger scale production, it is probably too expensive and the ip stack needs to be owned and integrated in the firmware from the company.
In the real world we already see lots of hacks of home and small business networks occurring through not only PCs but older not maintained and updated internet connected electronics such as routers, NASses, VCRs, TVs, IP cameras etc.
Lots of small electronic companies do not have a security lifecycle management department that actively monitors cve reports and some even never update the firmware after production.

So it is the responsibility of the OWNER of the equipment to at least yearly check the security vulnerabilities for their equipment and not blindly attach everything to the internet.
https://www.cvedetails.com/
 

Online peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3669
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #98 on: August 04, 2021, 01:43:42 pm »
This is digressing somewhat, but I looked up the Wiznet 5500. Yes; it looks like a good solution, although it doesn't have hardware crypto. In the thing I am working on now I have a LAN8742 and the stack is done on the 32F417 using the ST libs, so if some exploit comes out at least in can be fixed, whereas with a chip like the Wiznet you are stuffed.

OTOH a lot of products are used in applications where they are nowhere near being exposed to the outside internet... or so you hope ;) But then all you need is something which does NTP (for date/time; always a challenge in embedded systems) and you are immediately stuffed.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #99 on: August 04, 2021, 05:48:52 pm »
For small to medium scale production runs that is a viable solution.
Problem is the ownership and maintainability of the stack.
In case a zero day exploit is found and customer has an issue you should be able to upgrade your stack to solve it.
Yes and no. If the Wiznet chip gets hacked they still aren't in your application. It is only a real problem if a third party can reprogram the Wiznet chip remotely to become part of a botnet OR do a targetted DDOS attack on your device. However since IOT devices are typically behind a firewall / NAT router, the chances of a real attack are very low.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf