What do you want from MCU vendors? - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 06, 2020, 10:52:58 pm
content: What kind of vendor software support do you expect from MCU vendors?

author: amyk
author_rank: Super Contributor
timestamp: April 06, 2020, 11:55:28 pm
content: A very detailed and error-free datasheet.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 06, 2020, 11:59:42 pm
content: Quote from: amyk on April 06, 2020, 11:55:28 pmAmen to that. I expect an MCU datasheet to be correct and thorough. It should leave nothing to the imagination and spell out the operation of every subsystem in precise detail. Surprisingly, I find that lots of embedded developers are willing to settle for second-rate documentation.

author: wraper
author_rank: Unknown
timestamp: April 07, 2020, 12:01:15 am
content: Device which matches description. Not something like in the datasheet: device has factory USB bootloader, yay. In Errata: No bootloader, and even if you load your own bootloader into bootloader flash area, it won't work. Fix expected sometime later. Then after 2 years since that first Errata: bootloader will happen in devices made 6 months later.

author: ataradov
author_rank: Super Contributor
timestamp: April 07, 2020, 12:02:42 am
content: I prefer to live in a perfect world without wars and poverty. And surprisingly many people settle for a less than ideal world.You pick MCU according to what functionality and price point you need. Documentation ends up being secondary. If you just go by perfect documentation, you will never get anything done.This is unfortunate, but I doubt it will change any time soon.And also notice how when MCU price dropped to 3 cents, people all of a sudden not only got satisfied by no documentation whatsoever, but created their own, and also created their own tools.

author: admiralk
author_rank: Regular Contributor
timestamp: April 07, 2020, 12:28:59 am
content: Quote from: ataradov on April 07, 2020, 12:02:42 amIn a perfect world, the development environments would be interchangeable also. Although that is not realistic.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 07, 2020, 01:06:15 am
content: Second choice is fine with me, along with good documentation. Source code for peripheral drivers is not even mandatory, but it usually helps getting started. Even if I end up writing my own drivers, they complement the documentation and help getting there faster.

author: OwO
author_rank: Super Contributor
timestamp: April 07, 2020, 03:20:53 am
content: My criteria is you need to be able to program for it from scratch using only information in the datasheet and reference manual, without using any code provided by the vendor. The vendor provided driver code is almost always rubbish, and the most I will use from the vendor is the header containing register definitions.

author: westfw
author_rank: Super Contributor
timestamp: April 07, 2020, 06:00:55 am
content: Even your 0th entry assumes a C compiler...Complete and Accurate datasheet.Readable, well-organized, datasheet. :-(Symbol definitions that map "logically" to the datasheet. A C .h file is probably OK, if organized so that it can be used with an assembler as well.A free Assembler capable of using the symbol definitions from (3). Reasonably priced device programmers and/or well-documented programming specifications.Reasonably priced development/evaluation boards.Availability of a reasonably priced, reasonably standard C Compiler that produces reasonable code. It doesn't have to be great code, doesn't have to be free, and doesn't have to be from the Chip Vendor. But it should be good enough to tempt even "moderate" users away from Assembly Language. Preferred multiple OS support.Availability of a high-quality, free, OSSW C compiler.Availability of a high-quality, highly-supported C Compiler. Preferably free OSSW (a gcc or llvm port, I guess), but that has to mean either an assigned team or active community who knows what they're doing. An vendor or partner-provided proprietary compiler is ok, given appropriate quality.App Notes and examples.A book. Should be different than just the datasheet.The tools should be usable with standardized development environments. (I suppose the minimally, that means they should be usable from CLI.) Personally, I don't much care about a vendor-specific IDE, and I'm not even sure it's a good idea.Some sort of pin-use visualization tool. These tend to get wrapped in code generators and drivers, but I'm sort-of thinking that they don't need to be.Peripheral drivers, IFF they provide some useful level of abstraction. I've seen too many vendor libraries that implement "drivers" that are just as obscure as the peripherals themselves. Support of standard high level environments is desirable (I think lwip is a good example, if the chip has an ethernet controller. Linux is a fine example for that class of chip. Arduino is useful but probably too minimal)Additional programming languages - C++, BASIC, Forth, Ada, Pascal (probably in about that order.) (micro/circuit)Python and some Java subset?1-4 doesn't sound like much, but ... Atmel AVRs don't document their touch-controller peripheral or their debug protocol (at least, not historically.) FTDI's VNC2 documentation doesn't seem to include a description of the CPU architecture (!) ST's chip-specific .h files weren't usable from the assembler. "Simple" and well-documented programming protocols are in general a relatively recent phenomena. And we've had whole threads about datasheet quality.Microchip (the chip maker) seems to do pretty well WRT my list. I think they learned earlier than most how useful the hobbyist market is for generating "mindshare."

author: JPortici
author_rank: Super Contributor
timestamp: April 07, 2020, 06:02:38 am
content: Option 1 for me, because the source code for peripheral drivers has to make up for not so good documentation, or complement good documentation with examples for more complex peripherals...Can also be integrated with the documentation, see the dsPIC Reference manuals.I also expect option 1 to contain usb or whatever stack

author: techman-001
author_rank: Frequent Contributor
timestamp: April 07, 2020, 06:17:01 am
content: Re: What do you want from MCU vendors?I don't expect much, but what I would like are detailed datasheets written by a professional writing team, updated errata PDF's and a CMSIS-SVD file for all the registers.That way I can useANYprogramming language I want.That's it.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: April 07, 2020, 07:41:16 am
content: Yes, quality, understandability and accuracy of the datasheet is highly desirable. I believe a datasheet should describe the deviceas it is, not as it was intended to be. If a feature doesn't work, don't put it in the datasheet. If it doesn't meet specs, change the published specs.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: April 07, 2020, 11:26:33 am
content: Extended documentation, discussing all the registers (in English). (For ST, this is a datasheet + reference manual, but Nordic has the registers in the datasheet) Whatever the document is called, I'd like high and low level documentation of all the peripherals. The documentation should cover everthing, so that using the documentation, it would be possible to create my own libraries. (The hardware can often do more then the supplied libraries offer.... sometimes I'd like to use such features). (This would technically also allow to develop drivers in other languages, but for me, I'll stick to C)Furthermore, I'd like libraries/drivers/SDK (whatever the manufacturer calls it) to start developing in C. No C++, just plain C. Drivers for the peripherals, etc. I'd like them to be BSD-licensed. No non-free clauses in the license. I'm a developer, I'd like to concern about code, and not about whether I am legally allowed to combine libraries.Some manufacturers have non-free clauses (may only be used with hardware manufactured by xxx). Such non-free clause would be incompatible with certain licenses such as GPL. Furthermore, some manufacturers don't supply a license, only a disclaimer. (eg. Nuvoton, MindMotion). Am I legally speaking even allowed to use that code? -- So, I'd prefer something with a BSD-style license.I want to be able to compile the code using makefiles. I want to be able to do all setup from code. I do not want to depend on any manufacturer-specific tools (eg. PSoC Creator) to start developing.Then, debugger support. I'd prefer a standard SWD or JTAG debugger port, and OpenOCD support. It is acceptable to have to use a specific branch, but I'd prefer mainline support. Or other tools that support a GDB debugger, eg. dwire-debug for AVR targets)Once again, for me, I'd prefer to just have some libraries, startup files, linker files, etc. Basically, I'd prefer to have one development environment for all my targets. Once I have libraries that can be used with a GNU toolchain and makefiles, and debugging using s GDB debugger, that is satisfied.

author: hans
author_rank: Super Contributor
timestamp: April 07, 2020, 11:58:34 am
content: I would go for option 1 1/2:A good datasheet, that is not putting any registers or bits under NDA or into proprietary drivers.A basic CMSIS library that is enough to get up and running, perhaps with some demos. This is useful for quick prototyping. I don't want any code or framework generator BS, though.A pin planner if you are actually in the planning stage of selecting a chip+package, and want to know if you can fit all your GPIO/ADC/DAC/SPI/I2C/USB/ETH/CAN/LCD/SDRAM/Timer requirements into 64 or 100 pins.. I don't fancy solving a 100-pin riddle to just to find out the 100-pin chip can't run USB, CAN, Ethernet and SDRAM on any of it's 8 alternative IO functions, at the same time.A datasheet with live errata info. Unfortunately, this would probably require a full chip datasheet to be revised a couple dozen times over it's lifetime these days, so I don't think that's very likely..

author: Psi
author_rank: Super Contributor
timestamp: April 07, 2020, 12:27:39 pm
content: What annoys me is that STM32Cube could have been a useful tool.But like a lot of things, to many people try to add too many features and it ends up a mess that does nothing very well.Also, for the love of god, if you're going to have a standard peripheral library include the library version number in all the function calls.A quick find/replace when changing versions is only mildly annoying and is at-least a one-off.But trying to google for code examples and not knowing what code works with what peripheral library is infuriating.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 07, 2020, 02:43:20 pm
content: I am interested mostly what the device does, not what kind of support is provided by the vendor. I expect that what the device does in real life is not too far from what is documented. Everything else I can figure out.

author: ralphrmartin
author_rank: Frequent Contributor
timestamp: April 07, 2020, 04:06:43 pm
content: I'll cut across the survey and other people's replies, and say this: an extensive collection of libraries.This is the reason that Arduino has become popular: not because it has a particularly good ide or debugger, but because it has attracted around it a large set of libraries, which means that if you want to get going quickly, you don't have to start from scratch.Arm have half got the idea with mbed, but it still has a way to go.

author: bd139
author_rank: Super Contributor
timestamp: April 07, 2020, 04:14:01 pm
content: I want off any wild rides. That means:1. Debugger that works properly and quickly.2. Datasheets that actually make sense and are correct.3. A compiler suite without a million layers of shit crud around it that will stand alone without an IDE.4. Something that a human can understand on top of a basic C abstraction without having to dedicated religious amounts of time to overabstractions5. Something that the knowledge will remain valuable for more than the 8 minutes the MCU family is on the market.6. A test suite built in which allows functional testing to be done without having to reinvent a wheel from scratch.7. Dev boards that cost twice as much but are half as shit and don't have solder bridges or weirdness built in by default just to be "more arduino"8. An configuration management system which uses external include which doesn't periodically just roll a wrecking ball right through the middle of your shit and then strut around on top of it like a demented pigeon just because you decided to change a pin allocation.9. Some physical isolation hardware on the programming side so I'm not slowly risking the untimely demise of the USB ports on my laptop (I am down one port on my T470 so far)10. Some documentation of the quality that Microsoft MSDN provides actually on line and integrated with the IDE and well maintained across frameworks and device families.11. Something which actually helps me pick an MCU family and device rather than make it more difficult and confusing or realise you've built your entire universe on a product which is about to be discontinued or only available in bazillion quantities from some reel vendor in China.12. Free hats.

author: Karel
author_rank: Super Contributor
timestamp: April 07, 2020, 04:51:48 pm
content: As usual with these kinds of polls, I would like to see a differentiation between professional/industrial use and hobbyist/maker use.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 07, 2020, 04:59:48 pm
content: Here's what I expect from an MCU vendor:Excellent documentation, usually divided into a datasheet and a reference manual. I would prefer to have errata information incorporated into the reference manual rather than in a separate document. Yes, this is a lot of work for the vendor, but it saves time for users as they don't have to cross-reference separate documents. App notes that explain things in a more detailed, wordy manner are also helpful.If the vendor documentation is originally written in a language other than English and translated, have it proofread by a native English speaker with a technical background.Third-party documentation, such as a book, is nice to have too, but not a necessity.A solid, optimizing C compiler. This is usually GCC, which is fine. Vendor-specific compilers are fine too, even if they cost money, as long as they add value for that money.Excellent debug support. Speed is important here. I don't mind paying for professional tools as long as they add value. My choice here is Segger J-Link. Instruction trace is nice to have too.A complete .h file describing all registers and using names that exactly match the names in the reference manual. I prefer peripheral registers to be defined as structs so I can access them from a pointer initialized to the base address of the peripheral. This *.h should be usable in an assembler file too.Well-commented example code, particularly for any tricky areas that may not be entirely clear from the documentation. This can either be provided as part of the reference manual or as text files. I use this mainly to clarify things not clear in the reference manual.Well-documented (schematics, gerbers, pinouts) development boards. I prefer simpler boards that aren't packed with every external peripheral under the sun. I generally don't need displays, audio codecs, and accelerometers/gyros. A few LEDs, a switch or two, and a complete breakout of all MCU peripheral pins to 0.1" headers. Lots of headers to Vcc and ground are helpful too. For some reason some dev boards for MCUs that support a battery-powered backup domain don't seem to break out the connection to Vbat--I consider that mandatory.I tend to work on projects that span many months or even years, so I don't need quick configuration tools like code generators. I write all of my own code from scratch, including startup code and peripheral drivers, so I don't need or want vendor libraries. I sometimes refer to vendor examples, if available, when I'm debugging my own code, but find that's only necessary when the reference manual is incomplete or ambiguous. Once I standardize on an MCU, I tend to use it, or other members from the same family, so the work I put into developing my own peripheral drivers is amortized over many projects. Most of the vendor code I've seen is poorly written (by summer interns?) and either doesn't support a particular feature of a peripheral I need, or tries to support every possible feature, including ones I don't need, in a way that just increases code size.I prefer to edit code either in an IDE, or with an editor that can parse compiler error messages and take me to the error with a mouse click. I prefer to write my own makefiles, so an IDE or editor that can use them is preferable. Bloated IDEs with configurators and code generators are useless to me. I prefer something small and lightweight. My current favorite is Rowley CrossWorks or Segger Embedded Studio. Good integration with Git is essential.Debugging is a sore point with me. I want a fast, robust debug environment and am willing to pay for it. I don't care much for open source stuff like OpenOCD and prefer tools like Segger J-Link. I like to debug in the IDE itself, or in a separate debugger like Segger Ozone. I prefer to use the capabilities of the debugger (instruction and data breakpoints, single stepping, etc.) rather than sprinkling printfs into the code.

author: snarkysparky
author_rank: Frequent Contributor
timestamp: April 07, 2020, 05:55:24 pm
content: From a high end amateur point of view.Free IDE compiler.Better datasheets. Too many assume things about what you know in their peripheral description sections. Maybe a data sheet lite and a full data sheet.Data sheets all in one PDF. I don't care how big it is. I don't want to open seperate files for SPI A/D ....etc.Example code of bare metal peripheral setup. No bloated libraries.Well I can ask... Dip packages for experimentation.Add basic DSP instructions to more CPU. Just MAC with barrel shifter would be nice.Of course hardware single cycle multiply. Just about everyone has now.

author: Kleinstein
author_rank: Super Contributor
timestamp: April 07, 2020, 06:11:03 pm
content: Have a MCU that can read the data-sheet.If there are significant errata - have them on the first page of the data-sheet. And noted in the DS as well. So you know if some features don't work.Whether one needs extra drivers for the peripherals depends on the complexity. No real need for simple HW (e.g. UART, timer), but something like USB , Ethernet or or HDMI usually needs some drivers / supporting software that also works.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 07, 2020, 07:02:29 pm
content: Quote from: Sal Ammoniac on April 07, 2020, 04:59:48 pmDo you reallyexpectall that. meaning you "regard it as likely to happen" (Google) or "consider probable or certain" (Webster)?Or do you ratherwishit, meaning you "feel or express a strong desire or hope for something that is not easily attainable; want something that cannot or probably will not happen" (Google) or "have a desire for (something, such as something unattainable) " (Webster)?

author: Siwastaja
author_rank: Super Contributor
timestamp: April 07, 2020, 09:00:35 pm
content: Bare minimum is enough, more than that doesn't hurt and understandably widens the audience which has the ability to push unit price down. Crappy buggy IDEs that totally change every year are OK, they have always been like that, and will always be, people who "need" them don't expect more. It's good to waste as little time to build them as possible, keep using some interns for that.Peripheral driver source code only needed if documentation is broken, for reverse-engineering.UP-TO-DATE reference manual (or datasheet), which documentshow the device behaves, not how it was originally imagined to behave before design capture / HDL simulation / product release.Errata sheets are not the right place to document the differences between the documentation and reality; just fix the documentation instead. We have this magnificent thing called revision number, also we have the thing called "The Internet" which can be used to share some amazing things called "files".I don't expect perfection, it's completely OK for me if you release a totally unfinished piece of shit with unmatching documentation (that's a way to get the newest high-tech swag ASAP, I will deal with it, and I know I take a risk if a buy the first revision of an amazing new chip the day it comes out), BUT it's beyond belief that in the digital era of 2020, that same initial pre-production documentation stays for the whole product cycle of over a decade, even trivial-to-fix mistakes aren't corrected (which would be like 0.001% extra work after designing, releasing, documenting and selling a microcontroller!)Get some asperger/ADHD guys to proofread the manual. This isn't some women's magazine, engineering approach is better, look at how pilots communicate, be clear and concise, a good target is that every sentence only has one definite meaning, it's frustrating if you have to read between the lines and guess. If you need to assume and guess the design intent, you could do that without reading the 2000 pages wall of text at all!Looking at you, ST. I guess others have the same issues, though, to varying degrees. Large companies haven't quite figured out this "internet" thing yet despite so much talk about it.

author: westfw
author_rank: Super Contributor
timestamp: April 08, 2020, 01:39:54 am
content: QuoteHmm. Does that have any traction outside of ARM? I guess it could; Atmel had something similar (.ATDF) for their AVRs.Still, there seems to be quite some distance between SVD and actual HLL definitions.(For example, Microchip changed EVERYTHING on SAMxxx between pack versions, even though both versions are presumably based on the same root chip description...https://community.atmel.com/forum/gratuitous-changes-cmsis-types-and-defines-mplabx)

author: ataradov
author_rank: Super Contributor
timestamp: April 08, 2020, 01:45:58 am
content: Quote from: westfw on April 08, 2020, 01:39:54 amWell, that's exactly the point of SVD. You can generate your own header files and not rely on erratic behaviour from manufacturers.I don't like that change, and I will probably start generating my own header files for future projects. I already do that for GigaDevice parts, since their header files are atrocious.

author: techman-001
author_rank: Frequent Contributor
timestamp: April 08, 2020, 06:06:37 am
content: Quote from: westfw on April 08, 2020, 01:39:54 amIt does have traction outside of ARM, but not officially.For instance the Rust folks have made CMSIS-SVD converters for the Ti MSP430 and the tm4c1294, which I use to automatically generate my Forth memmap, bitfield and assembly equ files. It made using these chips *very* easy for me, thanks Rust people!The Atmel SAMxxx range all have CMSIS-SVD's being ARM based.I've never seen a PIC CMSIS-SVD converter, which would be nice as I do have a Forth (Flashforth) for them, but don't wish to have to manually enter memmaps and bitfields as it's far too time consuming and error prone.I think ARM set the standard with CMSIS-SVD and it would be very handy if the other mfrs would adopt it. Just my 2c.

author: westfw
author_rank: Super Contributor
timestamp: April 08, 2020, 10:44:01 am
content: QuoteI don’t know. I want to import other people’s code, buy sw vendors’ code, use code from books, and probably even use code from the chip vendors. The manufacturers symbols would have to be REALLY awful before I’d prefer a foursome of,different schemes. And I’d rather not have it all blow up...Eventually, standardization is more,impotrant than a particularly elegant mechasm in a tinycorner of the chip

author: rhodges
author_rank: Frequent Contributor
timestamp: April 08, 2020, 01:29:28 pm
content: Going back in time, I seem to remember that Motorola (for example) had a prominent page in the manuals asking for feedback to improve the manual.Now, when I see a typo or a confusing description, I can't find any email address to contact the editors. How the hell do they expect to correct their datasheets when they hide their contact information?!

author: NorthGuy
author_rank: Super Contributor
timestamp: April 08, 2020, 01:39:24 pm
content: Quote from: rhodges on April 08, 2020, 01:29:28 pmThe same with the software. There's no way to report bugs. Everything must go through some sort of outsourced tech support. Worse yet, users got accustomed to this, and most don't try at all.Same with banks. I try to call my local branch, but the phone is redirected to nationwide call center, possibly located somewhere in India.Companies don't want to hear from customers. Instead they send you surveys with questions that are mostly irrelevant.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 08, 2020, 02:20:12 pm
content: Quote from: westfw on April 08, 2020, 01:39:54 amBy the very name, CMSIS means "Cortex Microcontroller Software Interface Standard". So CMSIS-SVD files are purely defined for ARM Cortex MCUs.I don't think I have seen CMSIS-SVD "compliant" files for any other targets than ARM Cortex ones. Some vendors have similar files, but they aren't strictly compatible.

author: Bassman59
author_rank: Super Contributor
timestamp: April 08, 2020, 07:33:17 pm
content: I want useful examples that are properly documented. Verbosity in example comments is fine -- tell me WHY you do what you are doing. WHY is this weird library being included.If a configurator tool is provided, I want all of the examples to have configurations that were generated BY THAT TOOL.I want examples that get updated with the tools and the SDKs. So if there's a new release of the tools or the SDK, all of the examples need to be refreshed.Documentation for tools and SDKs must be updated with those tools and SDKs. If a walk-through/"get started" video is provided, make sure it ALWAYS uses the current rev of the tools.Doxygen is not a substitute for actual user manuals. If your code comments are worthless, so is your doxygen documentation.Low-level drivers that basically abstract register accesses are fine.Specifically regarding USB stacks: every vendor has different ideas on how to implement a USB library. Most of them are way overcomplicated. They're ok if you are going to implement the exact device classes for which examples are provided, but to do anything else it's usually a shit-show. All that is really necessary is: a, code that handles reading the device descriptors from one big structure. b, for IN transactions (to the host) provide a WRITE function that takes a buffer and sends it out over the specified endpoint. c, for OUT transactions (from the host) provide a READ function that fires an interrupt or callback when a previously-supplied buffer is filled from a specific endpoint. The Silicon Labs USB library is straightforward and easily extended. The TI Tiva and MSP-432 library is a disaster.And so on.

author: JPortici
author_rank: Super Contributor
timestamp: April 09, 2020, 06:51:26 am
content: Quote from: Bassman59 on April 08, 2020, 07:33:17 pmI sense you're not a fan of silicon labs (or at least their ezradios)

author: Bassman59
author_rank: Super Contributor
timestamp: April 09, 2020, 06:44:39 pm
content: Quote from: JPortici on April 09, 2020, 06:51:26 amActually, Iama fan of Silicon Labs. I've used their 8051 parts since they were still Cygnal. Getting a USB device working on EFM8UB2 wasn't difficult at all. The only hiccup was getting them to explain how the USB device interface would handle throttling data from the host. It turns out that it did exactly what it should do. (And the same interface is present on the EFM32 devices with USB, so porting was straightforward.)The EFM32 parts I've used (TG, GG) were not difficult to get going. The GG11 has a big fail in that the driver for the Ethernet interface is buried in the Micrium OS code and not supported as standalone, so a bare-metal (or other RTOS) design is, uh, not supported. And I wish that they supported High Speed USB, but that seems to be at odds with their low-power IoT push.I have never used their wireless parts (EZR) so I can't comment.

author: JPortici
author_rank: Super Contributor
timestamp: April 10, 2020, 06:23:08 am
content: ezradios check for every point in that list.they can be configured only with their WDS application, god forbid they provide the algorythm to calculate the radio parametersWDS has three output modes:-Header file with many defines containing all sorts of binary blobs, space separated hex numbers-Sample project for their IDE which by the way uses SDCC (puke) and assumes you are using a specific 8bitter from them-Sends the confiuration directly to the demoboard in case one is connectedThe communication protocol is not documented. you only know it's SPI, no idea on the mode or how it works so you need to decipher the sample project, which contains only a handful of comments for the useless bits like "now i'm turning on a LED" and the next function is something akin to "SetLedOn(LED1)"Well, actually one of the datasheets for one of the parts in the ezradio line briefly mention how to communicate with the radio so how to send requests and read data, which i would never figure out in a million years and gives some hints on an initialization sequence, which i couldn't figure out in on my own.Oh, and the information is scattered across several datasheets, app notes and reference manuals some of which won't be found in the product page nor mentioned in other datasheets with thei identification code code so you know it's the right one.But then there is this other archive which contains the programming interface in an htm format. doxygen!!!!! but at least formatted a bit to not look like an aftertought and THAT's probably what you need to understand the various commands, what they expect and what the device responds, once you figure out how to communicateBack to the initialization sequence, only found in the sample project: remember that we have an array of hundreds of space separated hex? how the hell am i supposed to put them in an array? but with a macro of course. containing macros. containing macros. I think four layer of macros unpack the patch because of course there was some formatting to do, every nth bythe is the lenght of the next message, same for the various configuration parameters. It took me a whole day to decypher the macros and port everything to platform independent C because their ancient IDE doesn't do expansion nor symbol navigation and also the funcions, I HATE SDCC with all my heart.Also, undocumented gotchas to put the radio into sleep, how to achieve low power.Once you get over all this the radio itself is pretty nice to use.. well would be better if it didn't have an extremely retarded QFN with 4 LGA pads on the corners containing both power and essential signals. why, oh whybut they're still the cheapest radio chips (by a lot!) that fit my requirementsAt the time i was tempted to try the radio and bluetooth enabled mcus from them to try and reduce costs but i was put off by the lack of documentation

author: up8051
author_rank: Frequent Contributor
timestamp: April 10, 2020, 09:58:55 am
content: Quote from: JPortici on April 10, 2020, 06:23:08 amUnfortunately, they also use this case for EFM8 series processorsIncomplete datasheets are probably the worst.As an example I can give: Microchip PIC32MZ USB HS OTGdocument 61232A.pdf"Section 51. Hi-Speed USB with On-The-Go (OTG)"Preliminary sine 2013Half of the information is missing, an attempt to get more accurate information from Microchip technical service failed.The only source of information is the sample library from the Harmony package.

author: NorthGuy
author_rank: Super Contributor
timestamp: April 10, 2020, 01:28:45 pm
content: Quote from: up8051 on April 10, 2020, 09:58:55 amThey bought an USB HS IP from someone, inserted it into their chips. The IP came with the library, which they simply passed to the user without adding/changing much. There may be no single person at Microchip who knows how it works and can produce better documentation. One of them practically said this on their forum. I'm afraid this is new normal.

author: mark03
author_rank: Frequent Contributor
timestamp: April 10, 2020, 03:49:21 pm
content: Quote from: JPortici on April 10, 2020, 06:23:08 amRadios are to MCUs what GPUs are to application processors: A black box which shall never be publically documented,even ifthis severely constrains actual end-user applications due to lack of timely driver support. Marketing doesn't care. They still get to claim all of the wonderful  capabilities on the "data brief." (Please refer to the unfortunate saga of the Intel Atom processors with Imagination Technologies GPUs, one of which never did get an actual accelerated driver, even on Windows!! The reason: Imagination would only allow their contracted driver-dev team to see the documentation, and they never delivered)Precious IP is the most-cited rationale for these kinds of policies, but it's hard for me to take that seriously. In the case of radios, an additional fig leaf exists in the form of FCC regulations---they can't risk mere mortals fooling around with the radio hardware, never mind the quality/competence of the devs actually producing the closed-source vendor code...Anyway, this is pretty much universal in the RF SoC world, so it's probably not fair to criticize one vendor more than their competitors. At least I know TI (CCxxxx series) is basically the same as you describe.

author: Bassman59
author_rank: Super Contributor
timestamp: April 10, 2020, 06:28:34 pm
content: Quote from: NorthGuy on April 10, 2020, 01:28:45 pmThat's the case with the TI Tiva M4 and MSP-432 devices. The standard user manual has no detail for the USB hardware other than a list of registers. It says that to get access to the manual that has much more detail about how the USB stuff works, you have to fill out an online form and wait to be approved. I did that, the approval was quick (I'm in the US, so I guess it's easier) and there it was.The same thing applies to the Ethernet in the SiLabs GG11 device. They licensed the core from someone and to "keep that IP confidential" they require you to use the Micrium OS which has the driver.

author: wizard69
author_rank: Super Contributor
timestamp: April 12, 2020, 07:05:48 pm
content: Quote from: Bassman59 on April 08, 2020, 07:33:17 pmThe "WHY" is so important that I really don't understand why it gets ignored so oftenQuoteIf they can't update them then with draw them from public view.QuoteThe best thing that could happen is if the entire industry relearned how to comment code. This especially for code designed to be examples of how to use hardware features.QuoteI like your post and have a couple of other things to add.Support a new language for embedded development that moves away from C/C++. For compiled languages I see Rust and Swift as the best two examples moving forward. This probably will upset may a C programmer out there but the idea is to have languages that remove the problems (mistakes) seen in C code.Likewise I'd like to see vendors start to support official MicroPython distributions for a range of chips. I'm basically from the back ground of industrial controls (PLC's) and frankly development times for one off projects is ridiculous. MicroPython is ideal for one off projects that doesn't need performance or that you can throw chip performance at. Having an officially supported version from chip vendors would elevate its status. In a nut shell bridge the development gap between rapid development hardware and hard embedded development.By the way far better IDE's could go a long ways to making rapid development more feasible. I'm not convinced that such really exists yet. However modern desktop computer certainly have the performance to deliver such an IDE. I know some may prefer the slow way of the command line but that isn't exactly a productivity win.