There is also support for the Segger IO debug mechanisms so that you can use printf() to send data to a terminal window hosted by the debugger. And of course, when the program you are writing crashes into the ARM hardfault handler for the umpteenth time, the hardware debugger lets you work backwards through the callstack to find out why. You can even single step through the libraries or set breakpoints inside them just like any other software you write. Doing so enables you to use the SES editor to walk through the Ambiq sources, or jump directly to where one of your Ambiq HAL calls is defined so you can see how it works. I have found it hugely useful to use the SES symbolic directories to include the Ambiq Suite sources in every project. The best feature is that attaching a J-Link EDU or J-Link Mini will allow you to reflash firmware, examine call stacks, set breakpoints, watch variables, and do everything that a hardware debugger enables you to do, all of it integrated natively into the SES IDE.
#Segger embedded studio icons full
If you replicate what I have done, you will be able to write Artemis software in C or C++ with full access to the Ambiq Suite libraries. But the whole reason for using SES was to get native support for full hardware debugging, as detailed here viewtopic.php?f=171&t=50960.
SES is based on GCC, so the code quality is excellent. Unlike Keil and IAR, SES is free for non-commercial use without the crippling code-size limitations of the free version available from Keil and IAR.
Hi all, I have been using Segger Embedded Studio with my Artemis boards now for over a month.
0 kommentar(er)
