I hate switching of interrupts, I always say if the main code needs
swithing off interrupts - it's probably poorly written main code ;).
I removed big array calculation from ISR and problem with other ram
data corruption vanish.
ml
2014-02-13 21:06 GMT+01:00, Don Wooton <d...@snuggle.org>:
> Or, turn off interrupts when doing big math when not in ISR.
>
> #define disableIntr() do GIE = 0; while (GIE)
> #define enableIntr() GIE = 1
>
> - Don
>
> On Feb 13, Maarten Brock propounded certain bytes, to wit:
>> Subject: Re: [Sdcc-user] pic14: size of array index
>>
>> > 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?
>>
>> Yes, I think so. I think the only option you have is not access this
>> large
>> array in an ISR. Maybe, if you can turn indexing into pointer access and
>> can use addition to this pointer instead of addition to the index, you
>> can
>> circumvent the problem.
>>
>> Maarten
>>
>> >
>> >
>> >
>> > 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\xe1l 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
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>-- End of excerpt from Maarten Brock'
>
> ------------------------------------------------------------------------------
> 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
