Hi,
nonreentrant support function is the likely cause, but AFAIK
--stack-auto is not supported on pic14 port so recompiling support
functions with --int-long-reent is meaningless , right?
2014-02-13 11:15 GMT+01:00, Maarten Brock <sourceforge.br...@dse.nl>:
> Hi,
>
> What you experience here is probably that multiplication is done in a
> non-reentrant support function. While it is executing a multiplication in
> the mainline it gets interrupted and reuses the multiplication variables
> in the support function which effectively destroys the original
> multiplication.
>
> Maarten
>
>> Hello,
>> when testing it with pic16f648a I found other issue, maybe related.
>> When such big code array is accessed with int index inside an
>> interrupt routine, retrieving values from other arrays located in ram
>> (used with other functions and not ralated to interrupt routine) are
>> randomly corrupted. When I comment out line with code array
>> retrieving:
>> // x = my_data[index][0] ;
>> ram arrays return values are not corrupted.
>>
>> Even declaring static index like:
>> x = my_data[33][0] ;
>> won't prevent wrong values retrieved from ram arrays .
>>
>> First I thought is related to small stack size (default 16) but
>> increasing stack (e.g --stack-size 32 ) makes it worse, code behaves
>> odd.
>>
>> regards,
>> ML
>>
>> 2014-02-12 22:20 GMT+01:00, Raphael Neider <rnei...@web.de>:
>>> Hi,
>>>
>>> I think that your analysis of the index exceeding 8 bit is correct.
>>> Thanks
>>> to your analysis of a larger index type yielding correct values this bug
>>> should be easier to fix than I initially assumed: indexing with types
>>> longer than 8 bit seem to work, I "only" need to make index computations
>>> use a large enough type (internally).
>>>
>>> I'll try to look into this over the weekend.
>>>
>>> Thank you for the report and the analysis!
>>>
>>> Raphael
>>> On Feb 12, 2014 7:32 PM, "M L" <maricol...@gmail.com> wrote:
>>>
>>>> Hello,
>>>> AFAIK it possible put static (const) arrays like bitmaps in code
>>>> memory (values are retrived by retlw instruction internally with sdcc
>>>> helpers function), here goes definition of my_data array:
>>>>
>>>> static __code unsigned char my_data[95][7] >> {
>>>> {0x95,0x01,0x78,0x67,0x12,0x88,0x11}, {...}};
>>>>
>>>>
>>>> I inspected .lst file and whole table is coded correctly in code
>>>> memory, starting addres is 0x6f and last address is 0x307:
>>>>
>>>> 00006f 3495 retlw 0x95
>>>> 000070 3401 retlw 0x1
>>>> 000071 3478 retlw 0x78
>>>> 000072 3467 retlw 0x67
>>>> 000073 3412 retlw 0x12
>>>> 000074 3488 retlw 0x88
>>>> 000075 3411 retlw 0x11
>>>> ....
>>>>
>>>> Looks like unsigned char index has problem accesing 37th element of
>>>> such
>>>> array,
>>>> example:
>>>> unsigned char index;
>>>> index=36;
>>>> my_data[index][0] -> value OK
>>>> index= 37;
>>>> my_data[index][0] -> wrong value,
>>>>
>>>> but when I declare:
>>>> unsigned int index;
>>>>
>>>> index=36;
>>>> my_data[index][0] -> value OK
>>>> index= 37;
>>>> my_data[index][0] -> value OK,
>>>>
>>>> So wrong values retrieved with char type index may be related to wrong
>>>> offset calculation for call to retlw instruction inside sdcc, like
>>>> this:
>>>> 36*7 = 252
>>>> 37*7 = 259 -> value beyond 8bit char type, index will be wrapped to 3
>>>>
>>>>
>>>> regards,
>>>> mb
>>>>
>>>> 2014-02-12 18:33 GMT+01:00, Gál Zsolt <tralitove...@freemail.hu>:
>>>> > Hello MB,
>>>> >
>>>> > Could you write more detail about definition of array? As I know, all
>>>> > variables takes places in data memory not in code memory. You should
>>>> > give
>>>> > modification word for defining variables in code memory. So this is
>>>> > littlebit more complicated.
>>>> >
>>>> > The other point is the size of your array. If its type is char, its
>>>> > size
>>>> > will be 95x7 = 665 bytes ( or words if it is takes place in code
>>>> memory
>>>> ).
>>>> > I think array is bigger those size what a pic14 device can handle.
>>>> >
>>>> > Zsolt
>>>> >
>>>> >
>>>> > 2014-02-12 17:20 GMT+01:00 M L <maricol...@gmail.com>:
>>>> >
>>>> >> Hello,
>>>> >> I have a 2 dimensional array with static values: unsigned char
>>>> >> my_tab[95][7] ={ ..} and it's located in a code memory. When I
>>>> read
>>>> >> array with the following code:
>>>> >>
>>>> >> unigned char index, v;
>>>> >>
>>>> >> { index is computed ...}
>>>> >> v=my_tab[index][0];
>>>> >>
>>>> >>
>>>> >> my "v" has unexpected value when computed index is above 36. When I
>>>> >> change index to unisgned int, values readings are as expected. Is
>>>> >> there any know issues with array index variables in pic14 port?
>>>> >>
>>>> >> regards,
>>>> >> mb
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
