[Top][All Lists]
[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