cortex M micros with "good" USB peripheral recommendations? - Page 1
Forum section: electronics / general

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 02, 2017, 01:01:59 am
content: hey all,I am looking to play about with embedded microcontroller USB.I want to get a simple eval board, write a simple embedded application that emulates a basic serial port adapter, and then be able to plug that into something like a raspberry pi, and communicate with my firmware over a terminal window. Like I could already do with any cortex m and an added FTDI chip, but without the FTDI chip..But the array of parts on offer with USB peripherals is so huge, I was wondering if anyone had any USB capable micros they had used and were happy with? I'd rather start leaning on something good, than spend this project trying and discarding different options that don't meet their marketing hype.So shout it out, if you have any experience with something like this where you made a thing that could show up as a serial port on a raspberry pi, were happy with the reliability of the solution, and thought the part had good peripheral support that works, was easy to understand, and made the job as painless as possible. Bonus points if it was a complex project and the USB library *still* just worked reliably like most USART peripheral libraries do.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 02, 2017, 01:05:49 am
content: Ideally I'd like someone to tell me the PSoC5 is great for this kind of USB work, because then I'd also get to play with the configurable analogue blocks, which also seem really interesting. :-)that little PSoC5 eval stick is probably my own pick for arbitrary new manufacturer part and toolchain to try first here, if nobody has anything they really loved working with that they want to shout from the rooftops about.

author: ataradov
author_rank: Super Contributor
timestamp: May 02, 2017, 04:33:17 am
content: They all are not great. I have not seen USB peripheral that would make sense to me yet. You can see that they have been designed by the hardware people, without really thinking about programming interface and convenience.I personally have a lot of experience with Atmel (now Microchip) parts (SAM Dx). And they are fine, after you get past the initial hurdle.I think same can be said about most more or less modern MCUs, but hurdles will be slightly different.And if you want to go with manufacturer-supplied software package, then you are mostly doomed anyway

author: ebclr
author_rank: Super Contributor
timestamp: May 02, 2017, 04:38:06 am
content: After you learn psoc, you will simply forget everything else, Cypress is the Big dog on USBTake a look on this pagehttp://www.cypress.com/products/usb-controllers

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 03, 2017, 06:08:09 am
content: well, I had a play with PSoC creator and it seems straightforward enough.In an hour I had it all downloaded and installed, and had some examples that seem to compile and look well enough organised, and the chip configuration stuff looks like fun! So I've ordered a CY8CKIT-059 to start with.I also just realised that my FRDM-K64Fs that I was using a whole lot last year for another project also have USB peripheral in the micro...Still, 2 different systems to compare sounds OK.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 03, 2017, 06:13:42 am
content: Quote from: ataradov on May 02, 2017, 04:33:17 amYeah, that's why I said bonus points for anyone that's used the USB stack in a non trivial application already, and it's been good...The PSoC range looks small enough that I'm *hopeful* any supplied driver code will be OK. I managed to re-target an eval project from one PSoC 5 chip to another, and it still built the HW setup and compiled the firmware without falling over and catching fire. (So it beats my experience with ASF a few years ago already) I guess I'll see how it works on the chip soon!And trying it out with the K64F is a chance for me to try out the new NXP wrapped remains of whatever they did to processor expert.

author: janoc
author_rank: Super Contributor
timestamp: May 03, 2017, 09:33:54 am
content: I am using the various STM32s - STM32F072 is a good starter, also STM32F303. STM32F103 is cheap and plentiful on eBay and AliExpress, but that is an old chip and notorious for its I2C bugs, so wouldn't be my first choice for projects. There are cheap devboards available from ST - I prefer the smaller Nucleos because they fit in a breadboard, but all of them work.I am not using the vendor software, getting USB working on the above with ChibiOS or libopencm3 was simple enough (especially libopencm3 is a breeze!). Most of what I have been doing was either ACM (serial over USB), HID device or some combination.

author: nctnico
author_rank: Super Contributor
timestamp: May 03, 2017, 10:54:34 am
content: So far I have used NXP's LPC1000 and LPC2000 (older) series with CDC USB implementations (standard serial bridge). These work well and I strongly suggest to always use a CDC USB device because the device drivers will be supplied with every OS (although older Windows versions will require an INF file).

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 03, 2017, 10:57:38 am
content: Quote from: janoc on May 03, 2017, 09:33:54 amcool! good to know. I would probably prefer a newer STM32. Will see what STM32 eval board I can find with a USB part on it, and get one soon.ChibiOs also looks interesting, and I've been wanting a reason to try it out, but I haven't gone out of my way so far because of the licensing.libopencm3 looks pretty cool! Will have to see if it matches any of the dev boards I already have, and give it a spin.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 03, 2017, 10:58:47 am
content: Quote from: nctnico on May 03, 2017, 10:54:34 amYes! driverless install for standard USB device types is definitely something I'd prefer. thanks.

author: krho
author_rank: Regular Contributor
timestamp: May 03, 2017, 07:54:33 pm
content: WEll the libopencm3 has the same licensing as chibios, so it might also not be of interest to you?

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 04, 2017, 10:45:23 am
content: Well the CY8CKIT-059 out of box experience was a success!1) the generic USB serial port project that I loaded up and reassigned to the part on my board worked first go!2) I am looking at making something that needs a simple skin touch sensor, and I was wondering if modern micro capsense could be made to work... I found another simple example project from a bigger eval board - so I downloaded it and loaded it up. Then I configured the project to use my board's micro, I cut out the parts in the HW config I didn't want, and I assigned the capsense and LED pin definitions to match my little eval board, cut out the code from the main.c file that referenced the removed peripherals, and boom. that worked first time too!3) the actual projects for my eval board are pretty fun, too. there's a simple little mouse HID project that takes over my mouse cursor and moves it in a square shape. There's an ADC/UART program that works nice and simply, and a good old LED blinky. All work, and all seem very straightforward when I look through them.The hardest part so far happened the very first time I plugged the board into my PC, and the built in debugger code was old... the error message to update the firmware wasn't well explained and I spent a few minutes clicking about in the IDE looking for what it said I needed to do and scratching my head, before I realised there was a separate standalone programmer application I needed for fixing that...This has got to be the best first steps I've ever had with an eval board and the manufacturer supplied tools. The whole hardware config thing is very unusual, but it was understandable and I could modify it logically to do what I needed with no issues. the code to drive the peripherals that it just makes for you is all well documented, easy to find, easy to follow, and has sensible names for the things I want to do with it.I'm keen to see how it all goes with an extended project.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 04, 2017, 11:31:32 am
content: I use TI's TM4C1294 and find its protocol stack quite useable - I have aLaunchpad board

author: janoc
author_rank: Super Contributor
timestamp: May 04, 2017, 11:09:12 pm
content: Quote from: krho on May 03, 2017, 07:54:33 pmNope, libopencm3 has LGPL3 license now, it has been relicensed recently. So you can use it even in proprietary products as long as you release any modifications to it.Chibios is GPL3 licensed - that is the stronger, "viral" version that doesn't allow closed source products. Then there is a free and full (paid) commercial license for Chibios, if you need it.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: May 05, 2017, 01:53:11 am
content: Quote from: janoc on May 04, 2017, 11:09:12 pmYeah, I thought my quick look at libopencm3 showed it wasn't as drastic as ChibiOs.The free commercial license of ChibiOS is maybe OK to use for a project, but the limitations and requirements placed on it certainly don't make it as attractive as FreeRTOS for a project where you don't know if it might end up commercial one day... it always seems like a gamble to try.

author: krho
author_rank: Regular Contributor
timestamp: May 05, 2017, 07:50:49 am
content: If you think that you are ok if you don't modify it you are wrong and are violating the license. You cannot statically link to any LGPL code. It has to be external library and that just doesn't work on embedded where everything is linked into one executable.If you use LGPL you have toe either release everything under LGPL, or you MUST release everything that's needed for me to rebuild your code (you can provide object files), however you MUST PROVIDE the compiler, linker, linker scripts,.. and tools to program it into the chip again.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2017, 10:08:19 am
content: Quote from: krho on May 05, 2017, 07:50:49 amYou have got this completely wrong. GPL=release all sources. LGPL=use in proprietary software allowed

author: krho
author_rank: Regular Contributor
timestamp: May 05, 2017, 10:56:07 am
content: I didn't say you can't use it. I just wrote down the conditions under which you can.For me that's too much hassle, so I tend to avoid even LGPL on embedded systems.edit:Chapters 10.7 and 10.8

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2017, 01:13:54 pm
content: Quote from: julianhigginson on May 05, 2017, 01:53:11 amAFAIK, the free license only requires registration on the website, which is fairly reasonable, IMO. However, I didn't investigate farther as I don't have the need for it. You can develop with the GPL licensed version and when you decide to go commercial and release the product, then you obtain/buy the commercial license if you don't want to publish the code (the GPL license provisions trigger only once you distribute the code, e.g. in your device, not when you only use it). This mode of operation is, in fact, encouraged - the website says explicitly that the commercial license is not for evaluation (use the GPL3 code for that - it is exactly the same code).The comparison with FreeRTOS is not really fair, because ChibiOS gives you not only the RTOS but also the complete HAL (device drivers), USB stack and tons of other things. FreeRTOS is only bare bones RTOS - i.e. the kernel doing task scheduling and task synchronization.

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2017, 01:30:57 pm
content: Quote from: krho on May 05, 2017, 07:50:49 amThat's not true. What you do need to distribute in the case of a GPL license is the source code of the entire application in a form that is rebuildable and can be deployed on the target system - i.e. including the makefiles, build scripts, whatever you use, including any encryption/signing keys if the firmware deployment requires it (the anti-tivoization provision).Stuff like compilers, linkers or programming toolsyou don't needto distribute. It may not even be possible if the toolchain is proprietary, for example.The license cannot and does not require you to distribute 3rd-party tools and components that may be required to fully use/rebuild the software - that's the end-user's responsibility to obtain them if they want to rebuild your code.From the GPL text on what is considered "source code":QuoteIn fact, this is part of the GPL FAQ too:https://www.gnu.org/licenses/gpl-faq.html#NonFreeToolsQuoteIf you use an LGPL component, this appliesonlyto the modifications of that component (NOT to your own code). If you use e.g. libopencm3 without modifications, there are no special obligations for you - you distribute the upstream source code libopencm3 (or point to their upstream repository where it can be downloaded - that is considered acceptable). The GPL restrictions don't propagate to your own code - LGPL licenses are not "viral". If you have modified the library (e.g. to patch a bug or add support for a new hw), then you need to distribute only source to that modified library, nothing else.This is no different than dealing with code using any other OSS or proprietary licenses - many will require you to e.g. to put a mention in the documentation or display a notice on the screen. And proprietary licenses could demand really crazy things - check the EULAs for Microsoft's SDKs sometime, for example.

author: tszaboo
author_rank: Super Contributor
timestamp: May 05, 2017, 01:45:13 pm
content: Quote from: nctnico on May 03, 2017, 10:54:34 amYes, LPC1000 has nice USB stuff. The LPC1343 for example has USB driver stuff in ROM, meaning you cannot even break it. Just a few magic calls into unknown memory space.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2017, 02:31:03 pm
content: Quote from: NANDBlog on May 05, 2017, 01:45:13 pmTrue. There are some minor errors in there though which need a workaround but the examples look pretty painless to start with. I never used the ROM routines though because I already have a working USB device stack.

author: krho
author_rank: Regular Contributor
timestamp: May 05, 2017, 06:10:39 pm
content: @janoc: Please read the linked paragraphs. You are wrong.

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2017, 06:44:31 pm
content: Quote from: krho on May 05, 2017, 06:10:39 pmCare to show me where am I wrong? Nothing in those 2 paragraphs you linked contradicts what I have said.The license is very explicit about what is considered "source code" (and thus has to be distributed) and explicitly excludes third party stuff that isn't part of the work.I suggest you read this:https://www.softwarefreedom.org/resources/2008/compliance-guide.htmlOf course, if in doubt always consult your lawyer (but many are clueless about OSS licensing, unfortunately).

author: krho
author_rank: Regular Contributor
timestamp: May 05, 2017, 08:11:34 pm
content: QuoteThis applies when you compile to a static binary which is in a case you use a micro-controller.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2017, 09:12:07 pm
content: No sane person would release anything under any xGPL >2.0 license because the GPL people went completely bonkers after that version. LGPLv2.1 §6(a) reverses LGPL back to GPL which isworthy. WxWidgets for example explicitly removes the requirements of LGPLv2.1 §6 from it's license.

author: free_electron
author_rank: Super Contributor
timestamp: May 05, 2017, 09:44:05 pm
content: my frustration with all usb microcontrollers is that the usb stack is a resource hog.why can't they make simple a simple system that does not require software overhead ?the pc side driver has 4 functions : opendevice, readblock and writeblock closedevice.writeblock (handle, pointer to array holding data, blocksize )readblock (handle, pointer to receive buffer , blocksize )in the micrcontroller side there is a memory block ( 64 bytes for example, size of a single usb frame ) when a packet comes in : interrupt.when a read request comes in : interrupt. you set a flag if data is ready to get picked up.it does not need to be harder than that. you would not need any software overhead.a device would be addressed by its vid pid and a serial number ( usb has provisioning for serial numbers )handle = opendevice (vid,pid,serial or portnumber)closedevice(handle)who makes this universal code ? lots of people would be very happy. the driver would be universal.pc side driver :Getdeviccount : lists how many devices there areGetdeviceinfo (index, byref vid, byref pid, byref serial, byref vendornamestring , byref productnamestring, byref portnumber ) :gives you the info about the device so you can scan all available devices and pick up the one(s) you are interested in.opendevice (vid,pid,serial)overload opendvice (portnumber)readblock (handle,blocksize,pointer to buffer)writeblock(handle,blocksize,pointer to buffer)all calls do sanity checking to avoid buffer overruns and detached devices.if devices detach the readblock returns all zeroes.if allocated buffer is smaller than requested bytes then only buffersize is read. same if the other side ( device side ) has different buffers.optionally there would be a mechanism to find out the size of the buffer in the device.Getbuffersizes(byref writebuffersize, byrefreadbuffersize)

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2017, 09:48:58 pm
content: Quote from: krho on May 05, 2017, 08:11:34 pmSo provide a bunch of .o files or a .a archive and let the end-user relink the firmware, if they so desire. Where is a problem in that? It requires only theobject code, not source.If your point is that I have missed this special case, yes, there you are right - I am more used to the normal shared library linking and didn't think of this one right away.

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2017, 10:12:11 pm
content: Quote from: nctnico on May 05, 2017, 09:12:07 pmThat's BS. It requires only object code or source, not both of the rest of the app - it says "object code and/or source code" there.Fromhttps://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic(emphasis mine):QuoteThis clause has always been there in a slightly different form, LGPL 2.1 and 3.0 only clarifies it. LGPL 2.0 was calling for distributing of "all data and tools" required to recreate the executable using the library, which essentially implied that you had to distribute either source or the object files (or both). However, it could have been problematic depending how a court would read it - it could have been interpreted as requiring also the distribution of OS, compilers, etc., which wasn't the intent. That's why it has been made explicit in 2.1 and later revisions. So there is no "reversion to GPL" (which does requiresourceof the entire application to be distributed) there.Distributing object files is not that uncommon - e.g. Nvidia drivers for Linux are binary blobs with a kernel-specific layer. The latter is distributed in the source form and links to the blob. SCO Unix kernel was also distributed as a set of .a archives and relinked each time a new module/driver was configured. Etc.And yes, those linking exception clauses are common, also OpenSceneGraph has one and a lot of other LGPL-licensed software. Libopencm3 is also considering adding it:https://github.com/libopencm3/libopencm3/wiki/LicensingThese licenses may not be a good fit for your project but there is no need to demonize them neither.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2017, 10:23:02 pm
content: Quote from: janoc on May 05, 2017, 10:12:11 pmWhich goes against the whole idea of LGPL in the first place! Maybe I had an earlier LGPL version in mind but the whole idea of LGPL is to use open source libraries in proprietary applications without restrictions so companies would be more inclined to contribute.

author: ataradov
author_rank: Super Contributor
timestamp: May 05, 2017, 11:17:33 pm
content: Quote from: free_electron on May 05, 2017, 09:44:05 pmThat is because things are designed by committees of people, who have noting else to do. The whole USB architecture is a monument to overthinking and over-engineering.

author: tszaboo
author_rank: Super Contributor
timestamp: May 06, 2017, 12:28:45 am
content: Quote from: ataradov on May 05, 2017, 11:17:33 pmThe more I looked into the USB specification, the more I think it was designed by complete idiots and software engineers (there is a very fine line between the two, sometimes there isnt).And then the implementation... A mess of callbacks, 1khz interrupts, data interrupts referencing pointers to callbacks which send magic numbers. A wierd and wonderful mix of things which are handled by the hardware, and things that isnt. If you try doing anything, that is not supported, you are officially screwed. You would like to have two endpoints on your device, one operating as a HID the other as a CDC? Too bad. Ah you would like to have isocronus transfer. We dont support that with this microcontroller. If you are able to read, it is clearly written on page 1523 of the reference manual, in the footer.

author: true
author_rank: Frequent Contributor
timestamp: May 06, 2017, 01:45:34 am
content: The situation isn't that bad today NANDBlog, but to do more than what demo code allows, requires being able to think, some good documentation and discovering undocumented pitfalls, traps, bugs and the like. And there usually isn't good documentation.But with today's USB hardware, even with vendor stacks, you can get custom complicated yet still maintainable things done. (I've done it now with a few vendor stacks...)

author: janoc
author_rank: Super Contributor
timestamp: May 06, 2017, 01:38:43 pm
content: Quote from: nctnico on May 05, 2017, 10:23:02 pmI am not sure which LGPL license you had in mind, all that ever have been in use are from 2.0 upwards.I think this is getting a bit off-topic, but don't you think that telling GNU what the ideaof theirlicense is is strange? Their position is that you are not supposed to use LGPL at all.The notion of unrestricted use in proprietary software has never been the goal, that's completely the opposite to what GNU has ever stood for. If things were going their way, there would be no proprietary software at all and no LGPL. Which is an unrealistic, extremist position, IMO, but that's all we can do about that.The (L)GPL idea has always been that the end-user must have the freedom to modify and replace the (L)GPL licensed code, even when used as a part of a larger (potentially proprietary) system. LGPL has only relaxed the GPL restrictions placed on the rest of the code by allowing dynamic linking and not requiring application source when you use static linking, object code is enough. That covers the 90% of the common use cases and permits to use LGPL libraries in proprietary code as a side effect (and it is commonly done).Now static linking for device firmware was not likely even on the radar when these licenses were designed and there the license isn't ideal. On the other hand, with a bit of care it is manageable.

author: Koen
author_rank: Frequent Contributor
timestamp: May 06, 2017, 07:46:14 pm
content: There's a neat little table at the end of ChibiOS licensing page that'll clear things up for future enthusiasts :http://www.chibios.org/dokuwiki/doku.php?id=chibios:licensing:start

author: julian1
author_rank: Frequent Contributor
timestamp: May 06, 2017, 08:54:53 pm
content: Quote from: nctnico on May 05, 2017, 10:23:02 pmThat's the normal case for LGPL - when an application is dynamically linked by the OS at runtime when the process starts.I believe the extra requirement for static linking - to make available one's own objects/libs (not necessarily source) is so that the end-user is not prevented from re-linking and re-deploying - in order to pick up a fix or new feature in the LGPL code.This is unnecessary in a dynamic linking context because the end-user never lost that ability in the first place. Ie since the *.so or *.dlls can be swapped in or out at will..

author: chicken
author_rank: Frequent Contributor
timestamp: May 07, 2017, 02:37:00 am
content: Does anyone have experience with the Silabs / Energy Micro USB stack?