Pic18f452 Help!

[ManTin361]

Hi everyone!

For those of you that don't know I am currently working on my senior project which is a very simple UAV (Roll/Pitch sensor, altimeter, compass, airspeed). I am using a PIC18F452 as the processor and a RTOS Kernel written in C. I am currently having problems with memory space (my current program is 69K and the PIC only has 32K of program ram!).

I have two solutions and was wondering if anyone has done either of these and had any thoughts. The first one is the most obvious: add more external memory. My other idea is to add a math co-processor. (Maybe both in the end) I think that the memory will be more effective, but I'm using some complex math as I'm sure you’re aware of and the math co-processor will help with increase the timing.

Has anyone out there done anything like this with a PIC, or have any thoughts about it?

Thanks for any help!
Matt

P.S. After I get farther along in this project I plan on posting what I have and maybe my thesis too for all to see if you guys are interested.

[Iraqigeek]

May I ask why are you using a PIC? Why not an ARM7? or an AVR?

[ManTin361]

May I ask why are you using a PIC? Why not an ARM7? or an AVR?

Only because I already had the PICs and the programmer when I started the project, and I don't have the money/time to change. :( Those processors look really cool though!

[Iraqigeek]

So you have the money to buy all the sensors (a single axis gyro will cost you at least $30) and the time to design the PCB for the PICs and interface for external RAM chips, but not enough money to buy a an ARM board or AVR for a little more than $50 which offer you much more processing power and are a lot easier to work with than PICs when it comes to complex programming (remember that ARMs are full fledged 32bit processors).

Take a look at THIS (http://www.olimex.com/dev/lpc-h2124.html) board from olimex, which you can buy at sparkfun (http://www.sparkfun.com), or at the ATMega128 based robostix from Gumstix (http://www.gumstix.com).

[MX]

...My other idea is to add a math co-processor. (Maybe both in the end) I think that the memory will be more effective, but I'm using some complex math as I'm sure you’re aware of and the math co-processor will help with increase the timing...

I don't think adding a math coprocessor would reduce your codesize by more than half.

You could do all your math in fixed point. I did that on my altimeter. If you don't use double or float variables and functions, a big chunk of the C floating point library is eliminated. You'll still probably have to add more memory.

I'm experimenting with an ARM7 from http://www.embeddedartists.com. Comes with a gcc compiler toolset.

MX

[ManTin361]

Thanks for the responses! I didn't realize that those other processors were so cheep. I guess that’s what happens when I don't research ever aspect of my project. (I took a class last year that used the PIC and MicroC OS-II, so that’s what I used in my proposal) I have since found a bigger PIC and will be using that as well as eliminating some of the services within MicroC.

This summer (after I graduate) I plan on expanding the project more. When this happens I will look into changing my processor as well. Maybe AVR?

Thanks for all the help!
Matt

[Nightz]

The PIC will work fine. Dump the RTOS. It's not necessary for the tasks at hand. A well defined state machine with do the job saving you a ton of memory, time, and overhead.

-Rocko

[Gary Warner]

I agree :rolleyes:

[poynting]

I would agree with Rocko as well. You don't need the RTOS. An interrupt-driven system will do fine. Just make sure your stability system (wing leveler) runs first, and run higher level tasks after that (so that in case your high-level code overruns its time, the aircraft won't crash).

If you still have problems, you could always go to a bigger PIC. There are a number that have more than 32k program memory.

[Iraqigeek]

Yesterday I was researching for some info about philips' ARM7TDMI microcontroller line, and came across FreeRTOS (http://www.freertos.org) which happens to have a PIC18 port. According to their FAQ, the kernel takes 4.4KB only on an AVR, which is quite impressive

[Nightz]

Yesterday I was researching for some info about philips' ARM7TDMI microcontroller line, and came across FreeRTOS (http://www.freertos.org) which happens to have a PIC18 port. According to their FAQ, the kernel takes 4.4KB only on an AVR, which is quite impressive

Many RTOS kernels for all flavors of micros are quite small. The one ManTin361 is already using may be similar in size. But, thats just the main kernel/scheduler. All the code required to create, maintain, and entertain a task or groups of tasks tends to bloat your code. So, when chosing an RTOS you need to determine the max number of tasks you will have, the code space required for each task and the actual task code. Add this on top of the kernel size and you have your memory requirment. Add some more free space to be safe.

-Rocko

[mattweisz]

If you are going to college in the US, you can get FREE parts from Analog Devices( accelerometer and gyro evaluation boards... ) If you decide to request some, make sure you have them sent directly to the school( they won't send free samples to addresses other than university addresses)

http://forms.analog.com/Form_Pages/corporate/parts.asp

I would highly recommend using something other than the PIC18F452...an ARM would be lightyears better. But, if you insist on using the PIC...you could maybe use multiple PICs to divide up the workload( one to calculate roll, pitch, heading...one for reading the gps, barometric pressure...) <---- This would make it modular, yet very inefficient...

Matt

[ManTin361]

Matt- I didn't know about the free program at Analog Devices (am aware of a few other companies that have a similar program) Thanks! I also like the idea of running a second PIC I'm going to look into that and see if that seems feasible. Thanks for the input!

Rocko and poynting – I agree that if I didn’t use the RTOS I would greatly reduce the program length. If I wrote it in assembly I would also reduce the program length too (which I as considered) Half the reason that I’m using an RTOS, and MicroC in particular, is because I’m working with my advisor who is currently designing an RTOS class. This is going to be an example that he can use to help promote the course. (Obviously he won’t be able to actually show it flying around inside the classroom!)

I’m not exactly sure how big my Kernel is because I’ve only compiled it with my source code. I have been striping everything out that I don’t need and I’m also optimizing and striping my own code to limit the size. I think right now I should be ok but if it gets any bigger I’ll have to use a second PIC to control some of functions.

Thanks again for all the help,
Matt

[kbosak]

Yesterday I was researching for some info about philips' ARM7TDMI microcontroller line, and came across FreeRTOS (http://www.freertos.org) which happens to have a PIC18 port. According to their FAQ, the kernel takes 4.4KB only on an AVR, which is quite impressive
After compiling the demo For ATMEGA32
I see in PonyProg that it uses Flash up to address 10848, so rather 11KB for simple demo that blinks LEDs etc. Also dont forget you will get 2-4KB RAM max depending on ATMEGA chip used. HEX file itself is some 31KB.