Author Topic: Next step from AVR  (Read 7737 times)

0 Members and 1 Guest are viewing this topic.

Offline Deku TreeTopic starter

  • Contributor
  • Posts: 35
  • Country: us
Next step from AVR
« on: October 16, 2018, 07:23:40 pm »
I'm graduating in a few months and have spent about a year working with the Atemga128 in various classes. My latest projects have mostly been with the Attiny85 but these chips are pretty expensive compared to some of the STM32 variants that offer way more functionality. With this in mind, what would you all suggest as a next family of microcontrollers? What would be good for both my own personal development as an (aspiring) embedded guy and for my wallet?


A note I'd like to add: all my work with these boards has been with the linux toolchain rather than an Arduino IDE
« Last Edit: October 16, 2018, 11:33:19 pm by Deku Tree »
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Next step from AVR
« Reply #1 on: October 16, 2018, 07:33:11 pm »
STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 722
  • Country: ch
Re: Next step from AVR
« Reply #2 on: October 16, 2018, 07:57:40 pm »
+1 for above statement
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Next step from AVR
« Reply #3 on: October 16, 2018, 08:17:42 pm »
STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)
I'd say that long list of applications and not having a proper manufacturer supplied IDE is a strike against STM. That toolchain seems to have the typical open source issue of being fragmented all over the place.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #4 on: October 16, 2018, 10:21:57 pm »
STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)
I'd say that long list of applications and not having a proper manufacturer supplied IDE is a strike against STM. That toolchain seems to have the typical open source issue of being fragmented all over the place.

I don't want some opaque manufacturer-supplied IDE .. ugh!

The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware

Each piece exists because it has a limited and well defined job to do, and can be swapped out for something else doing an equivalent job depending on the situation.

Eclipse is just for text editing and project build. That's absolutely independent of the CPU or board you're targeting. I prefer to use the text editor of my choice and gmake or cmake/ninja.

It's pretty easy to understand what is going on with your set of specialised tools, and they can be adapted to many purposes. It's just awful to try to figure out why some all-in-one vendor IDE isn't working.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Next step from AVR
« Reply #5 on: October 16, 2018, 10:46:10 pm »
The next step is ARM <something or other>, no question about it.  There is a question whether STM32 is the way to go but there is a book, "Mastering STM32" that will hold your hand starting with installing Eclipse and GCC and working up.

https://leanpub.com/mastering-stm32

Any time you can get a book, it's a good place to start.

Another way to go:  Look at mbed.org and, specifically, the original mbed (LPC1768).  I use these all the time and I really like the online toolchain.  I don't have to install anything, the binary is 'drag and drop' onto the device and I can work on my code from any PC in the world that has a web browser.  Yes, there are detractors, but ask if they ever did a sizable project actually using the tools.  Mostly it's opinion "I don't like online...".

You will also notice that some STM32 boards are also 'mbed compatible' and you will find them listed on the mbed.org site.  I'm not sure how well supported they are but the 'drag and drop' will work and that's the important bit.

The mbed infrastructure does not include a hardware debugger.  Fine!  Just use printf().  I have never found single stepping to be all that productive anyway and I've been doing it for almost 50 years (started in '70).

For a first attempt, I think the "Mastering STM32" is the way to start.

Completely different:  Cypress PSOC 6 (or PSOC 4 and PSOC 5).  There are terrific videos on how to use the boards and the toolchain creates a lot of the underlying code.  There is also a graphical component where you lay down the peripherals you will use and interconnect them as necessary.  When you build the configuration, all the support code is generated.  This is a VERY nice development environment.  The PSOC 6 has two ARM cores, an M0 and an M4.  One can be used to support tasks with high compute needs and the other might support IO.  But both devices have access to all peripherals and memory.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Next step from AVR
« Reply #6 on: October 16, 2018, 10:51:17 pm »
I don't want some opaque manufacturer-supplied IDE .. ugh!

The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware

Each piece exists because it has a limited and well defined job to do, and can be swapped out for something else doing an equivalent job depending on the situation.

Eclipse is just for text editing and project build. That's absolutely independent of the CPU or board you're targeting. I prefer to use the text editor of my choice and gmake or cmake/ninja.

It's pretty easy to understand what is going on with your set of specialised tools, and they can be adapted to many purposes. It's just awful to try to figure out why some all-in-one vendor IDE isn't working.
Needing to piece together a toolchain is what I was talking about. Open-source is great, but unfortunately often leads to fragmentation and having many alternatives that are both functional and broken in very similar but slightly different ways. Finding out what is misbehaving can be a pain and people always seem to be using different tools when you look for guidance or help.

I'm not saying vendor IDEs are ideal or perfect, mind. I think few would want to argue that.
 

Offline FERCSA

  • Contributor
  • Posts: 39
  • Country: hu
    • www.fercsa.com
Re: Next step from AVR
« Reply #7 on: October 16, 2018, 10:52:13 pm »
OP. Did you use arduino with atmega/attiny? Probably, so give a spin for the ESP32 platform, but if you really into electronics not just programming, PSoC is a great platform with a ton of doc, tutorial, etc.

One thing for sure, next step should be a ARM based uC.
Don't ask. I'm the same guy who gave you ultra fast internet in the '00s..
#FERCSA
 

Offline Deku TreeTopic starter

  • Contributor
  • Posts: 35
  • Country: us
Re: Next step from AVR
« Reply #8 on: October 16, 2018, 11:12:25 pm »
Looks like ARM is the general consensus then? One thing I do like is the opensource toolchain you guys mentioned.

I actually purchased that Mastering STM32 book, and began reading it about 6 months ago. I ended up just giving up on it because the whole development environment seemed so fragmented. I still have a Nucleo board and a copy of the book, maybe I'll try and take another stab at it. One thing I've really liked about working with AVR has been that I know exactly what's happening from when I write the code, to compilation, and then onto the board. With the STM32 is seems like in an effort to make it easier, many of the available tools hide a lot, making it difficult to debug anything.

If I do decide to start with ARM, what would you all suggest as an inexpensive development board to get started? I'm checking out that mbed board now, looks promising.

edit; Just a quick clarification; it's my understanding that at their core the STM32 series contain an arm processor along with additional functionality, is this correct? If so, it seems like the best choice to ease into the STM32 world would be to start with a simple ARM MCU and then transition to the STM32 once I'm comfortable?
« Last Edit: October 16, 2018, 11:16:03 pm by Deku Tree »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #9 on: October 16, 2018, 11:31:07 pm »
I don't want some opaque manufacturer-supplied IDE .. ugh!

The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware

Each piece exists because it has a limited and well defined job to do, and can be swapped out for something else doing an equivalent job depending on the situation.

Eclipse is just for text editing and project build. That's absolutely independent of the CPU or board you're targeting. I prefer to use the text editor of my choice and gmake or cmake/ninja.

It's pretty easy to understand what is going on with your set of specialised tools, and they can be adapted to many purposes. It's just awful to try to figure out why some all-in-one vendor IDE isn't working.
Needing to piece together a toolchain is what I was talking about. Open-source is great, but unfortunately often leads to fragmentation and having many alternatives that are both functional and broken in very similar but slightly different ways. Finding out what is misbehaving can be a pain and people always seem to be using different tools when you look for guidance or help.

I'm not saying vendor IDEs are ideal or perfect, mind. I think few would want to argue that.

OK, I'll admit I don't know exactly what typical ARM vendors do.

With our $59 HiFive1 Uno-compatible 320 MHz RISC-V board ...

https://www.crowdsupply.com/sifive/hifive1
https://nz.mouser.com/ProductDetail/Crowd-Supply/cs-hifive1-01?qs=wd5RIQLrsJiLD253rjAssQ%3D%3D

... here's what you do to get a functioning command line toolchain and run your first program:

git clone --recursive https://github.com/sifive/freedom-e-sdk.git
cd freedom-e-sdk
make tools

That checks out and builds binutils, gcc, newlib, gdb, openocd. Everything you need. Takes about 20 minutes on my NUC, or 3 minutes on a big i9 or ThreadRipper.

make software PROGRAM=hello
make upload PROGRAM=hello

That's *it*.

OR, you can use a pre-built version of the toolchain. OR and Eclipse-based IDE. OR the standard Arduino IDE you already have (pasting our tools URL into a dialog box in the IDE).

Plenty of choices for everyone, and they all work.

It's all in the "Getting Started" document https://static.dev.sifive.com/dev-kits/hifive1/hifive1-getting-started-v1.0.2.pdf
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Next step from AVR
« Reply #10 on: October 16, 2018, 11:33:17 pm »
Looks like ARM is the general consensus then? One thing I do like is the opensource toolchain you guys mentioned.

I actually purchased that Mastering STM32 book, and began reading it about 6 months ago. I ended up just giving up on it because the whole development environment seemed so fragmented. I still have a Nucleo board and a copy of the book, maybe I'll try and take another stab at it. One thing I've really liked about working with AVR has been that I know exactly what's happening from when I write the code, to compilation, and then onto the board. With the STM32 is seems like in an effort to make it easier, many of the available tools hide a lot, making it difficult to debug anything.

If I do decide to start with ARM, what would you all suggest as an inexpensive development board to get started? I'm checking out that mbed board now, looks promising.

edit; Just a quick clarification; it's my understanding that at their core the STM32 series contain an arm processor along with additional functionality, is this correct? If so, it seems like the best choice to ease into the STM32 world would be to start with a simple ARM MCU and then transition to the STM32 once I'm comfortable?
Maybe the aforementioned PSoC family is worth a shot. It provides a fairly decent experience and information and is quite versatile. They have various cheap and less cheap development boards.
« Last Edit: October 16, 2018, 11:36:30 pm by Mr. Scram »
 

Offline Deku TreeTopic starter

  • Contributor
  • Posts: 35
  • Country: us
Re: Next step from AVR
« Reply #11 on: October 16, 2018, 11:35:47 pm »
Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #12 on: October 16, 2018, 11:46:24 pm »
Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

Don't look at RISC-V if you want practical knowledge usable right now, not in 5-10 years, if ever.

There are plenty of cheap ARM boards from manufacturer supplied with integrated debuggers and all the bells and whistles to some very cheap eBay stuff from China. But you need to pick a chip vendor first, otherwise there are just way too many options.

Boards with integrated debuggers are a bit more expensive, but they are all you need to start. Cheaper boards will require external debugger to program them. Some chips will have bootloaders, but spare yourself some pain and get a real debugger, they are not that expensive.
Alex
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Next step from AVR
« Reply #13 on: October 16, 2018, 11:46:42 pm »
Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?
What did you find? Basic PSoC 4 and PSoC 5 boards go for under or around to 10 bucks. These are breadboardable and come with a snap off programmer. A PSoC 4 board used in many of their videos is about $25. They have both simple and fancy boards for pretty much any budget, but most won't break the bank.

I personally feel the FPGA-like fabric in many models is a pretty neat party trick. No need for many variants, you just configure the hardware as you please. If you know your way around Verilog you can even write your own components.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Next step from AVR
« Reply #14 on: October 16, 2018, 11:51:48 pm »
I'd say start from real project - something you want to create. Then select an MCU which will do the job for you, other parts, prototype it, design a board, build it, use it.

If you march on "mastering" all the MCUs one by one, it will not do you any good, and without real projects it will be all boring and useless anyway.
 

Offline Deku TreeTopic starter

  • Contributor
  • Posts: 35
  • Country: us
Re: Next step from AVR
« Reply #15 on: October 16, 2018, 11:54:05 pm »
Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

Don't look at RISC-V if you want practical knowledge usable right now, not in 5-10 years, if ever.

There are plenty of cheap ARM boards from manufacturer supplied with integrated debuggers and all the bells and whistles to some very cheap eBay stuff from China. But you need to pick a chip vendor first, otherwise there are just way too many options.

Boards with integrated debuggers are a bit more expensive, but they are all you need to start. Cheaper boards will require external debugger to program them. Some chips will have bootloaders, but spare yourself some pain and get a real debugger, they are not that expensive.

Do you suggest against RISC-V because it's too new? I'm not really familiar with it.

As for those cheap ARM boards, I'm getting overwhelmed by all the options! Are there any that you have used successfully in the past that might help guide my search?

Thank you all for being so patient with me, this is a bit leap for me!
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #16 on: October 17, 2018, 12:06:00 am »
Do you suggest against RISC-V because it's too new? I'm not really familiar with it.
Not only it is new, there are no good MCU-class devices on the market. FE310 is an engineering prototype for sale at best. 

As for those cheap ARM boards, I'm getting overwhelmed by all the options! Are there any that you have used successfully in the past that might help guide my search?
Not really. I work for Microchip, so I have easy access to Microchip development kits. Other than that, I just make my own boards with the peripherals I need for a project.

But they all work the same. It is just a board. What really matters is the used MCU. Once you decide that, you can pick any board you like that fits into your price range. But don't go too cheap for a first board. You don't need extra problems just because the board required extra fiddling.

It is also important to figure out what IDE/Toolchain you want to use, since this will define compatible debuggers/programmers.
« Last Edit: October 17, 2018, 12:08:08 am by ataradov »
Alex
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Next step from AVR
« Reply #17 on: October 17, 2018, 12:20:34 am »
Of course looking at ARM is a wise direction and you should certainly do that to complement your technical culture and help your short-term employability.

That said, looking at other architectures (even though there are not many anymore) will also expand your horizons. So a look at the Microchip products (8, 16 and 32-bit) would be valuable as well.
You can take advantage of this questioning of yours to start an habit of continuous watch for new technology and products. This will prove very useful for the rest of your career.

 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #18 on: October 17, 2018, 12:29:36 am »
Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?

Don't look at RISC-V if you want practical knowledge usable right now, not in 5-10 years, if ever.

Oh, come on. That's purest FUD.

If you said 1-2 years for hobbyists or small scale board manufacture using off the shelf MCU chips I'd agree with you.

People who are serious about manufacturing in volume want custom SoCs with everything they need already on them, not piece it together from a board full of chips. RISC-V is already in those markets with half a dozen companies having announced things like SSD/flash controllers and wearables/IoT chips, and a long funnel of other products in development.

Obviously, the volumes are small compared to ARM right now, but claiming it's not viable or relevant is ridiculous.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #19 on: October 17, 2018, 12:53:11 am »
Oh, come on. That's purest FUD.
It is not. I want RISC-V to succeed. But the reality is that if you go and look for a job right now, you will find plenty of ARM jobs and next to none of RISC-V.

There are no good general purpose RISC-V devices on the market. And I would let consumers decide what they want on their boards. Not everyone can afford an ASIC. And it is good that RISC-V finds its use in ASICs, but this is not applicable to this thread.

If you said 1-2 years for hobbyists or small scale board manufacture using off the shelf MCU chips I'd agree with you.
Do you think OP is a WD-scale enterprise that will roll an ASIC?  I don't think so. And otherwise the only useful RISC-V hardware at the moment is FE310, which is super weak as far as MCUs go.

There is a long road ahead for RISC-V before it will get into common MCUs.
« Last Edit: October 17, 2018, 12:56:10 am by ataradov »
Alex
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #20 on: October 17, 2018, 01:20:37 am »
Oh, come on. That's purest FUD.
It is not. I want RISC-V to succeed. But the reality is that if you go and look for a job right now, you will find plenty of ARM jobs and next to none of RISC-V.

Ah, that takes me back!

"The reality is that if you go and look for a job right now, you will find plenty of PDP11 and VAX jobs and next to none of 8086 or 68000".

And it's true, for two years my first job was on Data General Eclipse MV/10000. But then we got 80386 and 68020 and SPARC and pretty soon those things were stone dead.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #21 on: October 17, 2018, 01:23:17 am »
OP needs to learn something now. And "now" ARM is the best option, like it or not. Jumping from ARM to RISC-V takes minutes, so it is not a big deal. Hopefully by the time there is a need to jump, there is a RISC-V MCU with more than 4 basic peripherals.

Alex
 
The following users thanked this post: Siwastaja, Mr. Scram

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Next step from AVR
« Reply #22 on: October 17, 2018, 01:29:01 am »
Ah, that takes me back!

"The reality is that if you go and look for a job right now, you will find plenty of PDP11 and VAX jobs and next to none of 8086 or 68000".

And it's true, for two years my first job was on Data General Eclipse MV/10000. But then we got 80386 and 68020 and SPARC and pretty soon those things were stone dead.
I think the point was that "pretty soon" is not now. ARM is a thing now and will be in the foreseeable future.
 

Offline donotdespisethesnake

  • Super Contributor
  • ***
  • Posts: 1093
  • Country: gb
  • Embedded stuff
Re: Next step from AVR
« Reply #23 on: October 17, 2018, 01:36:12 am »
OK, I'll admit I don't know exactly what typical ARM vendors do.

With our $59 HiFive1 Uno-compatible 320 MHz RISC-V board ...

You seem very desperate to flog your RISC-V stuff, spamming any thread you can. Are sales slow?

I was sort of interested in RISC-V, but now it's on my "don't use, don't recommend" list. If an organization needs to spam everywhere to flog it's product, it's not worth using.

OP: forget about RISC-V, it's a dead end. Buy a $2 STM32 board. As far as ARM goes, they are as simple as they go, and a good entry point.
Bob
"All you said is just a bunch of opinions."
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #24 on: October 17, 2018, 01:38:01 am »
Jumping from ARM to RISC-V takes minutes, so it is not a big deal.

And vice versa.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #25 on: October 17, 2018, 01:39:24 am »
And vice versa.
Except that there is viable ARM hardware now. What do you not get about it?

Do you seriously think that FE310 is a good general purpose MCU? It has fewer peripherals than ATmega and needs more external circuitry to run.
Alex
 

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Next step from AVR
« Reply #26 on: October 17, 2018, 01:51:47 am »
STM32 and ARM in general is a good direction to take. ARM has an fully free and open source development environment (Eclipse CDT + GNU MCU Eclipse + GCC ARM Embedded toolchain, GDB + OpenOCD + CMSIS-DAP programming and debugging tools, all of which are open source and support Linux, Windows and macOS)
I'd say that long list of applications and not having a proper manufacturer supplied IDE is a strike against STM. That toolchain seems to have the typical open source issue of being fragmented all over the place.
The whole point of me recommending those software is because it can get the job done while being unbranded - it works for STM32 and it will work for other ARM-based chip as-is. The full installation guide is on GNU MCU Eclipse's website, which will step you through install every piece of those software listed above. I did not mention ST's TruStudio exactly because it is ST branded now.

Those look really promising, but the price tag is a bit steep for my college budget. Is it going to be difficult to find any development board for less?
What did you find? Basic PSoC 4 and PSoC 5 boards go for under or around to 10 bucks. These are breadboardable and come with a snap off programmer. A PSoC 4 board used in many of their videos is about $25. They have both simple and fancy boards for pretty much any budget, but most won't break the bank.

I personally feel the FPGA-like fabric in many models is a pretty neat party trick. No need for many variants, you just configure the hardware as you please. If you know your way around Verilog you can even write your own components.
PSoC ties you down to their Windows-only PSoC Creator software. Weigh your options before committing. (since I primarily uses macOS this hard requirement of Windows is a no-go.)

As of the future of RISC-V MCU, I have my doubts since ARM slashed the license fees of their Cortex-M0 and Cortex-M3 cores (compare RV32IMAC) significantly especially if your fab also has an ARM license (which most of them do.) Given the existing user base of Cortex-M there is a chance that RV32-based MCU would be smothered by ARM.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #27 on: October 17, 2018, 02:11:14 am »
OK, I'll admit I don't know exactly what typical ARM vendors do.

With our $59 HiFive1 Uno-compatible 320 MHz RISC-V board ...

You seem very desperate to flog your RISC-V stuff, spamming any thread you can. Are sales slow?

No. Run off our feet with customers wanting bigger cores, smaller cores, more IP integrated, more software ported. Hiring anyone we can find with relevant experience. Of which the OP could perhaps become one, if interested.
 

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Next step from AVR
« Reply #28 on: October 17, 2018, 04:10:12 am »
I'm graduating in a few months and have spent about a year working with the Atemga128 in various classes. My latest projects have mostly been with the Attiny85 but these chips are pretty expensive compared to some of the STM32 variants that offer way more functionality. With this in mind, what would you all suggest as a next family of microcontrollers? What would be good for both my own personal development as an (aspiring) embedded guy and for my wallet?


A note I'd like to add: all my work with these boards has been with the linux toolchain rather than an Arduino IDE

IMHO, the ST Nulceo boards are great place to start. You can go with the 20+ pins little modules, to full Arduino-signal mostly compatible, to the ones with Ethernet and LCD (the 746NG series). They have M0, M3, M4, M7, and low power MCU all in similar form factors. All come with on-board ST-LINK/V2, so all you need is the software and off you go. They range from $13 to $30+. Not having to buy/use a separate debug pod saves you $ and time.

Software wise, there are plenty of open source / free alternatives, so you are covered there. Just depending on how comfortable you are with DIY/pre-built, and command line vs. GUI.

Most people here are Linux friendly. OTOH, if you want to take advantage of things like the ST CubeMX (which is in many ways brain-dead, but can get you started) than you do have to use Windows. Perhaps, I like Windows for development just fine.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Next step from AVR
« Reply #29 on: October 17, 2018, 05:47:45 am »
For me, it was a nice jump from AVR to STM32. Not without hickups, though. But only one major hickup!

The biggest issue I see is lack of tutorials and information about minimal no-bullshit development - similar way everyone works on AVR (not counting Arduino) or PIC. Additionally, there is a lot of noise over the trend-tool-and-framework-of-year development style. It has changed several times during my STM32 career, and no one remembers the older ones! So everyone has relearned their tools. I saw this from the start and never looked at these IDEs.

I had really big issues when starting, due to a broken linker script I found online, and it took fairly long to solve this. But everything else went very smoothly, no problems with tools. Compared to an ever-changing IDE environment (not even talking about the "trend framework of the year"), the great thing in make/gcc/ld workflow is that:
1) It's been the same for decades, and will be for unforeseeable future
2) It's the backend in those IDE-of-the-year kludges anyway, so knowing it directly is the skill.

I wouldn't call this fragmented. I see this as the opposite of fragmented. Of course, a nice click-and-point application may give you a simplistic, warm fuzzy feeling, but really, googling for exact instructions for some exact piece of GUI software, where to click to configure memory regions or something like that, when you have a standard way available, expressed textually and processed by your actual tools directly? I think we coders could work out without the sugarcoating. At least for me, it's not an issue.

STM32 documentation totally sucks sometimes, but the chips are fairly innovative and having something orders of magnitude more capable than an AVR gives you a nice feeling to compensate for the headscratching. If you do AVR-complexity things on STM32, it's not difficult. But if you do some fancy thing you wasn't even able to dream about with AVR, you of course need some heavy reference manual reading and headscratching. This is often about combining the peripherals to work together, without CPU, without interrupts, to produce complex interactions, using peripheral-to-peripheral trigger signals, DMA channels...

One thing to be aware of is that when you have an AVR problem, you quickly find out the answer by googling. Whether it's a specific hardware design problem, a very low level software problem, anything.

When I started, really the only thing you could find out by googling any STM32 issue is that:
A lot of people have proudly bought a devboard and have succesfully copy-pasted 100 lines of bloat library code to blink an LED! Hats off to them, but this isn't helping, and no one was actually doing anything on these chips.

... now, this has finally changed  :phew:, and you will find actual results of  someone actually doing something, and hence, can find some help as well. But it still isn't so straightforward as it is on AVR or PIC. Because both the ARM and the ST guys fucked up the software side by creating too complex, too difficult to use abstraction layers, so the only way to program using these layers was to copy-paste code from Stack Overflow, and then they needed to build code autogeneration tools, and then one of the abstraction layers most people used is now obsolete and not recommended anymore, and then there are different options, and the end result is, the community is totally fragmented. But you don't need to care. Use none of these frameworks/layers and you'll be fine. Do it like you do on AVR.
 
Many are actually writing the code sanely, exactly the same way they did on AVR, but these people tend not to need much help, hence they won't post questions and their code won't show up.

When I started with STM32, I was a bit horrified about the fact there is no help available, but I took the bullet and haven't regretted a bit. I have grown to rely on my own skills more, and trust I can solve any problem. At the same time, I have learned the basic gnu tools properly. The thing is, you are using these tools anyway, either directly or indirectly. The indirect way is changing all the time. The direct way is a skill you won't ever lose.
« Last Edit: October 17, 2018, 05:58:32 am by Siwastaja »
 
The following users thanked this post: GeorgeOfTheJungle

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Next step from AVR
« Reply #30 on: October 17, 2018, 06:12:50 am »
The biggest issue I see is lack of tutorials and information about minimal no-bullshit development - similar way everyone works on AVR (not counting Arduino) or PIC. Additionally, there is a lot of noise over the trend-tool-and-framework-of-year development style. It has changed several times during my STM32 career, and no one remembers the older ones! So everyone has relearned their tools. I saw this from the start and never looked at these IDEs.
That is really my beef about those Chinese folks insisting on using CubeMX, HAL and FreeRTOS for absolutely everything.

I had really big issues when starting, due to a broken linker script I found online, and it took fairly long to solve this. But everything else went very smoothly, no problems with tools. Compared to an ever-changing IDE environment (not even talking about the "trend framework of the year"), the great thing in make/gcc/ld workflow is that:
1) It's been the same for decades, and will be for unforeseeable future
2) It's the backend in those IDE-of-the-year kludges anyway, so knowing it directly is the skill.
I have been there too, and decided to write some scripts to generate those files in my own way and published those in Github (https://github.com/SushiBits/platform-stm32f1 etc.) While I use vanilla Eclipse CDT + GNU MCU Eclipse, the main purpose of the IDE now is for the ease of point and click debugging and traversing variables and stack traces.

I wouldn't call this fragmented. I see this as the opposite of fragmented. Of course, a nice click-and-point application may give you a simplistic, warm fuzzy feeling, but really, googling for exact instructions for some exact piece of GUI software, where to click to configure memory regions or something like that, when you have a standard way available, expressed textually and processed by your actual tools directly? I think we coders could work out without the sugarcoating. At least for me, it's not an issue.
It is even less feagmented now sine Keil's new ARMCC v6 is based on LLVM/clang - a GCC compatible compiler. Now for ARM it is either GCC (including Keil) or IAR now for toolchain, and from a few tests I seen online GCC actually produces better code for ARM thanks to the contribution of Google (as in Android kernel, the same optimizations used in Android is now benefiting general GCC-based ARM embedded development.)
 

Offline perieanuo

  • Frequent Contributor
  • **
  • Posts: 838
  • Country: fr
Re: Next step from AVR
« Reply #31 on: October 17, 2018, 06:31:57 am »
The next step is ARM <something or other>, no question about it.  There is a question whether STM32 is the way to go but there is a book, "Mastering STM32" that will hold your hand starting with installing Eclipse and GCC and working up.

https://leanpub.com/mastering-stm32

Any time you can get a book, it's a good place to start.

Another way to go:  Look at mbed.org and, specifically, the original mbed (LPC1768).  I use these all the time and I really like the online toolchain.  I don't have to install anything, the binary is 'drag and drop' onto the device and I can work on my code from any PC in the world that has a web browser.  Yes, there are detractors, but ask if they ever did a sizable project actually using the tools.  Mostly it's opinion "I don't like online...".
Hi,
You're missing something VERY important here.
Most of us have a boss,patron,manager or some sh.t like this.How the hell you convince him your code, which is his code from law side of view,it's safe from other eyes?You put encrypted bootloaders and fw on a web site then you explain him this is SAFE?
Sorry, this web equation does not suit everybody at all.
Pierre


Envoyé de mon iPad en utilisant Tapatalk
 

Offline Deku TreeTopic starter

  • Contributor
  • Posts: 35
  • Country: us
Re: Next step from AVR
« Reply #32 on: October 17, 2018, 06:48:32 am »
For me, it was a nice jump from AVR to STM32. Not without hickups, though. But only one major hickup!

The biggest issue I see is lack of tutorials and information about minimal no-bullshit development - similar way everyone works on AVR (not counting Arduino) or PIC. Additionally, there is a lot of noise over the trend-tool-and-framework-of-year development style. It has changed several times during my STM32 career, and no one remembers the older ones! So everyone has relearned their tools. I saw this from the start and never looked at these IDEs.

I had really big issues when starting, due to a broken linker script I found online, and it took fairly long to solve this. But everything else went very smoothly, no problems with tools. Compared to an ever-changing IDE environment (not even talking about the "trend framework of the year"), the great thing in make/gcc/ld workflow is that:
1) It's been the same for decades, and will be for unforeseeable future
2) It's the backend in those IDE-of-the-year kludges anyway, so knowing it directly is the skill.

I wouldn't call this fragmented. I see this as the opposite of fragmented. Of course, a nice click-and-point application may give you a simplistic, warm fuzzy feeling, but really, googling for exact instructions for some exact piece of GUI software, where to click to configure memory regions or something like that, when you have a standard way available, expressed textually and processed by your actual tools directly? I think we coders could work out without the sugarcoating. At least for me, it's not an issue.

STM32 documentation totally sucks sometimes, but the chips are fairly innovative and having something orders of magnitude more capable than an AVR gives you a nice feeling to compensate for the headscratching. If you do AVR-complexity things on STM32, it's not difficult. But if you do some fancy thing you wasn't even able to dream about with AVR, you of course need some heavy reference manual reading and headscratching. This is often about combining the peripherals to work together, without CPU, without interrupts, to produce complex interactions, using peripheral-to-peripheral trigger signals, DMA channels...

One thing to be aware of is that when you have an AVR problem, you quickly find out the answer by googling. Whether it's a specific hardware design problem, a very low level software problem, anything.

When I started, really the only thing you could find out by googling any STM32 issue is that:
A lot of people have proudly bought a devboard and have succesfully copy-pasted 100 lines of bloat library code to blink an LED! Hats off to them, but this isn't helping, and no one was actually doing anything on these chips.

... now, this has finally changed  :phew:, and you will find actual results of  someone actually doing something, and hence, can find some help as well. But it still isn't so straightforward as it is on AVR or PIC. Because both the ARM and the ST guys fucked up the software side by creating too complex, too difficult to use abstraction layers, so the only way to program using these layers was to copy-paste code from Stack Overflow, and then they needed to build code autogeneration tools, and then one of the abstraction layers most people used is now obsolete and not recommended anymore, and then there are different options, and the end result is, the community is totally fragmented. But you don't need to care. Use none of these frameworks/layers and you'll be fine. Do it like you do on AVR.
 
Many are actually writing the code sanely, exactly the same way they did on AVR, but these people tend not to need much help, hence they won't post questions and their code won't show up.

When I started with STM32, I was a bit horrified about the fact there is no help available, but I took the bullet and haven't regretted a bit. I have grown to rely on my own skills more, and trust I can solve any problem. At the same time, I have learned the basic gnu tools properly. The thing is, you are using these tools anyway, either directly or indirectly. The indirect way is changing all the time. The direct way is a skill you won't ever lose.


Thank you, thank you, thank you. This makes complete sense to me, and is really encouraging. I might be messing the terminology up, but is this considered "bare metal" programming/development? As in, no abstraction layers, HALs, etc? The thing I love about working with AVR is that you're sitting right on top of the hardware whenever you write a line of code.

I'm going to go dust off my nucleo board and boot it up. Anyone have first project ideas?  ;D
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #33 on: October 17, 2018, 06:50:00 am »
And vice versa.
Except that there is viable ARM hardware now. What do you not get about it?

Of course there is. No one has ever said otherwise. They have, however, complained about the process of getting a toolchain up and running.

Quote
Do you seriously think that FE310 is a good general purpose MCU? It has fewer peripherals than ATmega and needs more external circuitry to run.

Of course it is not. It's a low volume engineering sample. It's the first tape-out from a small new company, and a low risk simplest-thing-that-could-possibly-work implementation.

It's designed for people to learn the RISC-V instruction set, for testing compilers and RTOS's, and being prepared for the general purpose MCUs that will come soon.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #34 on: October 17, 2018, 06:51:52 am »
but is this considered "bare metal" programming/development?

Yes. And if you are interested in Atmel/Microchip MCUs, I have a bunch of bare-metal examples for them - https://github.com/ataradov/mcu-starter-projects . I can also provide any support you need without referring you to any bloated libraries.
Alex
 
The following users thanked this post: Siwastaja

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #35 on: October 17, 2018, 06:55:21 am »
Of course there is. No one has ever said otherwise. They have, however, complained about the process of getting a toolchain up and running.
Toolchain as in compiler+debugger+IDE.  Not your build yourself from Git stuff. There are great official GCC binaries built by ARM for all platforms. There is no effort involved in getting that going.

It's designed for people to learn the RISC-V instruction set, for testing compilers and RTOS's, and being prepared for the general purpose MCUs that will come soon.
We'll talk when they come. Right now there is no useful RISC-V hardware, there is nothing to talk about. And suggesting it to newbies moving from AVR is plain cruel.
« Last Edit: October 17, 2018, 07:00:04 am by ataradov »
Alex
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Next step from AVR
« Reply #36 on: October 17, 2018, 07:08:15 am »
Thank you, thank you, thank you. This makes complete sense to me, and is really encouraging. I might be messing the terminology up, but is this considered "bare metal" programming/development? As in, no abstraction layers, HALs, etc? The thing I love about working with AVR is that you're sitting right on top of the hardware whenever you write a line of code.

Yes. On AVR, to blink an LED on PORTB pin 5, you do:

Code: [Select]
PRR = something; // turn off the peripherals you don't need to save power (optional)
DDRB |= 1<<5; // set as output
PORTB |= 1<<5; // confusingly named output register we all got used to
delay();
PORTB &= ~(1<<5);


On STM32, you do:

Code: [Select]
AHBENR |= 1<<18; // Turn PORTB on, it's off by default to save power
GPIOB->MODER |= 0b01<<(2*5); // Unlike AVR, the "direction" register has two bits (four possibilities) for each pin. Set as output (01) here.
GPIOB->ODR |= 1<<5;
delay();
GPIOB->ODR &= ~(1<<5);

Not that much different...

But beware, different STM32 products tend to have slightly different peripherals, so you always need to read the exact right manual. This is a bit frustrating. For example, the UART is always slightly different, but it's always as easy as it is on AVR, for example:


Code: [Select]
RCC->APB2ENR |= 1UL<<4;
IO_ALTFUNC(GPIOB, 14, 4); // my fancy helper macro which sets '10' in the MODER for GPIOB pin 14, and the specified alternative function id (here 4 for the USART1) in the AFR register.
IO_ALTFUNC(GPIOB, 15, 4);
USART1->BRR = 100000000/115200;
USART1->CR1 = 1UL<<5 /*RX interrupt*/ | 1UL<<3 /*TX ena*/ | 1UL<<2 /*RX ena*/ | 1UL /*USART ENA*/;

then:

Code: [Select]
void uart_print_string_blocking(const char *buf)
{
while(buf[0] != 0)
{
while((USART1->ISR & (1UL<<7)) == 0) ;
USART1->TDR = buf[0];
buf++;
}
}

This is very similar to how it is on AVR.

You can do it.

I use the toolchain you can download from https://launchpad.net/gcc-arm-embedded . No issues whatsoever (after I fixed my broken linker script...)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Next step from AVR
« Reply #37 on: October 17, 2018, 07:18:09 am »
Regardless of whether you use the Arduino libraries and ide, installing it (and the stm32duino “board” package) is a quick way to get a pretty complete set of working tools.

 
The following users thanked this post: Mr. Scram

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #38 on: October 17, 2018, 07:21:46 am »
Of course there is. No one has ever said otherwise. They have, however, complained about the process of getting a toolchain up and running.
Toolchain as in compiler+debugger+IDE.  Not your build yourself from Git stuff. There are great official GCC binaries built by ARM for all platforms. There is no effort involved in getting that going.

And, as I mentioned in my original message, SiFive has prebuilt gcc toolchain, prebuilt and configured Eclipse IDE, and prebuilt Arduino IDE plug-ins, if you like that kind of stuff.

https://www.sifive.com/boards
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #39 on: October 17, 2018, 07:26:53 am »
And, as I mentioned in my original message, SiFive has prebuilt gcc toolchain, prebuilt and configured Eclipse IDE, and prebuilt Arduino IDE plug-ins, if you like that kind of stuff.
But no usable hardware. What do you want us to do with that IDE? You can use it for in-house development, that's fine.

The Linux board is clearly not a replacement for AVR, nor it is in a requested price range.

Release something, then promote it, not the other way around.

And if that mythical MCU will have the same silly interrupt controller requiring 30+ instructions to enter and exit an interrupt, and a whole bunch of assembly code, then I doubt anyone will be interested. It is not 90-s anymore, thankfully. This and peripherals are the important part. The core is irrelevant really, unless you are fighting some freedom fight, which you will lose even with SiFive, since none of the CPU source code will be published.
Alex
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Next step from AVR
« Reply #40 on: October 17, 2018, 08:20:23 am »
Again: I strongly recommend looking further than ST. I've been using the LPC series ARM controllers from NXP for over a decade. In my opinion these have better organised peripherals so they are easier to use and it is easier to use existing low level code between microcontrollers. The latter is one of the reasons I don't use STM32 microcontrollers. Another reason is that the NXP LPC series have a good (fault tolerant) serial bootloader so they are easy to program by customers if they have to.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: Mr. Scram

Offline technix

  • Super Contributor
  • ***
  • Posts: 3507
  • Country: cn
  • From Shanghai With Love
    • My Untitled Blog
Re: Next step from AVR
« Reply #41 on: October 17, 2018, 11:08:05 am »
Again: I strongly recommend looking further than ST. I've been using the LPC series ARM controllers from NXP for over a decade. In my opinion these have better organised peripherals so they are easier to use and it is easier to use existing low level code between microcontrollers. The latter is one of the reasons I don't use STM32 microcontrollers. Another reason is that the NXP LPC series have a good (fault tolerant) serial bootloader so they are easy to program by customers if they have to.
I do agree on this. Do not limit yourself on one processor family, look around for possibilities.

I use AVR and STM32 primarily, but I also has a blog series exploring 8051 using a Chinese chip, for a few projects I have found PIC more useful, I am currently investigating a M68K based SBC, and for another ARM-based SBC project I even threw in a SigmaDSP in the audio lines just for giggles.
 

Offline snarkysparky

  • Frequent Contributor
  • **
  • Posts: 414
  • Country: us
Re: Next step from AVR
« Reply #42 on: October 17, 2018, 01:43:28 pm »
what about SAMD.   You get an integrated IDE compiler / programmer for free. 
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Next step from AVR
« Reply #43 on: October 17, 2018, 02:50:35 pm »
Again: I strongly recommend looking further than ST. I've been using the LPC series ARM controllers from NXP for over a decade. In my opinion these have better organised peripherals so they are easier to use and it is easier to use existing low level code between microcontrollers. The latter is one of the reasons I don't use STM32 microcontrollers. Another reason is that the NXP LPC series have a good (fault tolerant) serial bootloader so they are easy to program by customers if they have to.
I agree. You're not choosing a religion, so look around and enjoy the wonderful options out there. If only for a little tinkering.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Next step from AVR
« Reply #44 on: October 17, 2018, 02:51:21 pm »
The next step is ARM <something or other>, no question about it.  There is a question whether STM32 is the way to go but there is a book, "Mastering STM32" that will hold your hand starting with installing Eclipse and GCC and working up.

https://leanpub.com/mastering-stm32

Any time you can get a book, it's a good place to start.

Another way to go:  Look at mbed.org and, specifically, the original mbed (LPC1768).  I use these all the time and I really like the online toolchain.  I don't have to install anything, the binary is 'drag and drop' onto the device and I can work on my code from any PC in the world that has a web browser.  Yes, there are detractors, but ask if they ever did a sizable project actually using the tools.  Mostly it's opinion "I don't like online...".
Hi,
You're missing something VERY important here.
Most of us have a boss,patron,manager or some sh.t like this.How the hell you convince him your code, which is his code from law side of view,it's safe from other eyes?You put encrypted bootloaders and fw on a web site then you explain him this is SAFE?
Sorry, this web equation does not suit everybody at all.
Pierre


Envoyé de mon iPad en utilisant Tapatalk

And here I assumed we were talking about hobby level projects...  Of course you won't use the web development site for anything confidential.  Oddly, there is nothing to prevent you from downloading the mbed libraries and using a local toolchain.  I know that Rowley Crossworks can compile the code.  And that gets me to my second point...

Underneath all these pretty IDEs is the toolchain itself.  It costs a batrillion dollars to develop and maintain a  C compiler (with changing standards, slow as they change) and in many cases, the actual toolchain is GCC and friends.  It doesn't matter whose splash screen you see, it's still GCC.  Why wouldn't a vendor choose GCC, it is used by millions of people every day and if there is a problem, it doesn't take long to get it resolved.

As to the splashy stuff, there are vendors using Eclipse as the basis for whatever their IDE looks like.  Why not?  Again, it just costs too much to develop IDEs and Eclipse runs on Linux and Windows - as does GCC.  Fancy up the panels and menus and off you go!

So when you talk about 'fragmented' what you really mean is that there isn't a single downloadable package that installs everything.  That may be true but so what?  "Mastering STM32" gives detailed instructions on how to install the various packages and everything just works.  Or, just Google for 'gnuarm', there are tutorials all over the place.

In the early days of ARM, it was easier to use serial programming and skip the JTAG experience.  So it was just simpler to use Linux.  Gedit is a decent editor, the GCC tools always work and I have forgotten what I used to download the code but the process was quite straightforward.  I still like the old ARM7-TDMI chips, especially the LPC2148.  There is some very nice sample code at http://jcwren.com/arm/

BTW, being able to drop FreeRTOS into a project as happens with PSOC 6 is very nice.  Most of the awkward code is provided by the tools.  I have been following along with the robotic arm project - I just wish it would move a little faster.  PSOC Creator is a very nice toolchain and it does come with a single downloadable installer.


 

Offline GeorgeOfTheJungle

  • Super Contributor
  • ***
  • !
  • Posts: 2699
  • Country: tr
Re: Next step from AVR
« Reply #45 on: October 17, 2018, 09:25:08 pm »
I'm graduating in a few months and have spent about a year working with the Atemga128 in various classes. My latest projects have mostly been with the Attiny85 but these chips are pretty expensive compared to some of the STM32 variants that offer way more functionality. With this in mind, what would you all suggest as a next family of microcontrollers? What would be good for both my own personal development as an (aspiring) embedded guy and for my wallet?

A note I'd like to add: all my work with these boards has been with the linux toolchain rather than an Arduino IDE

The $2 bluepill STM32 is the way to go. The arduino IDE contains everything you need to program the STM32 even without it: all the headers, compilers, linkers and makefiles are there for you to dig deeper when/if you feel like it. This channel is a good starting point, but just search STM32 on youtube, there are a lot more:




The further a society drifts from truth, the more it will hate those who speak it.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Next step from AVR
« Reply #46 on: October 17, 2018, 10:05:32 pm »
Right now there is no useful RISC-V hardware, there is nothing to talk about. And suggesting it to newbies moving from AVR is plain cruel.

Why cruel? He's a hobbyist. He doesn't have a boss who yells at him every morning pressing for results (whatever this is in his mind). Why do you think that repeating LED blinking/LCD driving exercises with STM (after he already did exactly that with Arduino) will fill him with joy? Looking at the first ever open-source RISC-V processor, which does not yet have a fully operational ecosystem, may be something differed and much more rewarding. I think Bruce is absolutely right suggesting this. OP is free to choose what he likes.

 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
Re: Next step from AVR
« Reply #47 on: October 17, 2018, 10:43:27 pm »
The only essential parts are

1) a C compiler and/or assembler for the CPU. That's gcc and binutils and glibc/newlib.

2) a way to get the compiled binary onto the board/chip. That's avdude or gcc+OpenOCD and maybe some JTAG or FDTI hardware
I definitely, want an open source USB device implementation.  Not because I want to use it, but because each USB controller has so many quirks and oddities (like, enumeration doesn't work if the main CPU is in a sleep state - but ONLY enumeration, or that the DMA controller runs on the main CPU clock and on wake from sleep might be too fast for certain PLL settings to settle) that having working code to refer can save a lot of frustration when figuring out some undocumented corner condition that once in a blue moon causes the hardware to glitch out.  USB controllers tend to be hideously complicated, unstructured, fragile, and poorly documented - just like the entire freaking USB mess. (Layering? What's that?!)  And, sometimes, just having a working library, the more naive the better, allows working out what's not working in your own code.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: Next step from AVR
« Reply #48 on: October 17, 2018, 10:48:03 pm »
I definitely, want an open source USB device implementation.
How is this related to any of the previous discussions here?

There are open source implementations of the USB devices FS and HS on the Internet (Verilog and VHDL code), but what exactly it buys you?

There are also simple drivers for some MCUs, including mine for Atmel SAMs.
Alex
 

Offline TomS_

  • Frequent Contributor
  • **
  • Posts: 834
  • Country: gb
Re: Next step from AVR
« Reply #49 on: October 18, 2018, 10:56:02 am »

I was sort of interested in RISC-V, but now it's on my "don't use, don't recommend" list. If an organization needs to spam everywhere to flog it's product, it's not worth using.

Wow. Writing off an *entire ISA* because one guy tries to sell his product? Over reaction much?

As for not recommending it, I hope you don't do much consulting with such prejudices...
 
The following users thanked this post: Siwastaja

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Next step from AVR
« Reply #50 on: October 18, 2018, 03:54:29 pm »
Right now there is no useful RISC-V hardware, there is nothing to talk about. And suggesting it to newbies moving from AVR is plain cruel.

Why cruel? He's a hobbyist. He doesn't have a boss who yells at him every morning pressing for results (whatever this is in his mind). Why do you think that repeating LED blinking/LCD driving exercises with STM (after he already did exactly that with Arduino) will fill him with joy? Looking at the first ever open-source RISC-V processor, which does not yet have a fully operational ecosystem, may be something differed and much more rewarding. I think Bruce is absolutely right suggesting this. OP is free to choose what he likes.

OK, I somehow got interested in the FE310 board.  It starts out with a 48 pin chip so, by definition, IO is limited when compared to a 100 pin chip.  But it does have a UART, 3 PWMs and SPI (master only) with 3 slave selects.  Getting to the details is going to take a bit more reading.  It's also fast!

It uses an external Quad SPI flash for program storage (there is a 16 kB internal instruction cache) and it has 16 kB of data SRAM.  AFAICT, there is no analog input or DAC output (other than PWM).  There doesn't seem to be support for Ethernet (like in the LPC1768, among others).  No USB Host or Device AFAICT.

So, pretty spartan by some measures.  But, as pointed out, this is just one implementation.  Something to get started with.  But, at $59, it's kind of expensive when I can buy an Arduino Nano for about $5.  And the Arduino Nano is pretty well understood.  I'm not comparing speed here, the Nano is SLOW!  The RISC-V is FAST!

Intertia, that's the problem.  Static inertia says "Nobody is using this, prototype projects aren't available, why bother?" and dynamic inertia says "I'm using ARM, it's a RISC core, why bother?".

The ISA is irrelevant to the user in most cases.  They want to pump C in one end and having blinking and flashing come out the other end.  At the hobby level, I'd be willing to bet that most users don't know, nor do they care, how the NVIC works.

Think of how different the PIC, AVR and ARM ISAs are.  They are wildly different and, yet, the PIC 16F series is still being sold.  By the bazillions!


 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Next step from AVR
« Reply #51 on: October 18, 2018, 04:52:25 pm »
IMHO, if brucehoult's company wants to succeed on the microcontroller or embedded market, the ways to get there is:
1) Try to forget your great RISC-V core for a second
2) Try to come up with flexible and numerous peripherals, and
3) Document them clearly.

The managers who want the ARM core on Powerpoint are hard to convince anyway. They need the inertia the most.

But, there are engineer-like managers as well, and sometimes even engineers can make the component decisions. This is where good peripheral sets totally shine, since most engineers are not that interested about the core, as long as it has the basic tool support. This is a free advice for brucehoult, but IMHO they should try to concentrate on the peripherals from day one - and here I can see a huge opportunity for the configurability: Every core licensing company has the same graphical toolset you can use to "design your CPU", meaning, choose whether you have a hardware divider or not, or select the amount of cache, and so on...

No one has done the same for peripherals on a level that would allow building a modern microcontroller. This could be huge; look at high-end microcontrollers that always implement easily over 100 peripherals, of over 30-40 different types, just that the user can use 5 of them and leave the rest unused. Maybe there would be market for custom SoCs in this $5-$15 mid-to-high-end microcontroller market?
« Last Edit: October 19, 2018, 05:24:26 am by Siwastaja »
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 708
  • Country: us
Re: Next step from AVR
« Reply #52 on: October 18, 2018, 05:01:12 pm »
If you want to start playing with an IDE for STM32 (or any other ARM Cortex-M line) that is truly plug-and-play, it's worth mentioning that the free (code-size-limited) version of IAR is pretty capable.  You're unlikely to hit the code-size limit on a hobby project, as long as you don't use the vendor-supplied peripheral drivers (HAL), which as a hobbyist, you shouldn't.

Obvious drawbacks:  Windows only, and a regular license costs serious money.  As a student you would likely be better served by learning how to roll your own gcc-based toolchain.  OTOH, IAR is very widely used in for-profit embedded development, so you might look at it as a job skill, although any engineer worth their salt should be able to pick up a new IDE quickly.

As for STM32 vs PSOC vs others, really, just pick one... they have far more in common than their differences.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #53 on: October 18, 2018, 11:06:57 pm »
No one has done the same for peripherals on a level that would allow building a modern microcontroller. This could be huge; look at high-end microcontrollers that always implement easily over 100 peripherals, of over 30-40 different types, just that the user can use 5 of them and leave the rest unused. Maybe there would be market for custom SoCs in this $5-$15 mid-to-high-end microcontroller market?

Funny you should say that. Already done and in testing internally, switched on for the public soon: https://www.sifive.com/chip-designer

There are already hundreds of IP blocks licensed from various DesignShare partners under a deal where you pay no license fee until you go into volume production.

Both the FE310 and FU540 have been recreated using this flow and taped out to TSMC.

Yunsup talked about this at the Embedded Linux Conference
 

Offline legacy

  • Super Contributor
  • ***
  • !
  • Posts: 4415
  • Country: ch
Re: Next step from AVR
« Reply #54 on: October 19, 2018, 12:18:10 am »
But, at $59, it's kind of expensive when I can buy an Arduino Nano for about $5

Yesterday I went to the restaurant for a business meeting, and when I went out, a few colleagues were complaining they were still hungry because the dishes haven't been filled to the brim and for 60 euro per head it was rather expensive.

The cook was nearby and heard, so he answered something like "well if you compare the street food with a tasting of excellence, you can do similar complaints:D
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #55 on: October 19, 2018, 01:31:21 am »
So, pretty spartan by some measures.  But, as pointed out, this is just one implementation.  Something to get started with.  But, at $59, it's kind of expensive when I can buy an Arduino Nano for about $5.

A fair assessment (not only the part I quoted).

You can by the way buy bare FE310 chips for $25 for 5, and there is also the "LoFive" design done by a 3rd party. The board design is open source, you can make it yourself, and there have been a couple of GroupGets campaigns for assembled LoFives for $25.

https://groupgets.com/manufacturers/qwerty-embedded-design/products/lofive-risc-v
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: Next step from AVR
« Reply #56 on: October 19, 2018, 01:54:58 am »
So, pretty spartan by some measures.  But, as pointed out, this is just one implementation.  Something to get started with.  But, at $59, it's kind of expensive when I can buy an Arduino Nano for about $5.

A fair assessment (not only the part I quoted).

You can by the way buy bare FE310 chips for $25 for 5, and there is also the "LoFive" design done by a 3rd party. The board design is open source, you can make it yourself, and there have been a couple of GroupGets campaigns for assembled LoFives for $25.

https://groupgets.com/manufacturers/qwerty-embedded-design/products/lofive-risc-v

I just looked briefly but I did want to be fair because I just might be interested.  Sure, the board is pricey but so what, education has never been free.  I have a couple of dozen development boards going back 15 years or more.  I don't regret buying any of them.  OTOH, I'm not sure what to do with some of them...

There's quite a bit of documentation and it seems quite thorough.  I don't recall seeing such detail of the internal logic with any other device.

I mainly playing with FPGAs and the PSOC 6 at the moment but that can change in an instant.  Sometimes I think I bounce around like a BB in a bowling alley.

Bare chips for $5 seems very interesting. I prefer to use pre-manufactured boards but I have designed some from time to time.  Mostly I design daughter cards to break out various IO from the factory headers.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Next step from AVR
« Reply #57 on: October 19, 2018, 03:31:50 am »
Bare chips for $5 seems very interesting. I prefer to use pre-manufactured boards but I have designed some from time to time.  Mostly I design daughter cards to break out various IO from the factory headers.

Bare chips are here: https://www.crowdsupply.com/sifive/hifive1
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf