AFAIK stackauto option has no effect (is not supported) on some archs
like PIC14/16.
ml
2015-02-26 3:57 GMT+01:00, 陳韋任 :
> Hi All,
>
> I have a question about stackauto. When I enable #pragma stackauto
> on the entire project, the binary has chance to be different. Most of
> those difference a
2015-01-30 14:03 GMT+01:00, Kustaa Nyholm :
> First of all, I'm talking about existing code and hardware.
>
> The existing code (without the bootloader) already pretty much
> fills the PIC18F4550.
>
> I can't just willy-nilly move to a bigger device, there is
> existing hardware on the field.
> I d
Hi,
I don't really get it, why You trying (so hard) use a bootloader which
won't fit in boot block, so what?
Bootloader can be with any size, just move user code to location
after bootloader (to first free block of flash erase boundary).
If size of user code+bootloader won't fit into device - choo
ht is related to small stack size (default 16) but
>> >>> increasing stack (e.g --stack-size 32 ) makes it worse, code behaves
>> >>> odd.
>> >>>
>> >>> regards,
>> >>> ML
>> >>>
>> >>> 201
ly 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 rep
for the report and the analysis!
>
> Raphael
> On Feb 12, 2014 7:32 PM, "M L" wrote:
>
>> Hello,
>> AFAIK it possible put static (const) arrays like bitmaps in code
>> memory (values are retrived by retlw instruction internally with sdcc
>> helper
s
> 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
>
>
>
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 abo
I doubt that there there exist any pic24* compiler for unices, but you
can try run Microchip C30 compiler under wine, I use C18 with Linux
(using wine) w/o problems.
2013/5/27, Ori Idan :
> Not directly related to SDCC but I guess members of this list may know the
> answer.
>
> I have to program a
There are some GPLed USB frameworks laying around, my faworite is
http://openprog.altervista.org/USB_firm_eng.html.
It works fine, but using it for create a bootloader with sdcc is a
bit pointless becouse
SDCC generate a bigger final code than C18.
This is a simple test compiling usb firmware from
Make sure the cpu clock (ext. osc) is working, test code with the
internal osc. first.
2013/2/28, Butuza Tamas :
> Dear sdcc users and developers,
>
> At the past I used sdcc for 14 bit pic devices with success.Now I'd like to
> use sdcc for a 16 bit pic microcontroller, but I have a problem just
Does updated manual says now anything about NOT SUPPORTED option
--stack-auto on pic16 port? I wasted many days for searching why libs
compiled with --stack-auto won't work correctly. There is only one or
two posts on list with such warning, manual in pic16 chapter says
nothing about this problem.
Hello,
I found that using --stack-auto when (re)compiling sdcclib for needed
reetrancy (as manual recommends) can break int (and long)
multiplication in "user" code when interrupts are on.
And not only int/long, libmath too.
Looks like an "empty" ISR (which has only a prologue and epilogue) has
imp
nt, long or float calculations are
randomly wrong.
I know, these calcuations are not atomic, but why they are wrong even when all
int/long sdcclib functions (mulint etc) are compiled as reentrant
(and even not in use in ISR)?
When I disable interrupt calculations problem just disappear.
regards,
Hello,
I discover some strange behaviour of sqrtf() function when usart
interrupts are enabled.
My sdcclibs are compiled with --stack-auto option, libm too.
My program is simple and just do a sqrt calculations in endless loop
(my code compiled is with --stack-auto):
float val;
unsigned int x;
whi
Hello,
I discover some strange behaviour of sqrtf() function when usart
interrupts are enabled.
My sdcclibs are compiled with --stack-auto option, libm too.
My program is simple, just do sqrt calculations in endless loop:
float val;
while(1){
}
---
Hi,
There was a couple discussions before about generated code size in
comparison with mcc18. But I wonder is there any chance (in the near
future) that
sdcc pic16 port will generate a smaller code? Now the same code
compiled with mcc18 & sdcc is almost half size when compiled with
mcc18 (even wi
fixed my problems. For me this is an unusual sdcc behavior, I often
use pointers to char arrays, like:
char buf[32], *p;
p=&buf
and "p" points correctly to buf, which is located in ram. So why it
won't work with usbram ?
regards,
2011/11/9 Kustaa Nyholm :
> On 11/9/11
/11/9 Kustaa Nyholm :
> On 11/9/11 11:54, "M L" wrote:
>>outPtr = &deviceDescriptor;
>>so I changed it to
>>outPtr = (byte *)&deviceDescriptor;
>
> >From the top of my head and not looking at the code,
> pointers in SDCC/PIC come in three type
Hi,
I searched sdcc archives about some usable & wroking USB library and I
found some posts about gpled USB stack writtten by Alexander Enzmann
( file usb.zip found on nutsvols.com). This library was created using
sdcc version 2.5 (according to some comments in the source files) and
it contains pr
20 matches
Mail list logo
