embedded

I have implemented fputc and fgetc in retarget.c to successfully use printf via UART0 on a Cortex-M3. However, I want a second uart channel for additional debug information. How can I integrate this as nicely as I can UART0 using printf? For example, using fprintf to a custom target and checking in fputc which target to send the character to.. E.g. for normal output fprintf(UART0,".."); and for debug output fprintf(UART1,".."); But I cannot see if fopen is called for stdout so I am struggling to see how to manually implement this. (If I just call fprintf(RANDOM_VALUE,..) , I don't know how

I was recently making some adjustments to code wherein I had to change a formal parameter in a function. Originally, the parameter was similar to the following (note, the structure was typedef'd earlier): static MySpecialStructure my_special_structure; static unsigned char char_being_passed; // Passed to function elsewhere. static MySpecialStructure * p_my_special_structure; // Passed to function elsewhere. int myFunction (MySpecialStructure * p_structure, unsigned char useful_char) { ... } The change was made because I could define and initialize my_special_structure before compile time and

I have some firmware built with GCC that runs on an ARM Cortex M0 based microcontroller. The build currently generates a single binary image that can be written into the program memory of the microcontroller. For reasons to do with field update, I need to split this image into two parts that can be updated separately. I'll call these Core and App . Core : contains the interrupt vector table, main() routine, and various drivers and library routines. It will be located in the first half of the program memory. App : contains application-specific code. It will be located in the second half of the

I'm looking for a way to determine whether an ARM processor is booting from a cold boot (i.e. initial power-on) versus a warm boot (i.e. reset assertion without actual power loss). Specifically I'm using an ARM968 core, will be making the determination using C or assembly, and I will use the determination so certain operations only run on the initial power-on and not on subsequent resets. In previous projects I've leveraged external circuitry (e.g. FPGA) to detect the different boot scenarios, but in this case I am limited to the ARM core. You can initialize a global variable in RAM to a value

I'd have some code that needs to be run as the result of a particular interrupt going off. I don't want to execute it in the context of the interrupt itself but I also don't want it to execute in thread mode. I would like to run it at a priority that's lower than the high level interrupt that precipitated its running but also a priority that higher than thread level (and some other interrupts as well). I think I need to use one of the other interrupt handlers. Which ones are the best to use and what the best way to invoke them? At the moment I'm planning on just using the interrupt handlers

I can't test it but I need to know if it real , because I started working on project for it with .NET 4 so I must to be sure I can install it there. So can I install .NET Framework 4 on Windows XP Embedded ? Thank you. Based on the wiki entry for Windows XP Embedded : Windows XP Embedded, commonly abbreviated "XPe", is a componentized version of the Professional edition of Windows XP. So I'd say yes, because .NET Framework 4 is compatible with Windows XP Professional. .NET 4.0 Framework Template available Microsoft has published a Windows XP Embedded template for the Microsoft .NET Framework 4

I have created a small program as a proof-of-concept for a system which are to be implemented on an embedded platform. The program is written in C++11 with use of std and compiled to run on a laptop. The final program which should be implemented later is an embedded system. We do not have access to the compiler of the embedded platform. I would like to know if there is a way to determine a programs static memory (the size of the compiled binaries) in a sensible and comparable way when it should be ported to an embedded platform. The requirement is that the size of the binary is less than 10kb.