embedded

I would like to capture, decode, and view ITM trace information for a Cortex-M4 MCU (in my case, an Atmel SAM4S). In particular, I want to capture exceptions and user trace data relative to other signals on my board (i.e. show all signals and trace information on same timeline). This can be done using the following steps: Place debugger in SWD mode. If using J-Link Segger on Linux, this can be done with JLinkGDBServer -if swd Add code to the MCU to enable trace. Set the bit rate to a value suitable for your needs (I used 8 MHz). Example Ada code is below. Use logic analyzer to capture trace

How do operating systems detect stack overflows of user-space programs [and then send SIGTERM or SIGSEGV to those userspace programs] ? The answer will depend on the target architecture and the particular OS. Since the question is tagged Linux, you have rather biased the question which on the face of it seems more general. In a sophisticated OS or RTOS such as Linux or QNX Neutrino, with MMU protection support, memory protection mechanisms may be used such as the guard pages already mentioned. Such OSs require a target with an MMU of course. Simpler OSs and typical RTOS scheduling kernels

I am running a bare metal embedded system with an ARM Cortex-M3 (STM32F205). When I try to use snprintf() with float numbers, e.g.: float f; f = 1.23; snprintf(s, 20, "%5.2f", f); I get garbage into s . The format seems to be honored, i.e. the garbage is a well-formed string with digits, decimal point, and two trailing digits. However, if I repeat the snprintf , the string may change between two calls. Floating point mathematics seems to work otherwise, and snprintf works with integers, e.g.: snprintf(s, 20, "%10d", 1234567); I use the newlib-nano implementation with the -u _printf_float

I have to program peripheral registers in an ARM9-based microcontroller. For instance, for the USART, I store the relevant memory addresses in an enum : enum USART { US_BASE = (int) 0xFFFC4000, US_BRGR = US_BASE + 0x16, //... }; Then, I use pointers in a function to initialize the registers: void init_usart (void) { vuint* pBRGR = (vuint*) US_BRGR; *pBRGR = 0x030C; //... } But my teacher says I'd better use #define s, such as: #define US_BASE (0xFFFC4000) #define US_BRGR (US_BASE + 0x16) #define pBRGR ((vuint*) US_BRGR) void init_usart (void) { *pBRGR = 0x030C; } Like so, he says, you don't

I came across code similar to the following today and I am curious as to what is actually happening: #pragma pack(1) __align(2) static unsigned char multi_array[7][24] = { 0 }; __align(2) static unsigned char another_multi_array[7][24] = { 0 }; #pragma pack() When searching for a reference to the __align keyword in the Keil compiler, I came across this: Overalignment of execution regions and input sections There are situations when you want to overalign code and data sections... If you have access to the original source code, you can do this at compile time with the __align(n) keyword... I do

I'm looking for a very portable, minimalistic/small XML/configuration language library in ANSI C with no external dependencies (or very few), compiling down to less than 100K. I need it for a moderately complex configuration file, and it must support Unicode. Some more requirements: OK to use/embed/statically link into proprietary code . Credit will always will be given where credit is due. Not necessarily XML. Really, clean code /no weird or inconsistent string handling. UTF-8 . Thank you fellas. karlphillip This is somehow similar to this question: Is there a good tiny XML parser for an

This question already has answers here : Closed 3 years ago . Dynamic memory allocation in embedded C (3 answers) I am working with an embedded system. The application is running on AT91SAMxxxx and cortex m3 lpc17xxx. I am looking into dynamic memory allocation as it would dramatically change the face of the application (and give me more Power). I think the my only real route is to set out an area of memory for a heap and design a tailored malloc that best fits (pun) my purpose. When looking at different algorithms for memory allocation you cant not stumble upon Doug Lea's malloc. I take it