[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: |
Julius Luukko |
Subject: |
Re: [avr-gcc-list] Function Pointers on AT90USB1287 and ATmega2561 |
Date: |
Fri, 22 Feb 2008 11:40:54 +0200 |
User-agent: |
KMail/1.9.6 (enterprise 0.20071204.744707) |
On Friday 22 February 2008, Peter LaDow wrote:
> >From: "Julius Luukko" <address@hidden>
> >>> 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.
Yes you are right, I have not updated the port to take into account a 3-byte
PC. I meant that there are other serious bugs in the version which is
available from Micrium (e.g. usage of r0 and r1 when mixing C and assembly).
Version 2.70 is the last version I have obtained from Micrium. I got it when
I first submitted the port to Micrium, at that point only for 2.52 (the
version with the book). Updates are not freely available and I don't have a
commercial license for uC/OS-II (I work in a university). So I don't know if
there are changes that affect ports.
>
> 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
This is of course wise. I have only included the tick ISR with timer0 since it
is available in every AVR.
>
> 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.
>
The choice between timers could be made with preprocessor macros. You could
define these in os_cfg.h so that you can choose the timer in every project
without making changes to the actual OS source.
> >> (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 mean that if you publish something, someone is bound to ask you something
about it. I have received about 90 uC/OS-II related emails since March 2003.
>
> 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.
>
I don't know if there is a universal method to determine it at compile time.
You'll just have to test chip by chip:
#if defined(__AVR_ATmega256__) || defined(some_other_with_3_byte_PC)
#define THREEBYTEPC 1
#else
#define THREEBYTEPC 0
#endif
I am not sure if __AVR_ATmega256__ is the right constant name.
If you have more uC/OS-II related questions, maybe the discussion should be
moved offlist or to avr-chat.
--
Julius