Jesse,
It might also help to spread your functions over
multiple source files. Every source file generates one
object file and all allocations in a segment (e.g. DSEG
which gets the slocs) are placed by the linker in one
chunk. The only way to subdivide the chunk into smaller
ones is to split
Forwarded message follows:
Marteen,
I just ran across the multiple file info in the SDCC
user's manual, which explained the
linking of multiple files. I now seem to be able to use
more than 256 bytes of XDATA in
my program--I set up for 1024 bytes of XRAM.
I'll test the XRAM more rigorously
Jesse,
> unsigned long var32;
> unsigned short var16;
>
> If I do this:
>
> var32= var16 * 60;
>
> I get a 16-bit multiply, not a 32-bit. This caused an overflow and a
> bug. doing this:
>
> var32= *(unsigned long)var16) * 60;
>
> solves that.
>
> But, I thought that there was automatic t
I guess it isn't there because this only holds true for
mcs51 and not necessarily for the other targets. And
besides, these functions are helper functions for SDCC
to perform floating point arithmetic. They were not
created to be used directly.
> Hi Maarten
> >
> > IIRC the __fs floating poin
Hello Dennis,
You are right. The linker only includes objects from a
library if it is referenced. The solution is to either
put something in the object that you can explicitly
reference or to use the .rel file directly.
HTH,
Maarten
> I've created a little custom assembly for an interrupt au
Dennis,
Initially you had --xram-loc=0x4000, but the FX2 has
only 16kB RAM so there is nothing at 0x4000 unless you
have external RAM connected. Without any --xram-loc SDCC
puts xdata at 0x but unless you have external ROM
and EA=1 this memory is shared with code memory. So any
write to x
I suggest you try Code Architect free from
www.esacademy.org
>
>Has anyone written any general-purpose routines for SDCC to deal
> with the on-chip I2C controller in the 87C751 that they'd be willing
> to share?
>
> Thanks,
> -Dave
>
> --
> Dave McGuire
> Port
Colin,
Please file this as a bug report in our SourceForge
tracker system. On a mailing list it will simply be
forgotten and on this USER mailing list I doubt there
are any users who can help you with this.
Greets,
Maarten
> I have encountered an internal compiler error when compiling
> a pa
Hello Hansi,
I'm not sure what to do with the library. SDCC currently has almost
no library code for 8051 derivatives and I'm not sure if we want to
start to. Most library functionality can be found on the SDCC OKR,
on www.8052.com or on the website of the manufacturer. But I'm just
one vote s
Happy New Year Mark,
The difference is that medium model puts the variables
in pdata and large in xdata. Pdata (max. 256 bytes) is
smaller than xdata (max. 64kB) but can be accessed with
two pointers (r0,r1) what might result in smaller code
than xdata which only can use dptr.
Maarten
> What
anual. I
still think it's a good idea though and maybe one day in
the future...
Sorry for the bad news,
Maarten
> On Fri, 02 Jan 2009 14:54:26 +0100
> Frieder Ferlemann wrote:
>
> > Hi Mark,
> >
> > Maarten Brock schrieb:
> > > The difference is that m
If you don't need a full printf, you can also use puts
which also uses putchar.
> Thanks for the reply. On your reccomendation, I looked at some print
> examples, but didn't need anything as powerful as printf.
> I just created a print_LCD (unsigned char* message). function. Here's the
> worki
Raphael, Kustaa,
> Assignments to the pointer should not need special attention, except
> for casts:
> ptr = (struct something *)&blob;
> might need to be rewritten to
> ptr = (__data struct something *)&blob;
With my change last week (and fix just a minute ago)
this should not be necess
Hansi,
> Am Mittwoch, den 31.12.2008, 17:43 +0100 schrieb Maarten Brock:
> > The headers could be included and I'm glad you already used
> > compiler.h. But I do not like anything I see in uctypes.h. NULL,
> > bool and the int's are all already defined in stdlib
But it looks like Martin uses it on an unsigned char and
not on a bit variable. I doubt it will create a problem
here. Probably not even suboptimal code.
Maarten
> In SDCC, use ! instead of ~ to flip a bit.
>
>
> -Original Message-
> From: Martin Leopold
> To: sdcc-user@lists.sourcef
Or in C
void (*fp)(void) = 0xfff0;
fp();
> Try:
>
> _asm lcall 0xfff0 _endasm;
>
>
> At 10:59 AM 18/01/2009, Gudjon I. Gudjonsson wrote:
>
> >Hi
> > Sorry once again if the question is silly but I am trying to call the
> >PGM_MTP at address 0xFFF0
> >function in the in application bootlo
Ok, make it a const function pointer then. And to get
rid of the warning add a cast too:
void (* const fp)(void) = (void (*)(void))0xFFF0;
fp();
Now it's as small as the inline asm.
Maarten
> The resulting code using the C version generates this assembly instructions:
>
> mov _fp,#0xF0
>
Hi,
> > Do we need to protect the prologue/epilogue?
>
> Not sure, probably not, though __critical attached to the function
> probably would.
For other targets the prologue and epilogue aren't
protected either. The idea was to keep interrupts off as
short as possible. But there is an RFE for i
Andy,
SDCC generates a so-called extended intel-hex file. This
also contains records to indicate the start of a new
segment/bank. If your bootloader or whatever you use to
program the chip(s) does not understand extended hex-
files you can use srecord to split the file into several
hex-files f
g the library for the
regression tests only.
I still would like to see more responses.
Maarten
> Borut Razem schrieb:
> > I and Maarten Brock had a discussion and agreed to enable the floating
> > point support in printf_large() function included in libsdcc.lib
> > librar
> Thanks in advance,
> Andy
>
>
>
>
> >
> > Message: 4
> > Date: Fri, 23 Jan 2009 20:28:49 +0100
> > From: "Maarten Brock"
> > Subject: Re: [Sdcc-user] Help with code-banking
> > To: sdcc-user@lists.sourceforge.net
> > Message-
Hi Andy,
Please send me the files to reproduce this error. I'll
see if I can do something about it.
Maarten
> Maarten,
>
> Many thanks for the excellent response so far.
> Please bear with the following lengthy explanation
>
>
Overrun = overrun;
> hexRecord(addr, rtvalIndex);
> return;
> }
>
> I've tried to compress the app even further, to get something small
> enough to submit as a how-to-reproduce sample. However the problem goes
> away if I get it any smaller
Hi Alexandre,
Please look in the manual under "Library Routines". It explains why
floating point support is disabled in printf by default and how to turn it
on.
Greets,
Maarten
> Hello everyone.
>
> I had a problem working with float and integer numbers in SDCC using the
> sprintf function.
>
>
Peter,
That is currently impossible because how would you
otherwise create a generic pointer? There is no
'generic' keyword.
Maarten
> Hi,
>
> How to make a default pointer type xdata pointer and not generic as it is
> currently.
>
>
> Cheers,
> Peter Kuhar
>
>
> http://www.pkuhar.com/
>
ding an option to make unqulified
> pointers xdata.
>
> Cheers,
> Peter
>
> http://www.pkuhar.com/
> http://www.modula.si
> skype: pkuhar
>
>
> On Wed, Feb 11, 2009 at 9:39 AM, Maarten Brock
> wrote:
>
> > Peter,
> >
> > That is currently
Hello,
You're compiling for mcs51 (default) and this has a
harvard architecture. So the compiler needs to know what
memory type the pointer should point to
(code/data/xdata?). C was created with a VonNeumann
architecture in mind.
Maarten
> Hi,
>
> Code in main.c :
>
> int main()
> {
> unsi
Andy,
You're right. The combination --model-large and --stack-auto is not
pre-built for SDCC.
And when using --model-large you'll find a lot of intermediate
temperary results (sloc) are located in data memory. More info is in
the .map file, but library locals do not show up.
Maarten
> I've t
Ronny,
If the registers are not used in the ISR they do not
need to be saved and restored. The compiler does check
that.
And without a clue what the source and generated asm
looks like we cannot help you more.
Maarten
> I have a small routine that uses an interrupt to reset a timer. It appe
Andy,
Good catch. I think you are right and I programmed the bug.
Borut,
Shall we fix this before the release?
Maarten
> To those in the know,
>
> The code for printf (printf_large.c) is as follows. My question is,
> should the space conditions be '>=' rather than just '>' ? (I did some
> ra
To install SDCC you probably used a linux package which contains the FREE
parts only. The NONFREE parts as they were labeled contain the mcs51
target. I guess they forgot to change the default target (mcs51) even
though they disabled it.
Maarten
> It would be useful to know the actual command tha
Sorry, this is currently not possible.
> Hi,
>
> Is is possible to enable dual dptr support without selecting -mds390?
>
> The chip is cc2430 and has:
> DPH0 (0x83) â Data Pointer 0 High Byte
> DPL0 (0x82) â Data Pointer 0 Low Byte
> DPH1 (0x85) â Data Pointer 1 High Byte
> DPL1 (0x84) â
Peter,
Please include SDCC version and target for which you
compile. For mcs51 this should work I think.
Maarten
> Hi,
>
> Is it possible to make linker skip a part of code memory?
>
> I'd like to use a segment of flash in the middle the whole flash for data.
>
> Ex. flash segments are 2k.
Hello,
Currently I cannot verify but have you used the latest version of SDCC? If
so please file it as a bug in the tracker system.
I also recommend to try:
xdata PBYTE xptr;
Greets,
Maarten
> Hi,
>
> Code in main.c :
>
> typedef unsigned char * PBYTE;
>
> int main()
> {
> PBYTE xdata xptr;
>
Ricardo,
Are you by any chance using SDCC on debian linux? If so,
be warned that it comes with pic support only unless you
install the *-nf (non-free) package.
Otherwise, it might be useful to tell us what "error"
you get.
Maarten
> Hi:
>
> Am using an AT89C2051 with a very simple program i
Hi,
There is no manual for it, but there is some info on the SDCC wiki
under "SDCC internals and porting".
And if after that you have questions, just ask.
Greets,
Maarten
> Hi All,
>
> Sorry for my bad english.
> How can I add to sdcc support for a 8-bit micro (Harvard architecture)?
> An RT
Hi,
It looks like you think you've found a bug. Posting it in the user mailing
list might get you a quick answer. But if not, it is bound to be
forgotten. Bugs should be reported in the bug tracker system. Please
repost.
Maarten
> Hi all,
>
> We use SDCC with our project and we encountered some
Hello Bart,
I agree with Bodo. Xdata is probably not set up correctly. Does your mcu
have internal xdata? And do you need to enable it? Otherwise I expect your
real external ram not to be working.
You should not need to initialize malloc, it's probably ok.
Greets,
Maarten
> Hi Bart,
>
> Your an
Lv Zheng,
If you think you found a bug please file it in SDCC's bug tracker at
sourceforge. On the mailinglist it is bound to be forgotten.
Greets,
Maarten Brock
> Hi, all
>
> We post this message for someone who might be put in a great
> quandary like us.
>
> Please l
Hi,
Are you using absolutely located bits? And are they declared in multiple
source files (possibly through a .h file)?
And why don't you like what --pack-iram gives?
Maarten
> Hello.
>
> I'm trying to port an application to SDCC 2.9.0 from SDCC 2.3.8.
> Compiling using the old Makefile that i
to do with it, but it's an
> obvious thing I noted that is different.
>
> Greetings,
>
> Christian "BC" Svensson
> Codelead Systems - http://www.codelead.se
>
>
> On Sat, Jul 18, 2009 at 10:57 PM, Maarten Brock
> wrote:
>
>> Hi,
>>
>
re indeed declared in header files.
>
> Christian "BC" Svensson
> Codelead Systems - http://www.codelead.se
>
>
> On Sun, Jul 19, 2009 at 8:25 AM, Maarten Brock
> wrote:
>
>> Search for the keyword "at" that is used to absolutely locate variables.
&g
Bart,
Did you ever mention which mcu you're using? You say it has 2kB of
internal ram. But have you checked if you need to enable it? SDCC will not
do that for you! The best place to do it is in _sdcc_external_startup().
Maarten
> Hello Bodo & Maarten
>
> My apologies for the very late reply, i
Instead of FSR you should enter its address 0xF8.
> I'm trying to use the macros in compiler.h to port some headers from Keil.
> So I have stuff like...
>
> SFR(FSR, 0xF8);
> SBIT(MCDIS, FSR, 7);
>
> And sdcc is telling me "Initializer element is not constant". What am I
> doing wrong?
Miles,
You probably have sfr definitions in Keil notation in
there.
Maarten
> Ralph,
>
> Thanks very much. You were right, the .rel files were just preprocessed
> source code (which I noticed before and was confused about). I'm using sdcc
> to compile now, and after some tweaking of flags an
Hello Peter,
This method only works for z80 I think. For mcs51 the
best option is to absolutely locate the CONST area while
linking. Remember that the lowest address is used by the
reset and interrupt vectors, so stay above them.
Example:
sdcc main.rel others.rel -Wl-bCONST=0x0400
HTH,
Maart
Hi Kurt,
It looks like you found a bug. The reason it only
complains about the flag in main is because it's
optimized away in test. Somehow SDCC forgets to allocate
the space for the local bit variable. If you make it
static or volatile it does get an address. And as you
found out also when i
Hi Tebogo,
SDCC cannot pass structs as parameters. You probably got
a warning too about the struct being converted to a
pointer. I changed that recently because that really did
not work, so SDCC 2.9.3 now throws an error. Passing a
pointer to the struct should work though.
Greets,
Maarten
>
Hi Prateek,
I don't see anything wrong with your code or the
generated assembly. Those pops belong to the prior
pushes to save your values.
Maarten
> Hello,
>
>
>
> We are using SDCC for compiling a code for 8051 core from Oregano Systems
> target.
> We are facing an issue with serial por
C99 support is very incomplete and this is one of the
unsupported parts.
> I tried to do something like
>
> struct {int a, b;} mystruct = { .a=1, .b=1 };
>
> and it didn't work, even though I used the --std-c99 option. Did I do
> something wrong or is this unsupported?
>
> The error message w
In the meantime, Graham, I'm already trying to fix this
bug.
Maarten
>
> LOL
> Thanks very much for that, Im glad it was that easy, my stupid typo has cost
> me hours of wasted time :-)
> Keep up the good work.
>
> Graham
>
> -Original Message-
> From: Jesus Calvino-Fraga [mailto:jes.
Hi Jesus,
So I noticed. I should have addressed you too in my
reply I guess.
To both of you (and the rest),
I think I have it fixed already, but still have to run
regression tests. I'll let it do that while I get my
sleep :) Hopefully tomorrow evening after work I can
commit.
Greets,
Maarte
Kurt,
If you had read 4.1.1 too, you would have realized that
it was enough to declare _XPAGE as an alias for MPAGE to
make xdata initialization work. And it probably saves a
lot of code memory.
Maarten
> Brandon;
>
> In this case I would try initializing your structure within your main
> s
Anthony,
There are still header files missing. At least these,
but maybe more:
8051def.h
log.h
timetable-aggregate.h
Maarten
> I located the source of the problem in timetable.h.
>
> * int i;*
>int t1, t2;
>
>t1 = t2 = t->size;
>for(i = *t->ptr - 1; i >= 0; --i) {
> *if(t->t
r does invoke a paged memory access it wouldn't
> corrupt P2 which is mapped to IOC (0xA0) of the CY7C68013. I had tested
> for paging by decompiling the hex code and searching for P2 in the output
> listing prior to redefining _XPAGE.
>
>
> SDCCMan.pdf V2.9.2 Section 4.1.1 for ref
Yes, you can specify it on the command line using the -o
option. The .ihx is already an intel hex-file, though
not necessarily in ascending order.
> Is there some way to output a .hex file instead if the .ihx that SDCC
> creates by default?
> Thanks,
> Ron
>
Anthony,
Are you linking the file that contains main() as the
first object? It looks like the linker has put
sdcc_call_dptr() at the address of the reset vector
which makes it jump to whatever A+DPTR is after reset.
Maarten
> another strange observation. If I move the actual declaration of t
Gudjon,
> Here is one bug in the Debian bug reporting system that I don't know if it
> has
> been reported to upstream but I know that it still exists in the SVN version
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422599
AFAIK we were unaware of it and unless it is added to
our bugtrack
John,
Your mcu has its watchdog enabled by default and it
bites before you can kick it in main(). Create your own
_sdcc_external_startup() function and setup the watchdog
there by either kicking it, setting a longer timeout or
disabling it.
Happy programming,
Maarten
> My problem seems to be
make an advertisement on the
> mailing list.
>
> Best regards
> Gudjon
>
> On Monday 09 November 2009 22:22:11 Maarten Brock wrote:
> > Gudjon,
> >
> > I think I understood you allright. I fully understand
> > that you do not want to create a package of an
> &
Borut,
I did not advise to use the snapshot for the package, merely to use it to
verify fast and simple if the bug indeed was fixed. Then use the fix to
backpatch the original 2.9.0. I'm glad Gudjon already took on this
approach.
Maarten
> Borut wrote:
>>I'm not very happy with the decision to t
Bruno,
Have you considered using one of the USB-UART converters from FTDI, SiLabs
or Prolific? Much easier than augmenting your application with a complete
USB stack just for debug output. And what if your MCU doesn't have USB,
only UART?
Maarten
> Hi guys, I'm playing with SDCC for a while, alw
Marcos,
SDCC does not have any libraries for any hardware that
can be attached to any microcontroller. I don't think we
want to take this up either. Such an implementation is
usually highly mcu dependant and totally compiler
independant.
Good places to publish this kind of stuff could be the
Roel,
> I've been thinking that a site with diferent libraries for SDCC would be a
> nice idea. Need to have a bit of quality control, and the diferent
> architectures probably need diferent hardware files. But, a collection of
> some (hardware)-libs would be nice.
Others have thought the same t
Raphael,
I think you are right and that this is a bug.
Maarten
> Hi,
>
> >void delay (uint32_t delay)
> >{
> > setCounter (delay) ;
> > while (!counterTriggered ())
> >;
> >}
> >
> > Gives the error:
> >
> >dross.c:435: error 98: conflict with previous definiti
fixing
as many bugs when I find the time.
Thanks for your patience (I hope)
Maarten Brock
> Dear SDCC developers and users,
>
> because of I have stuck on the broken SDCC inline support years
> ago and we still maintain compatibility for MCS51 in our project
> we cannot keep hac
Hi,
Just put it in xdata. But also check in the datasheet if this XRAM
is enabled by default, otherwise you need to enable it in
_sdcc_external_startup().
Maarten
> Good morning, everyone
>
> I need to use the internal XRAM AT89C51ED2.
> Can anyone give me guidance on how to set a variable in
Hi Anthony,
It seems bankswitching is broken. And you also found why
already: the startup routine should be at 0x and
__sdcc_banked_call at some higher address. Does it help
if you put the .rel which contains main() as the first
object to link?
Programmers that cannot handle unsorted hex-
Hi Kurt,
I think you misunderstand the keywords data and idata
and did not fully graps the (im)possibilities of the
8051 internal ram. Data memory is only 128 bytes big and
it shares space with the registers and bit variables. In
the upper 128 bytes you can only have idata variables
and stack
Kurt,
Remove the --iram-size 128 so you can still use the high
internal ram for idata variables and stack. Otherwise
everything must be crammed into the first 128 bytes.
Maarten
> Maarten;
>
> Thanks. I had remembered reading that the stack used idata and could be
> mapped into the upper
Hi Anthony,
Currently all C-library code is compiled without any bankswitching
directive which places the code in CSEG. The linker will put CSEG in the
common bank (0x-0x7FFF) so there is no banking problem.
Instead of preprocessing your source code I think what you want is a
pragma or comman
someone else in testing a new feature?
>
>
> anthony*
>
>
> Maarten Brock wrote:
> > Hi Anthony,
> >
> > Currently all C-library code is compiled without any bankswitching
> > directive which places the code in CSEG. The linker will put CSEG in the
> > c
Anthony,
I see no problem with payload being sent through
DPL/DPH/B. It is properly assigned when sending in
cc2430_rf_send() and properly read and put on stack when
receiving in cc2430_rf_send_b(). Are you messing up DPTR
or B or the stack in your adapted __sdcc_banked_call
except the one pu
send_b
> doesn't find payload_len in the correct position.
No, rf_send_b wants payload at SP+1 (plus 1) and it puts it there
itself at the start of the function when receiving DPL/DPH/B. It
treats payload as a local variable.
> Maarten Brock wrote:
> > Anthony,
> >
> &g
end_b wants payload at SP+1 (plus 1) and it puts it there
> > itself at the start of the function when receiving DPL/DPH/B. It
> > treats payload as a local variable.
> >
> >
> >>Maarten Brock wrote:
> >>
> >>> Anthony,
> >>>
> &
029C F8 1136 mov r0,a
> 029D E6 1137 mov a,@r0
> 029E C0 E0 1138 pushacc
> 02A0 08 1139 inc r0
> 02A1 E6 1140 mov a,@r0
> 02A2 C0 E
Anthony,
> Maarten Brock wrote:
> >> It should be a stack overflow. The stack supports up to 256 bytes. (?)
> >> The SP is at 0x78, so less than half full.
> >>
> >
> > Yes, the stackpointer can go upto address 255. With these values I
> > d
Anthony,
I think I've found the bug.
In mcs51/main.c(795) banked_overhead should be set to 1.
And in SDCCast.c(6514) the following should be added:
if (IFFUNC_ISBANKEDCALL (name->type))
stackPtr -= port->stack.direction * port->stack.banked_overhead;
When I fully have --model-huge working
t; #if 0
>if (FUNC_ISINLINE (name->type) && !IS_EXTERN (fetype))
> goto skipall;
> #else
>/* Temporary hack: always generate code for static inline functions. */
>/* Ideally static inline functions should only be generated if needed. */
>if (FUNC_ISINLINE (name-&
Hello everyone,
A new memory model was introduced today for the mcs51 called huge (--
model-huge). It uses bankswitching to call all functions. It passes our
regression test suite, but without any real bankswitching in the
simulator, so it might still be buggy. It also creates quite some
overhe
Hi,
I wanted to reply:
__sbit __at (&PSW + 7) CY;
But that also doesn't seem to work. So the only option is to do the math
yourself.
Maarten
> hi,
> what about:
>
> __sbit__ at (0xD7) CY;
>
> ?
>
> On Sun, Jan 31, 2010 at 10:16 AM, Grissiom wrote:
>
>> Hello all,
>>
>> I want to define a sbit
Hi,
I assume since you ask on the SDCC user list that you don't ask about
writing and compiling the program, but about downloading it to the mcu.
For the latter you can try ec2drv.
http://sourceforge.net/projects/ec2drv/
Hope this helps,
Maarten
> I have to write a new project using Silicon Lab
Jan and Borut,
I just tried on my old Win98 laptop and cannot complete
the installer either. I get the same error as Jan.
And if I instead use the zip-file which can be read ok
by 7-zip, I get the same warnings about -y, -Y, PSEG and
l_IRAM.
I don't have Visual C installed on it or any other
Brendan,
SDCC does not accept a linker script, but it creates one (extension .lnk)
when calling the linker. You can adapt it (or write it yourself) and then
call the linker manually instead of through SDCC. Use sdcc -V --verbose to
see how the linker is called.
To relocate only the code and not t
Brandon,
You could also rename your main() to mymain() and
generate the necessary startup code yourself in
assembly.
(Sorry for misspelling your name earlier.)
Maarten
>
> On Feb 11, 2010, at 20:04 , Peter Van Epp wrote:
>
> > On Thu, Feb 11, 2010 at 12:27:04PM +0100, Brandon Fosdick wrote:
Hi,
You've found a bug that I think I fixed already some time ago. Please try
again with the latest snapshot.
Maarten
> Hello,
>
> I'm using an 8051-derivative with the 2.9.0 version of SDCC. I am
> trying to pass parameters in xdata like this:
>
> void WriteLEDByte( BYTE iOutput, BYTE
Hi Brandon,
You sure know how to make life difficult. Had you asked
right away how to create a bootloader instead of how to
relocate this and that I would have given totally
different advice.
First, a bootloader that doesn't redirect the interrupt
vectors runs the risk of selfdestruction. If
oing something
> obviously wrong, but I couldn't see it at the time.
>
> Thanks for the advice. Feel free to kill that wiki page if you think it's
> inappropriate. I thought I was helping.
>
>
> On Feb 21, 2010, at 17:40 , Maarten Brock wrote:
>
> >
if there was a way to
> make this all much more flexible.
>
> a*
>
> Anthony Asterisk wrote:
> > Thanks Maarten, your fix has helped! I look forward to your full
> > release. Let me know if you need any assistance with testing.
> >
> > Anthony
> >
Thanks Anthony, it's in revision 5722 now.
> I downloaded the latest version and noticed a small issue with the huge
> memory model. the get_lib_suffix routine is missing the HUGE option...
>
> case MODEL_MEDIUM:
>if (options.stackAuto)
> c = "medium-stack-auto
Mark,
> So, if I build a Linux compatible SDCC on Linux, can I use it to compile
> the libraries and drop them into my windows environment? Or will I end
> up in some CRLF related purgatory?
No, it should work ok.
> What ./configure options do I need to use to enable the huge mode
> build?
Peter,
> I'm compiling stuff for the Wiznet W7100 8051 varient and hit the
> dreaded "can't allocate DSEG" error. A search through the forum indicates
> that --stack-auto and/or large model may fix this. Large model alone didn't
> seem to so I rebuilt from source (vi Cygwin) from a recent snap a
Peter,
> The overflow in DSEG is all
> sloc variables and I don't know how to move those (thats what stack-auto
> is supposed to do I think?) out of the internal ram.
Yes, stack-auto puts the sloc's on stack too. And you
cannot move slocs to any other memory, because then SDCC
would need sloc'
Peter,
>> Yes, stack-auto puts the sloc's on stack too. And you
>> cannot move slocs to any other memory, because then SDCC
>> would need sloc's to access those sloc's.
>>
> Does that then imply a severe limit on arguments to functions? Using
> both --model-large and --stack-auto makes the failing
Hi Raphael,
Can you please verify this also with a larger array? IIRC sdcc checks the
array size (in bytes) and then decides if it can get away with 8 bit
calculations.
Greets,
Maarten
> Hi,
>
> SDCC (not restricted to the pic ports) seems to be buggy with array
> indices;
> the problem is visib
Peter,
If you look at the latest _startup.c you'll see that
_sdcc_external_startup() is now marked __nonbanked. This is a requirement
(or naked) for it to work as you found out.
Maarten
> Thanks to Maarten and Borut's help I was able to get --model-huge code
> working on my system.
>
> I did ru
Oops, I should have addressed Mark instead of Peter.
> Peter,
>
> If you look at the latest _startup.c you'll see that
> _sdcc_external_startup() is now marked __nonbanked. This is a requirement
> (or naked) for it to work as you found out.
>
> Maarten
---
Mark,
You need to put the code and consts in named segments
and locate these somewhere in the banks. See 4.1.3 in
the manual.
Maarten
> I am continuing to experiment with the new --model-huge option.
>
> When I try to link files that exceed 64 of code, I get an insufficient
> memory error f
Why do you use the cast to unsigned int? That inserts a new intermediate
operand.
Maarten
> On Tue, Mar 30, 2010 at 4:28 PM, Sébastien Lorquet
> wrote:
>
>> Hi,
>>
>> Aren't the (shortValue&0xFF) and (shortValue>>8) optimized ? I think
>> they
>> are, at least for pic16.
>>
>>
> Yes they are opt
Anthony,
You can change _gptrget.c and _gprtput.c to make it
select the bank. Then use a generic pointer to your
variables. As long as these functions are in the common
bank it should work.
IIRC there is no support for direct access yet (even
though that would also use _gptrget/put).
Directl
1 - 100 of 538 matches
Mail list logo
