On Friday 22 February 2008, Peter LaDow wrote: > >From: "Julius Luukko" <[EMAIL PROTECTED]> > >>> 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
