Next step from AVR

[ataradov]

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.

[technix]

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.

[brucehoult]

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.

[richardman]

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.

[Siwastaja]

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  , 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.

[technix]

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.)

[perieanuo]

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

[Deku Tree]

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  , 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? 

[brucehoult]

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.

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.

[ataradov]

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.

[ataradov]

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.

[Siwastaja]

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...)

[westfw]

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.

[brucehoult]

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

[ataradov]

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.

[nctnico]

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.

[technix]

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.

[snarkysparky]

what about SAMD.   You get an integrated IDE compiler / programmer for free. 

[Mr. Scram]

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.

[rstofer]

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.

[GeorgeOfTheJungle]

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:

[NorthGuy]

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.

[bson]

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.

[ataradov]

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.

[TomS_]

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...