On Tue, 24 Nov 2009, Raphael Neider wrote:
>> Specifically during compiler generated calls to _mullong although I
>> haven't tried any others yet.
>
> A quick look at the generated .asm shows that sdcc replaces the local
> union-type variables x, y, t, t1, and t2 with global variables -- which
> a
On Tue, 24 Nov 2009, Michel Bouissou wrote:
Le mardi 24 novembre 2009, Gordon Henderson a écrit :
Any thoughts, anyone?
As a workaround, you might disable (mask) interrupts in your main() code just
before the instruction that calls _mullong, and re-enable them immediately
after, so you're su
On Tue, 24 Nov 2009, Frieder Ferlemann wrote:
> Hi Gordon,
>
> Gordon Henderson schrieb:
>> void mathTest (uint16_t x)
>> {
>>uint32_t y ;
>>uint32_t i = 0 ;
>>
>>for (;;)
>>{
>>
>> y = (uint32_t)x * 9668 + 500 ;
>> if (y != 4225416L)
>> {
>>serialPuts ("Curr
Hi Gordon,
Gordon Henderson schrieb:
> void mathTest (uint16_t x)
> {
>uint32_t y ;
>uint32_t i = 0 ;
>
>for (;;)
>{
>
> y = (uint32_t)x * 9668 + 500 ;
> if (y != 4225416L)
> {
>serialPuts ("Curruption @ ") ;
> ...
> }
> ++i ;
>
>}
>
>
> Specifically during compiler generated calls to _mullong although I
> haven't tried any others yet.
A quick look at the generated .asm shows that sdcc replaces the local
union-type variables x, y, t, t1, and t2 with global variables -- which
are of course corrupted during the second (nested) exe
Le mardi 24 novembre 2009, Gordon Henderson a écrit :
> Any thoughts, anyone?
As a workaround, you might disable (mask) interrupts in your main() code just
before the instruction that calls _mullong, and re-enable them immediately
after, so you're sure that an interrupt will never call _mullong
On Thu, 12 Nov 2009, Gordon Henderson wrote:
> I'll give it a go and let you know :)
So a while back, I asked about interrupts, etc. and now I'm letting you
know what happened...
I see data corruption )-:
Specifically during compiler generated calls to _mullong although I
haven't tried any ot
On Thu, 12 Nov 2009, Raphael Neider wrote:
> Hi,
>
>>> it would make life easier if I can use multiple interrupts - however
>>> inside an interrupt routine I need to be able to call other functions
>>> and do some floating point math. I also need the main interrupt to be
>>> reentrant, so the long
Hi,
>> it would make life easier if I can use multiple interrupts - however
>> inside an interrupt routine I need to be able to call other functions
>> and do some floating point math. I also need the main interrupt to be
>> reentrant, so the longish bit of code that is doing the FP calculations
Hi,
Le jeudi 12 novembre 2009, Gordon Henderson a écrit :
> it would make life easier if I can use multiple interrupts - however
> inside an interrupt routine I need to be able to call other functions and
> do some floating point math. I also need the main interrupt to be
> reentrant, so the long
... or what can't I do?
Essentially I have a little real-time system which currently runs on an
AVR chip (with GCC) which I'm porting to PIC18 and SDCC. So-far so good
and SDCC is managing about 8000 lines of C very well.
So before I end up shooting myself in the foot, I thought I'd ask a
qui
11 matches
Mail list logo
