Hi guys,I'd be interested in hearing some opinion and/or discussion around development tools and UX. As we all know, creating BLE applications with any tool, is not especially easy. Not talking about learning platforms like the micro:bit. But for "real" development platforms in general.
This was one thing that I discovered when starting with Nordic: In spite of the ingenious design of SoftDevices and the SDK, the toolchain of the nRF products may not be the easiest to get your head around. There is no single download-to-rule-them-all or wizard-based code generators. There are overview tutorials and code examples to start with, where you usually choose an example that fits one of the peripherals you want to work with. But the moment you need to integrate more perihperals, as is most often the case with BLE applications, the next step may be a bit obscure. And fiddly.
Having worked a fair bit with the Atmel AVR, the difference was very tangible. Atmel had AVR studio, which was an integrated development and debugging platform. It included gcc and connected and updated external hardware tools automatically. Then Atmel Studio, also including the choice of which modules to include in your project and do some initialization housework at the click(s) of a button(s). There was also, the Imagecraft and CodeVision compilers/IDEs which had a setup wizard included; allowing you to setup peripherals like timers, GPIO and ADC without writing code.
The AVR range is of course not directly comparable to the nRF products in terms of features and performance.But what do you think - are there similar approaches that would benefit the nRF products? Maybe you think the tools are just fine, but agree that some more integrated tutorials and examples could be useful?What are your most appreciated features of a development toolchain?
Cheers and thanks;Eivind :-)
you can take a look at this tool for code generation: https://vicara.co/nrf52-code-generatorIt currently supports GPIO, GPIOTE, PWM, UART, SPI & TWIM with Segger Embedded Studio project file…
Thoughts on development tools? I have them.
Segger Embedded Studio is a buggy, unreliable, nigh-unusable abomination of a tool that belongs in the dumpster with NetBeans.
Atmel Studio (is it just AVR studio…
evanperrygrove said:Atmel Studio (is it just AVR studio now?)
It was originally AVR Studio, then changed to Atmel Studio when they added the SAM (ARM) support - many years ago.
It has recently been renamed…
Atmel Studio (is it just AVR studio now?) was okay when I used it. Certainly better than MPLab X or Infineon's DAVE tool. That said, I have found that the best workflow for me, on any company's microcontroller, is to write code in whatever text editor I feel like (over the years, that has been everything from Kate, to VSCode, to a custom fork of Sam), compile in a terminal, then debug in Ozone.
Only once did I find a codegen tool to be useful, and that was ST's CubeMX tool. I only used it once, to generate some DSP code. I got the impression that reading the manual a bit more thoroughly would have made CubeMX completely unnecessary. CubeMX doesn't necessarily generate code that fits your company's semantics or best practices. Not the end of the world, but certainly an annoyance when taking code from CubeMX and integrating it with an existing codebase.
I have to give Nordic credit for getting their SDK structure just about perfect. Easy to install, and easy to make it compile properly, at least compared to similar libraries from ST, Infineon, and Microchip. Including makefiles with SDKs seems to be a difficult thing for some manufacturers, and the reasons for that are beyond me. Nordic gets it right by including makefiles in their SDK that require no project-to-project modification, and that are agnostic to the position of your project relative to the SDK source tree.
nRF5 (and all of Nordic's python libraries, as well) fall flat when it comes to documentation. Their documentation is by far the worst of any ARM chipmaker I have worked with. It is not difficult to run your doc comments through Doxygen, and throw the result up on GitHub Pages. There is no excuse for DevZone to be as active as it is- documentation should not need to be crowd-sourced. Perusing old DevZone posts is not a substitute for proper documentation, and Nordic should be ashamed that its community relies on this website as much as it does. So there.
It has recently been renamed "Microchip Studio".
evanperrygrove said:documentation is by far the worst of any ARM chipmaker
Not so sure about that - but certainly not good.
evanperrygrove said:It is not difficult to run your doc comments through Doxygen
That is what they do - which means that there's no use looking to code comments for extra info.
And the common problem with (nearly?) all Doxygen-generated documentation is that it fails to give the Big Picture.(that's not necessarily the fault of the tool itself - just of relying solely on code comments).
awneil said:It was originally AVR Studio, then changed to Atmel Studio when they added the SAM (ARM) support - many years ago.
Ah, that makes sense. I didn't get into the Microchip ecosystem until a couple of years ago, so I must have come in long past the name change.
To be clear: Nordic has the worst documentation of any Cortex-M chipmaker I have used. I have used ARM microcontrollers in a professional capacity from these manufacturers: Microchip, Infineon, ST, Nordic. I won't speak for TI, Renesas, NXP, or any of the others.
I found ST's tools to be the best. Their documentation is phenomenal, and their libraries are easy to set up and use. The open-source community surrounding them is massive, which also helps. Microchip's documentation is even better, but I wasn't a fan of their libraries. ASF is finicky to set up properly, but the HAL underlying ASF is too low-level to be helpful on its own.
Infineon's documentation is wordy and difficult to read. If I recall, the reference manual for one of their simplest Cortex-M0 chips was 1800 pages. That said, I'll take "too much documentation" over "not enough documentation."