If you are a TL;DR kind of person, the title is enough. If not, uncork a hazy IPA let’s see how long you last:
As a starting point, let me say that I have been working with Atmel parts (now MicroChip) for over 20 years now. A long time ago, I got locked into Atmel’s Studio development environment if only because it is a pain in the butt to learn ones all the time. But honestly, their Studio software development and debugging product is really good and gets better all the time. It’s a great example of a product from a company that understands that you it is easiest to sell silicon when it is easy for developers to use. There are lots of silicon vendors out there who know that.
But now, I find myself entranced by the Apollo3 from a silicon perspective, but turned off from a development perspective. An Arduino environment is an awesome starting point. Arduino’s main feature is that you can get running really really quickly because a single install takes care of hiding a myriad of details. Once installed, Arduino is great for running the built-in examples or for creating your own programs based on tweaking those examples. What Arduino is lousy for is developing a program that fills any substantial portion of the Apollo3’s 1 meg of flash or 384K of RAM. Specifically, Serial.print debugging or blinking an LED only gets you so far until you end up with a stack problem or dangling pointer or race condition and you really, really wish you had a real debugger. I have found that the best way to write a complex Arduino library is to develop it in Studio using a real debugger, and port it back into the Arduino environment once it works.
I admit that real Apollo3 development environments with effective debuggers exist, but sadly, they cost real money. Keil’s website says this morning that their cheapest solution is $1530 per year. I’m betting that kind of money is beyond the reach of the average Sparkfun customer. I know you can get a free version that is hobbled to 32K of output code, but again, if your program fits in 32K, just use an AVR. Or for overkill, use a Sparkfun board with a SAMD Cortex M processor. Either way, you can use Atmel Studio for a first-class development and debugging environment.
But still, the Apollo3 sings its siren song. Who can say no to all that memory and such spectacular power specs? Not me, but I’m a sucker for that kind of stuff.
What to do? I see that the Apollo documentation says that Eclipse and GDB was intended to be a development solution up until they hit some undisclosed problem and apparently gave up. But that was back in 2017, and two years have passed. I wondered if they made any progress. There is nothing on their website to indicate that they have, or even that they are still working on it.
With no other options, I thought that I would try the Eclipse/GDB route myself. I must point out that this is not my strong suit. At this point in my life, my goals involve using tools to make things, not making tools. But I dove in anyway.
I have since learned that Eclipse is configurable to the point of utter incomprehension. But thanks to google and to various people all over the world who know way more about this than me, I got Eclipse running in a fashion that generates binary files that I can use the Sparkfun bootloader to push onto my device. But all that just got me to a place where I could stare wistfully at the ‘debug’ icon and wish I could press it. Basically, I spent a bunch of time to create a different version of the Arduino development environment, albeit with a much better editor. But truthfully, I already had the Artemis working with Arduino in Visual Studio Code, so the much better editor already existed. [Apologies to all those out there that think that the only good editor is VIM/emacs/the-editor-you-binge-wrote-yourself-in-one-weekend, but you are wrong] To get back on track, the whole point of the Eclipse experiment was to be able to push that ‘debug’ button.
So I continued to work on that. I found a thing call a “Black Magic Probe” which claimed to debug all Cortex M cores. It contains its own GDB server and that sounded both cool and like one less thing I would have to worry about installing and configuring, so I got one. Days of googling later, and to my utter amazement, it is actually sort-of working. Now I can use my Eclipse environment to edit and build firmware, then I use the Sparkfun bootloader to push it onto the Artemis. And finally, I can actually click ‘debug’. Assuming that the GDB is not in a snit from the previous session, my freshly downloaded program stops running at some random location. At that point, I can hover over variables and see their values. To my delight, I can watch CPU registers change as I single step code execution. Dang! That’s what I’m talking about!! See the attached photo for proof.
But that’s where the happiness ends. Problematically, what I can’t do is make any changes to the flash. This means that the debugger can’t flash a binary file or more importantly, set a breakpoint. So my new debug environment is tantalizingly there and hugely incomplete. It appears that to get full-on debugging capability, I would need to write a driver to go inside the black magic device that would describe all the low-level interactions required to work with an Apollo3. Sadly (for me), writing that driver requires an STM development environment. And almost certainly, a debugger to debug the driver. Amusingly enough, the Black Magic developers say that they can use a second Black Magic device as the debugger to debug their primary Black Magic device, but I’m finally starting to admit that maybe I bit off more than I can chew here.
So that’s where I am: just like Tantalus in Greek mythology https://en.wikipedia.org/wiki/Tantalus, I see lots of tasty icons that appear in reach that I just can’t click.
Sparkfun people, you must have connections into Ambiq. Are there any plans to create a real development environment? Are we on our own? Are there people out there in this community smart enough to write that Black Magic driver for an Apollo3? Or is that something that the Ambiq team could do? They obviously have some talented driver software people.
Finally, thanks for listening. I’m all ears for input on the topic.
P.S. I would be happy if someone pointed out that I was a complete moron for spending my time going down this rathole because solution XYZ already exists. Please, point me at it.
P.P.S. I’m tried hard not to sound like I was whining while spouting off above, but I won’t be put off if you say that I was obviously and completely whining. I still want a development environment with a real debugger. All the cool kids have one.
P.P.P.S. I won’t lie: I wish MicroChip would just buy Ambiq and add support for the Apollo parts to Studio. My life would be easy. C’mon MicroChip: Ambiq is still a private company. They must have some pretty good patents on their processes.
). The silicon costs are obvious to a company, but the costs of homegrown tools are not. But when you have to pay someone else for the tools, those toolchain costs instantly become quantifiable and obvious, which immediately gets the attention of the financial management part of the company.
Just today I stumbled across this guide by SEGGER and am pleased to report that it is more or less working with my SEGGER J-LINK