Re: [Fx2lib-devel] Some bugs

[Dennis M. <de...@ub...>]

On Jul 24, 2009, at 8:53 AM, Maarten Brock wrote:

> 1. The generated documentation for fx2regs.h has put many descriptions
> next to the wrong (next) registers.

Good catch.  I pushed an update for this.  Eventually, I'd like to  
expand the documentation to include much more detailed information for  
each register but It hasn't been much of a priority since you can't do  
a lot without the TRM anyway and it's all in there already.

>
> 2. usbjt.a51 has several areas defined without specifying the memory  
> type.
> I advise to change them to (CODE, ABS, CON) so they will not end up in
> xdata by accident and the linker can check for overlaps.

Which areas?  _INT2AV,_INT4AV are ( ABS, OVR )

For INT2JT, I specifically didn't put the .org in because it has to be  
aligned on a page boundary and I didn't have a way to get the compiler  
to put that in the correct location without telling the linker  
specifically about it.  By the way, INT2JT is declared as:
.area INT2J2 ( CODE )

I specify the INT2JT location in the firmware Makefile like this:

sdcc -Wl"-b INT2JT 0x 0x3000"

Is there a better way to do it?

>
> 3. The value in loop_count in delay.c seems wrong. And if you don't  
> like
> volatile in delay.c then I suggest the use of NOP's and also use  
> only 8
> bit counters. This way the chosen model has little influence. E.g.

I had planned on revisiting this function actually.  I like your  
suggestions.

>
> void delay(WORD millis)
> {
>  register BYTE count_inner, count_outer;
>
>  do {
>    count_outer = 3;
>    do {
>      count_inner = 250;
>      do {
> #if (CPUFREQ == CLK_12M)
>        NOP();  // 1 cycle
> #elif (CPUFREQ == CLK_24M)
>        NOP();  // 5 cycles
>        NOP();
>        NOP();
>        NOP();
>        NOP();
> #else
>        NOP();  // 13 cycles
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
>        NOP();
> #endif
>      } while (--count_inner);  //should result in DJNZ Rn : 3 cycles
>    } while (--count_outer);  //should result in DJNZ Rn
>  } while (--millis);
> }
>
> Or if you want even more precise timing either fully write the  
> function in
> asm or use a timer.

I've struggled a little with the use of timers.  Not how to use them,  
but whether or not to use them.  I like the idea of a better  
resolution delay with timers but I don't like the idea of limiting the  
usage of timers for other purposes.  For instance, right now, the  
serial code uses timer 2.  If you want to use timer 2, you can't use  
the serial code.  Suppose I use timer 1 for a delay.  Can you now not  
use a timer for something else?

Perhaps you have some suggestions on this subject.  I know one  
improvement would be to use the fx2 high speed baud generation timer  
instead of timer 2.  I don't think there are many other usages for  
that timer than for serial IO.

>
> 4. The functions in eputils.c could be sped up if you use the  
> autoptr's.
> And even more if you unroll the inner loop for the special case of 64
> bytes.

In general, the whole library needs a passthrough for performance.   
I'm kind of at the functionality stage, making sure things work.  I'd  
also like to do some optimization for size at some point.

Thanks for your suggestions.
Dennis