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

[Julius Luukko]

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