embedded

Is there a relation between endianness of a processor and the direction of stack growth? For example, x86 architecture is little endian and the stack grows downwards (i.e. it starts at highest address and grows towards lower address with each push operation). Similarly, in SPARC architecture , which is big endian , the stack starts at lowest address and grows upwards towards higher addresses. This relationship pattern is seen in almost all architectures. I believe there must be a reason for this unsaid convention. Can this be explained from computer architecture or OS point of view? Is this

I have a real-time embedded app with the major cycle running at 10KHz. It runs on a TI TMS320C configured to boot from flash. I recently added an initialized array to a source file, and all of a sudden the timing is screwed up (in a way too complex to explain well - essentially a serial port write is no longer completing on time.) The things about this that baffle me: I'm not even accessing the new data , just declaring an initialized array. It is size dependant - the problem only appears if the array is >40 words. I know I'm not overflowing any data segments in the link map. There is no data

How do you calculate a percentage from 2 int values into a int value that represents a percentage(perthousands for more accuracy)? Background/purpose: using a processor that doesn't have a FPU, floating point computations take 100's of times longer. int x = 25; int y = 75; int resultPercentage; // desire is 250 which would mean 25.0 percent resultPercentage = (x/(x+y))*1000; // used 1000 instead of 100 for accuracy printf("Result= "); printf(resultPercentage); output: Result= 0 When really what I need is 250. and I can't use ANY Floating point computation. Example of normal fpu computation:

Starting with code like this void lib_memset( unsigned char *dest, unsigned char c, unsigned int n) { while(n--) { *dest=c; dest++; } } using llvm as a cross compiler clang -Wall -m32 -emit-llvm -fno-builtin --target=arm-none-eabi -c lib_memset.c -o lib_memset.bc opt -std-compile-opts -strip-debug -march=arm -mcpu=mpcore -mtriple=arm-none-eabi lib_memset.bc -o lib_memset.opt.bc llc -march=arm -mcpu=mpcore -disable-simplify-libcalls lib_memset.opt.bc -o lib_memset.opt.s llc -march=arm -mcpu=mpcore -disable-simplify-libcalls lib_memset.bc -o lib_memset.s and it detects and replaces it with a

Few days back i had an interview but, still I am searching for the answer. I would like to understand the significance of using volatile keyword. Find the code below: Two different scenario. //project1 //File1.c int abc;//Global variable /*And this variable is getting used in some other files too.*/ if(abc == 3) //Say { printf("abc == 3"); } else { printf("abc != 3"); } /*So if or else part will not be optimized because "abc" can not be predicted, the value can chage at any point of time */ //Project2 //file1.c volatile int abc;//Global variable with volatile keyword /*And this variable is

I am working on a ARM cortex M4 evaluation board, its a bare metal application without any operating system running on it. Now I want to measure CPU usage of a given process/algorithm , what would be the best way to do so? Should i implement an operating system to measure the CPU usage that have the functionality for such demand? The question almost answers itself. What is your bare metal application doing when it is not in that process/algorithm? Measure one or the other or both. If you have a bare metal application that is not completely consuming the cpu in this algorithm, then you already

I've seen a lot of examples how to run a QEMU ARM board emulator. In every case, besides SD card image param, QEMU was also always supplied with kernel param, i.e.: qemu-system-arm -M versatilepb \ -kernel vmlinuz-2.6.18-6-versatile \ #KERNEL PARAM HERE -initrd initrd.gz \ -hda hda.img -append "root=/dev/ram" I am palying with bootloaders and want to create my own bootable SD card, but don't have a real board yet and want to learn with an emulated one. However, if run as described above, QEMU skips bootloader stage and runs kernel. So what should I do to emulate a full boot sequence on QEMU so

I've written a small operating system for embedded project running on small to medium target. I added some automated unit test with a high test code coverage (>95%), but the scope is only the static part. I got some code metrics as complexity and readability. I'm testing my code with a rule checker with MiSRA support, and of course fixed all warnings. I'm testing the code with a static analyzer and again fixed all warnings. What can I do now to test - and improve - the reliability of my OS ? How about the dynamic part ? Try writing some unit tests for the dynamic part. Then run the tests on

PROBLEM I need a way to generate unique values using a preprocessor directive. The aim is that each time the macro is called, it will have a unique integral identifier. But it should retain it's value across files. Kind of like a preprocessor counter for the number of times a call is made to the function. FURTHER INFO The macro I am using is: #define LOG_MSG(a) log_msg(?) 'a' is a string that the user wants to print. log_msg is a custom function used to print a message on the UART The '?' if the part I need help with. This macro would be defined at a single place only. During the preprocessing