avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Function Pointers on AT90USB1287 and ATmega2561


From: Peter LaDow
Subject: Re: [avr-gcc-list] Function Pointers on AT90USB1287 and ATmega2561
Date: Thu, 21 Feb 2008 23:52:52 -0800

>From: "Julius Luukko" <address@hidden>
>> On Friday 22 February 2008, Peter LaDow wrote:
>>> In my specific case, I discovered the problem when trying to get 
>>> uC/OS-II
>>> to run.  I'm using the port on the Micrium website, and in OSTaskStkInit
>>> (in os_cpu_c.c) it does:
>>
>>> Are you using my port version? If you are, you might want to start with 
>>> a
>>> newer version available in my page
>>>
>>> http://www.ee.lut.fi/staff/Julius.Luukko/ucos-ii/index.shtml
>> http://www.ee.lut.fi/staff/Julius.Luukko/ucos-ii/avr/index.shtml

Thanks for the links.  Though your site mentions the patch applies to 2.52 
and 2.70, I am using 2.86.  Know of any issues there?  A cursory inspection 
shows the os_cpu_c.c still assumes a 2-byte PC.  I'll compare the rest to 
see what else has changed.

One note though.  I modified os_cpu_a.asm to remove the dependence on TCNT0 
in OSTickISR.  I'm using a different timer, which auto-reloads, so there is 
no need for the output to TCNT0.  I commented this out in my version and 
relied upon a vector to jump to this handler.  In fact, I do:

.global OSTickISR

.global TIMER1_COMPA_vect
TIMER1_COMPA_vect:
  jmp OSTickISR

Of course with copious commenting.  This eliminates the coupling of the OS 
port to a specific platform.  Though it does make it more difficult to use 
with hardware that does not auto-reload a timer.  But that would likely 
require modification anyways.  I think my change makes the port more 
platform independent.

>> (even though the header on the page only mentions gcc 3.x, it also works 
>> with
>> 4.x)

Perfect.  :)  I am using 4.2.1.

>> I haven't been very active with uC/OS-II or AVR lately. However, if you 
>> are
>> able to get it run with newer parts (with more than 128kB memory), I 
>> would be
>> happy to integrate your changes into my port. The current port should 
>> work
>> with all AVRs (with 128kB or less) and with your changes, it should be a
>> simple matter of preprocessor conditionals to support both older and 
>> newer
>> chips. If you are willing to take over the "support" of the port, you 
>> could
>> contact me offlist.

"Support"?  :)

I have to admit, I'm using the AT90USB1287 for a project, not the 
ATmega2561.  Though I am experimenting with the 2561 (having used it on my 
last project) for the uC/OS-II stuff I am doing.  But given the USB1287's 
apparent use of a 3-byte PC, a port to the USB1287 could perhaps provide a 
fix to a part with more than 128K.

The question is how to determine, compile time, if a part as a 3-byte PC or 
a 2-byte PC.  It seems that the size of the flash doesn't matter, if my 
observations of the USB1287 prove true.

Pete 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]