Passing any arrays by value or pointer does not work very well.
I can try integrating an array into a structure, but that is not how I would do it.
if I have: frame( unsigned char &mbrtubuf, int &uslen) and the receiving side is :
frame ( unsigned char *somepointer, and int *uslen) neither of the variables are passed
correctly to the function. Prototype is in a header file. Does not work and when it does work
its becomes unstable. Terrible compiler. It should work and I should even have to think
about it. I spend more time on the Compiler then I do on the actual program.
The only way I can get the array into a fucntion is by declaring it external in the function.
Any ideas
Phil
You wrote:
Terrible compiler. It should work and I should even have to think about it. I spend more time on the Compiler then I do on the actual program.
But in the end, you don't know standard C and the needs for "extern" to tell the compiler that there exists a variable somewhere, but don't allocate a copy of it in this specific file.
You have two choices for global variables. Either have a global variable visible only inside a single source file. You do that with a "static" keyword, telling the compiler to hide the linkage information for the variable - basically making the variable into an anonymous, unnamed, global variable.
Or you can share a global variable between multiple files. In which case you can allocate the variable in one single file. And then let the other files know about it with the "extern" keyword (using header files).
The above is standard C. It isn't a "terrible compiler" but a minimum requirement for a standards-compliant compiler.
Have you looked for some good C books? After having gained enough knowledge, it's then time to get the ISO standard.
Besides that, you also do need to walk through the manual for the Keil C51 compiler, to find out what platform-specific things you must know about.
When something doesn't work, it's (at least) a 99.99% chance that it is a user error, and not a compiler error. Blaming the tools just hurts you, since that only means you spend your time looking in the wrong direction. In this case, you complained about the time you have spent on the compiler instead of on the program. Maybe that time should have been spent on manuals and the C language instead?
For debugging, you need to go multiple routes, depending on what problems to look for.
You can use GPIO with LED to measure the runtime of interrupts. You can compute the number of interrupts/second your program needs. You can figure out the potential timing problems based on your real-time needs and the interrupt load.
For finding logic errors, it's normally best to deactivate different parts of the code and try to debug module-by-module.
You also need to spend time just reading the code. For all interrupts you have, you must look at what global variables they make use of, and make sure that your code can correctly share these variables between the interrupt handler and the main loop code.
You also have to track down any function call you make from an ISR. Are any of these functions also called from the main loop? If so, the function needs to be reentrant. But it is normally best to duplicate that function and have one copy called by the ISR and one copy called by the main loop. Even then, you must check the usage of global variables and make sure that a switch from main loop to ISR processing at any single point in time will be safe. If it isn't, then you have found a critical section. And critical sections must be protected - in some situations by blocking interrupts while inside the critical section.
www.catb.org/.../smart-questions.html