Page 1 of 1

migrating from 16F876 to 18F252

PostPosted: Wed Apr 12, 2006 4:16 am
by phil
Hello Andrew,

I'm having a real problem getting Salvo code, which worked solidly for many months on PIC18F876, going on PIC18F252.

I can send you my code, if you don't mind looking at it, however here's a brief outline of what's happening.

I have four tasks and am using OS_Delay to control how frequently they run. On PIC18, when I decrease the delay time below a certain value the RTOS freezes and no tasks run. This task is setup as the highest priority task, so one would expect the other tasks to stop running, however it's all tasks stop. The same code runs fine on the PIC16. Any ideas or experience of this kind of behaviour? I'm totally stumped for now.



Re: migrating from 16F876 to 18F252

PostPosted: Wed Apr 12, 2006 4:55 am
by aek
Hmmm ... I assume HI-TECH PICC-18 compiler ...

The main difference between PIC16 and PIC18 with PICC/PICC-18 is that there are no banking issues with PIC18, and there is the issue of high- and low-priority interrupts with PIC18. Assuming you're running in compatibility mode on the PIC18 (i.e. all interrupts at same priority), then that is strange. You can send the code in if you like, but please reduce the case to its simplest so that we can figure it out quickly. Best is if it exhibits the problems in MPLAB-SIM -- those are the easiest to debug.

My guess is that it's something interrupt-related, e.g. you have a high-rate interrupt that's consuming all of your processing power.


Re: migrating from 16F876 to 18F252

PostPosted: Fri Apr 14, 2006 12:11 am
by aek
Hi Phil.

All I know is that one of our users reported something similar, and eventually found that the code was in an ISR 99% of the time, and so it appeared to be not working.

One thing you could try is to slow Salvo's timer waaaay down -- e.g. put a sw prescalar in front of the call to OSTimer.

The other way I would debug it is simply to toggle a port pin in main(), just prior to OSSched(), and perhaps also in the ISR that calls OSTimer() and in OSIdlingHook(). That should characterize the Salvo behavior pretty quickly.

Dunno about the other issues -- I would think that a lack of banking would make the PIC18 faster. Note that there are some PIC18 errata that require different libraries and maybe even startup code than the "default" -- see HI-TECH does for more info.


Re: migrating from 16F876 to 18F252

PostPosted: Fri Apr 14, 2006 11:56 am
by phil

I still haven't completely got to the bottom of this. It appears that the overhead of servicing interrupts generated by timer0 is greater on 18-bit cores than 16-bit cores. The timer0 hardware is slightly different on PIC18 and is configurable as 8 or 16 bit timer.

The other possibility you pointed out was another source of interrupts. I've tried to lock everything down in my code, but I may have missed something.

Also, do you think it's a possibility that 18-bit cores can't deal as efficiently with floating point math. My application is fairly intensive as it requires the PIC to do floating point math regulary and Timer0 was set with no prescaler, so the PIC is doing alot of number crunching. I'm using a 20MHz oscillator.

As I mentioned, the 16-bit core had been coping with this and has not given me any problems.

I'll inflict a small portion of my code on you later today, if I can't get any further.

If you have any more thoughts or ideas please let me know.