Anthony,
I don't really see how SDCC could help here. Is this debug status register
an SFR? If so you could read it anywhere in your code. But the question is
of course if you still get to that code when it is set. An interrupt might
help here. When detected you can light an LED or something or pe
Scott,
That should do fine. You can also keep an eye on the
generated .mem file because pdata access does not set
_XPAGE every time. I usually let make echo it to the
terminal.
Modifying crtpagesfr.asm may be overkill. The other two
are required.
OTOH for real paranoia you can use an extra pe
Scott,
Are you sure it doesn't write to DPTR1 when you set DPS
to 1 and then perform MOV DPTR,#0 ? B.t.w. SDCC only
uses dual datapointers in the alternative crtxinit.asm
and not in any other (generated) file IIRC.
To use the multiply unit you could adapt the _div*,
ould the normal overflow bit be set
> for this operation?
>
> Anyway this is not high priority for me, I am just being hopeful.
> Thanks for responding!
>
> a*
>
>
> Maarten Brock wrote:
> > Anthony,
> >
> > I don't really see how SDCC could
Peter,
> Can someone suggest how to avoid the allocation in DSEG (which is
> overfull) in the following code snippet?
>
> ...
> void lcd_puts (char xdata *str)
> {
> uint8 xdata i;
>
> for (i=0; str[i] != '\0'; i++) {
> lcd_datas (str[i]);
> }
> }
To put the pointer in xdata yo
Hi Anthony,
This is a known bug. See
https://sourceforge.net/tracker/?func=detail&aid=1579664&group_id=599&atid=100599
Maarten
> Try to remove struct keyword from extern struct ... line.
>
> I thing that compiler behaves according to standard, as typedef struct
> typename defines type, so struc
I have no problems with this code using SDCC 2.9.0 or 2.9.7 #5823.
> Hello, can anyone say if this is an sdcc compiler bug or another case
> where gcc follows a different "standard" than sdcc?
>
> The internal error occurs do to:
>
> extern uint8_t * const uip_buf;
>
>
> If I take away the "const"
Peter,
Since the W7100 uses the value of P2 for MOVX @Ri instructions, P2 should
have the correct value. SDCC supports only one page of 256 bytes and sets
P2 to the correct value during startup (not neccesarily 0). If you also
use P2 for an LCD then either don't use PDATA or be very careful around
Hi Oliver,
I don't see much wrong in your approach. The values for --xram-size and
--code-size are a bit weird though and so is the reported End of Paged Ext
Ram. Isn't the external ram 8192 bytes and 256 bytes internal (default)?
And does your code need more than 64k code? If so, are you using ba
Hello George,
You're right that SDCC doesn't adjust the librarry
search path when --xstack is used. As a work-around you
can use --nostdlib to suppress the default path and add
-L/usr/local/share/sdcc/lib/huge-xstack-auto to point to
the proper library. There is no need to remove the huge-
sta
> On 2010-7-15 02:57, Frieder Ferlemann wrote:
> > Unfortunately SDCC does not support this, so unfortunately
> > there is nothing like callee-clobers-registers R4,R5 or
> > callee-saves-registers R0-R3,R7 or inline-asm-clobers R6.
> Then, will it be supported in near or future?
I don't think so.
Hi,
#pragma codeseg cannot be saved and restored. It is
global for the whole source file. So is #pragma
constseg.
SDCC does not try to replace LCALL with ACALL as it does
not know where the code will end up after linking. There
is a command line option to do this but it will replace
*all* ju
Lenik,
> Now I want to move these AJMP functions in a separate segment which
> starts a 0x800 page.
Then place that segment at that address. See the chapter
about bankswitching in the manual, esp. -Wl-b.
Maarten
--
Th
Hello Richard,
Yes, so long as you ensure the DPTR is not touched in
the DPTR. That means no function calls and no xdata or
code access. Not even C-support functions for generic
pointer access or integer multiplication. I recommend to
carefully inspect the generated assembler for your
ISR's.
Hi,
SDCC does not reserve the register banks for interrupts.
And it should use unused banks for data storage
automatically. Are you perhaps using an ancient version
of SDCC? Or some special command line options?
Maarten
> Saleemuddin Mohd schreef:
> > Hi All,
> >
> > I am compiling my applica
gt; Saleem
>
>
>
>
> On Tue, Jul 27, 2010 at 1:42 AM, Maarten Brock
> wrote:
> > Hi,
> >
> > SDCC does not reserve the register banks for interrupts.
> > And it should use unused banks for data storage
> > automatically. Are you perhaps using an anci
de/mcs51" -isystem
> "/usr/local/bin/sdcc-2.9.7//../share/sdcc/include" -isystem
> "/usr/local/share/sdcc/include" "src/core/ipv4/inet.c"
>
> Can you please let me know how to pack application image to make use
> of unused reg banks for data.
&
Hi,
At least put the prototype in (an include of) the file
that contains main(). This is where the ISR table is
filled.
When you use an included header file I consider it good
practice to also include it where the function is
implemented so the compiler can check the prototype for
being an i
Look in the generated test1.rst and find all the info
you need.
> Hi,
>
> Is it possible to generate a file which containts line number and
> program counter information?
> I have a project (named noname) which contains test1.c. I successfully
> generated the hex file but the lst file is test1.l
Hi Jeonj,
Those lines are not dummy lines but select the bank in
extended intel-hex files.
But please use copy/paste when asking for help as what
you obviously typed over are not generated by the
linker.
Maarten
> Hi,
>
> I successfully compiled the FreeRTOS 6.0.1 on 8051 based processor.
>
Hi George,
Please report this as a feature request in our tracker
system.
Maarten
> Hi all.
>
> I'm trying to port some pre-existing code to sdcc for 8051. In some files,
> the original code uses gcc-style void * arithmetic, similar to this:
>
> static unsigned short foo[15];
>
> void funct
Most probably because nobody was interested in taking up the challenge of
completing and maintaining it. Underlying reason is probably the existence
of avr-gcc.
Maarten
> But why AVR was abandoned?
> It is a polular kind of MCU.
>
>> On 10/12/10 9:13 AM, Claude Sylvain wrote:
>> > >I no
Hello,
Shouldn't ./configure check for gputils?
And I would not silently ignore this error unless both pic's were disabled
in the configuration, which Claude did not do.
Maarten
> Hi,
>
>>+++
>> make[5]: Entering directory
>> `/home/claude/work/software/pc/sdcc/sdcc-src
Hi all,
Have you noticed this? Our recent efforts to get a new
release out the door have brought SDCC into the top 25
projects on SourceForge!
Greetings,
Maarten
--- Forwarded message follows ---
Date sent: Thu, 14 Oct 2010 20:58:31 +
From: "SourceFor
Hello Bill,
I think we will not postpone the release for this issue.
Nevertheless it would be nice if it got fixed one day.
To make sure we will not forget it, can you please turn
this into a bug report in our tracker at sourceforge?
Thank you,
Maarten Brock
Hi,
I recommend to start with an empty main function and
just set and/or clear some outputs, preferably with a
LED connected, in _sdcc_external_startup().
Maarten
> Hello,
>
> I have a hardware board with 80390 core. I want to use SDCC in ds390
> flat42 (24 bit address) memory mode.
>
> But
Arif,
Please inspect the generated .rst files. Especially look when you change
into ds390 mode (my guess is not at all) and when the compiler generates
ds390 code for 24bit jump and call.
Maarten
>
>>> (* please forgive the top-post *)
>
>>> Arif --
>
>>> >>> P1 = 0xFF; //ALL LEDs off
>>> >>>
still *not* in flat24 address mode as
> that is supposed to be done in __sdcc_external_startup
> (which I am doing after LED switching on).
> But as LED is not switched on. It seems control is not reaching
> __sdcc_external_startup function.
>
> Thanks,
> Arif
>
>
>
rving .rst file but you can
> make a better comment after looking at that message of mine.
>
> Also, if this is the case, how can I modify SDCC code generation so that
> the initial 2 jump and lcall instructions are not in 24bit mode?
>
> Thanks,
> Arif
>
>
Hi George,
The T represents the bit bank which contains 8 pseudo bit-registers like
the regular 4 banks of byte registers. It is used by reentrant functions
that need bit parameters or local bit variables. There are probably some
library functions that use it. As it is a bit bank it cannot be move
;
> Thanks again for your time
> Regards
> geo
>
> On 3 Nov 2010, at 18:24, Maarten Brock wrote:
>
>> Hi George,
>>
>> The T represents the bit bank which contains 8 pseudo bit-registers like
>> the regular 4 banks of byte registers. It is used by reentrant functi
Woody,
This was fixed 2 days ago. See Bugs item #3093447.
Please use the latest snapshot instead.
Maarten
> I am testing SDCC 3.0.0 with my Z80 software. Originally I have some inline
> asm like:
> "_asm di _endasm", compiled well with 2.9.0.
> I changed it to "__asm di __endasm" following com
Feel free to report this as a bug. This warning and the
promotion are not necessary for equality comparison (but
it is for < and >).
> Another SDCC 3.0.0 quesstion, I got a lot of "warning 185: comparison of
> 'signed char' with "unsigned char' requires promotion to int".
> Typical code looks l
dcc_external_startup in /device/lib/_startup.c is called properly
> (and control reaches main function too).
>
> Clearly, SDCC flat24 mode for ds390 mcu is not working for me here.
>
> Any suggestion?
>
> Thanks,
> Arif
>
>
>
> -Original Message--
sing
>0012 02 00 00 16 26 ljmp__sdcc_program_startup
> 27
>0016 28 __sdcc_program_startup:
>0016 53 B0 5F 29 anl _P3,#0x5F
>0019 80 FE30 sjmp .
>
>
&g
gt; >0009 75 EB AA 21 mov _TA,#0xaa
> >000C 75 EB 55 22 mov _TA,#0x55
> >000F 75 9D 02 23 mov _ACON,#0x02 ; Put the CPU
> > in 24 bit mode
> > 24
> >
Hi George,
May I suggest that we include these lines in the current
cc2430.h?
Maarten
> Hello all,
>
> I've written a mini header file with declarations for TI's cc2431 RFRs. This
> 8051-based SoC is identical to the cc2430, enhanced with a location engine.
> The loc. eng. is controlled thro
and they appear to have done the same thing).
>
> Whatever works best for SDCC works for me too. If they are to go inside
> cc2430.h, I would recommend something like 'cc2431 only' as part of the
> comment line.
>
> Best Regards
> George
>
> Maarten Brock wro
Hi,
This is impossible. The sfr's are not indirectly
accessable on almost all mcs51 compatible derivatives.
Maarten
> Hi All,
>
> Is there any method to passing an sfr addres to a function?
> And I need to store sfr address to a struct like this:
>
> typedef struct {
> uint8_t cursorX;
Peter,
I only see a bug that was there after 5560 and has been solved again
in 3.0.1. There is no conversion from integer to pointer without
cast in this line:
invalid_ip[0] = IINCHIP_READ(UIPR0+1);
So there should be no warning.
Maarten
> I'm not sure if this is a bug or just question
Philipp,
Why not just commit this to subversion? We are nowhere
near a release so this should not hurt too much. And you
even claim it passes all current regression tests. I see
no reason to keep this separate.
Maarten
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> An sdcc version tha
> On my system:
> Old register allocator:
> Summary for 'ucz80': 0 failures, 5880 tests, 847 test cases, 2208784
> bytes, 5844603 ticks
>
> New register allocator, --max-allocs-per-node 8192:
> Summary for 'ucz80': 0 failures, 5911 tests, 851 test cases, 2058904
> bytes, 6121208 ticks
>
> Any idea
Jan,
Please refresh the page in your browser. There is a new
snapshot already.
Maarten
> http://sdcc.sourceforge.net/snap.php appears not to be updated since Jan 10
> (6092).
>
> JW
--
Protect Your Site and Customer
Karl is not completely right here.
> Your header file should work fine, you need to refer to the sdcc
> manual, there are slight differences between the keil interrupt syntax
> and SDCC.
This header file NOT work with SDCC. It assigns values to sfr typed
variables that the linker will place at
evices* to download the file into the uC
> (works perfectly with Wine), so I can ensure that the problem I'm having is
> with the compiler and not the downloader.
>
> I'll keep working on it and try to find some code examples. I'll tell you if
> I finally can do it :-).
Hi Krish,
Instead of posting this to the other users, it is better to file this as a
bug report in the SDCC tracker system. Otherwise it runs a great risk of
being lost and forgotten.
Greets,
Maarten Brock
> Dear All,
>
> Consider the follo
Hi Dennis,
You don't need to call the linker directly, you can do that through SDCC.
For setting the XRAM size see --xram-size in the SDCC manual.
Maarten
> Hi,
>
> I am a newbie to this list and the SDCC compiler. I'm using Silicon Labs
> IDE.
>
> I am converting a Keil C51 project which has b
Eric,
I think you have them defined 4 times or something like
that. Maybe you forgot to 'extern' them and made them
'static' instead? The fact that Out_Packet is at address
0x0100 and In_Packet at 0x0140 shows that there size is
ok (64 bytes).
Maarten
> Then it's 8 bytes. Even if they're not
Donald,
I guess you're chinese and the language barrier is hindering you to
clearly write down what you mean. But please try to be a bit more
specific. What I understand now is that you have access to the STC
51 core design and that your company (lab) has modified its pipeline
and external cod
> Sherpa Solutions, LLC
> (678) 906-4182
>
>
>
> On Feb 26, 2011, at 3:50 AM, Maarten Brock wrote:
>
> > Eric,
> >
> > I think you have them defined 4 times or something like
> > that. Maybe you forgot to 'extern' them and made them
>
Hi,
Keil uses a very strange symbols (^, =) to define a bit in an sfr. To
standard C they mean 'xor' and 'assign' and thus SDCC treats them as such.
sbit P10 = P1^0;
SDCC sees a definition of an sbit called P10 and it is INITIALIZED with
the value of P1 XOR 0x00. The value of sfr P1 is not const
No, that's not true. If some company creates a compatible copy of a
microchip controller, their license prohibits the use of the header file
with this copy.
Maarten
> As the hardware addresses have no utility other than for mchp hardware,
> it would follow that the license is not the issue.
>
> p
Hi everyone,
I intend to change the file extension for the (mcs51) OMF file from
nothing to .omf. Would anyone have any problem with that?
Greetings,
Maarten Brock
--
Xperia(TM) PLAY
It's a major breakthroug
Julien,
Have you looked really sharp? I expect f1() to generate
a JBC (instead of JB or JNB) and that includes the
clearing of the sbit.
Maarten
>
>Hi,
>
>I am currently having an issue (or a misunderstanding) with sdcc
> mcs51 with a sbit clearing instruction being erroneously (IMHO
Hi all,
When portability is an issue my concerns would be endianness and packing
which none of the posts have addressed. C does not guarantee much about
the position of fields in a union or a struct or the position of bytes in
a long int.
Maarten
> Am 05.05.2011 09:10, schrieb Krishnendu Chatter
SDCC already has a forum on sourceforge. I see no reason to have
another one at a location that has nothing to do with the project.
Maarten
> On Sat, 2011-05-14 at 01:58 -0500, Mark Rages wrote:
> > On Saturday, May 14, 2011, admin wrote:
> > > Hello SDCC-Community,
> > >
> > > There is a SDCC
And for which target would you like to have that?
> Hi, I need to create a .cof file in order to simulate the program, I've
> managed to create a .hex file, but could not find if it is possible to
> create a .cof file... any help?
-
Hello all,
Have you noticed that we ranked nr. 17 in the Top 25 Projects list at
SourceForge this month?
Enjoy your programming,
Maarten Brock
--
What Every C/C++ and Fortran developer Should Know!
Read this article
Hello George,
In this context I recommend to use VECTOR (ABS,CODE)
with a .org 0x. The .globl __interrupt_vect can
probably be left out.
I personally do not fully agree with the chosen solution
in the wiki, because usually the code memory is flash
that needs to be erased in pages and not
George,
You totally understood me correctly.
I advise never to overwrite the bootloader or the reset vector (and thus
the IVT). The bootloader should enforce that.
Let the bootloader forward the interrupt vectors to where the application
will land. Usually for a bootloader it is no problem to wo
Hi,
You probably need to add an undercore in assembly to disp_digits.
Maarten
> Hi,
>
> I have tried a little bit of programming in sdcc for pic before, but
> it never went too far, so treat me as a complete beginner. I have
> studied C programming many years ago, but almost never used it, so
>
Hi Charles,
> The first issue I am having is with SDCC's __sbit syntax.
>
> When I compile, this line:
> __sbit DB7 = P1^7;
>
> sdcc.exe returns with:
> lcd.c:31: error 2: Initializer element is not constant
>
> So after consulting some documentation it seems that the following should
> work, but
Hi Charles,
As Frieder pointed out this code you see is the C
RunTime initialization. Normally it is always included
by the linker but will be skipped at runtime as there is
no xdata used in your program.
If you need to set --iram-size 128 then the simulator
cannot handle idata above 0x7F. Th
Hi Allan,
Unfortunately you can't. This is a long outstanding bug
(1666106) that still needs fixing. It's also the reason
why I started to upgrade the linker some time ago.
Greets,
Maarten
> How do I specify the size of the direct page RAM for the hc08 port?
> --data-loc is working for specify
Hello Charles,
I think what you need is something like srecord
(http://srecord.sourceforge.net/) with which you can split your hex file
into two parts.
Greets,
Maarten Brock
> I have an AT89S52 with an external 30K of flash memory connected. I can
> read from and write to the flash
Hi,
Then you need to recompile at least printf_large.c
(which is the real workhorse here) from the library
sources for your preferred bank segment.
Maarten
> Hello,
>
> I'm using model huge for my application. I would like to put _printf,
> _sprintf etc in BANK3 instead of CSEG. How can I do
George,
I think it's safe to file this as a bug without loosing your
credibility ;-)
Maarten
> Hi all
>
> While playing around with the Contiki OS, I came across something that left
> me scratching my head for a while... I stripped it down to something small
> that will still exhibit the same
> > At the end of the day
> > the behavior depends on the assembler unless we want SDCC to
> > understand the asm syntax.
>
> Exactly. Some assemblers support multiple mnemonics in one line, others
> don't. I think that the original AS supports it, but if I'm not
> wrong, Maarten some time a
> I checked in the installation script and found out that I was wrong: the
> new path is added to the end of PATH variable. If only one version is
> installed this is not a problem, but in this case probably it is: I
> would expect that the latest installed version is the first found.
>
> > So
> I think that side by side installation is already possible by defining
> different installation directory (not 100% sure, I have to try it) both
> on single platform (32 or 64) and on mixed platform (32 and 64). The
> problem is PATH variable, which can point to only one installation and
> we
Hello Peter,
> In the main routine a printf gets the wrong value:
>
> extern __data uint8 * __data sys_rstack;
>
> // string for LCD output
> #define STR_LEN 80
> __xdata uint8 str[STR_LEN];
>
> main()
> {
> sprintf (str,"%x", (uint8) *sys_rstack);
> lcd_print(2, str);
>
> ge
> Am 23.09.2011 19:03, schrieb Raphael Neider:
>
> >
> > We had discussed this problem when it was implemented and did not
> > find *the* ideal solution back then. Not sure if we can find one now
> > :-(
>
> Where can I find this discussion? Not doing the argument promotions
> (i.e. float to dou
> What I really want is
>
> sprintf (str,"%x", sys_rstack);
>
> which is the contents of Data 10h. However the above gets 4000 on the LCD
> because its a pointer.
>
>01B1 12 48 50706 lcall _lcd_print
> 707 ; main.c:107: sprintf (str,"
> > By the way
> >
> > sprintf (str,"%hx", *sys_rstack);
> >
> > displays Hx on the lcd not the now expected 61. In any case thanks for the
> > help!
>
> Since int and short int are identical in SDCC the 'h' modifier is
> not needed. And apparently printf_large.c does not support it.
pri
Hello ...?
Well if the source is different so will be the result.
What was your expectation and what was the result? Why
do you think there is a bug?
Maarten
> I'm so good at English shows the source.
> And the results vary with / uncomment the line 9.
> Is this a known bug?
>
> #include
Hello George,
Your idea is a logical one. When I implemented banking for the mcs51 I
knew this was next. But my implementation is of course totally different
from what the author of AS had done. And since we are now allowed to
merge with the current AS again, my implementation will probabl
Hi George,
What happens in crtbank.asm is under your control when
you write your own. So you can get the correct value in
PSBANK. But what will go wrong is the LSW of the
physical/virtual address. The linked code will jump to
0x when it needs to go to 0x1 instead of the
bank at 0x8000
Hi Gerard,
gen.c is part of the SDCC sources. Please file this as a
bug report in our bug tracker at sourceforge. Include
source code to reproduce it and the version of SDCC you
use. But before you do this first verify this is still
present in a recent snapshot.
Merry Christmas,
Maarten
Hi Roelof,
There is no reply-to address because the question was
posted in the Open Discussion forum. You get an email
from it probably because you are monitoring this forum.
The whole idea about a forum is that everyone can read
the contents, including your answers. If it was your
intent to
Please send this bug report to the SDCC bug tracker instead of informing
the users of it. The users can/will not fix it and the developers, if they
happen to see it, will forget it.
http://sourceforge.net/tracker/?group_id=599&atid=100599
Maarten
> SDCC revision 7520
>
> ;---
Hello John,
> I'm creating a Bootloader firmware reflash feature for my application.
> The SDCC compatible source version of the USB Express library was made
> available via a license. However, the Bootloader example that has been
> on the SiLabs App Note, AN200SW, does not seem to have a 'SDCC'
>
Hi,
Looking in the code generator it seems that __interrupt should turn a
normal function into an ISR and generates some PUSHes/POPs and a RETI. But
it also seems that unless you make it callee-saves it forgets half of the
registers.
If the __interrupt function is also __critical it will use RETN
Hi George,
> First attempt to make it static inline, like s_foo in the attached
> example. The compiler 'may' emit an out-of-line version and in this
> instance SDCC does. So far so good but I want to do this without
> increasing my code size even further by having a separate implementation.
>
> Q
Hello Kustaa,
We do not keep all old snapshot builds. If anyone has it
you may get lucky, but if you depend on it maybe you
should have kept it yourself. OTOH, 2.8.9 is close to
2.9.0 so maybe you could try that. The only real
alternative when it has to be this exact version is to
compile fro
Roelof,
Is there a reason why you use this "poor man's malloc"?
You could also just place a struct variable in memory.
You can initialise the pointer with the address of this
variable. But if it never changes you might as well use
the variable itself. And unless you use its contents in
an ISR
>> And unless you use its contents in
>> an ISR or asm you don't need volatile either.
>
> So, if I read this right I do not have to make the variable
> volatile and can still use it in an ISR (and all the other
> c files).
No, if you want to use the pointer in both an ISR and your main loop you
h
forge.
Kind regards,
Maarten Brock
> Hi,
>
> I'm the current maintainer of the FreeBSD package of sdcc. A user sent
> me this build error on ia64. Can you take a look at this?
>
> Thanks
>
> Tijl
>
> Original Message
> Subject: lang/sdcc fails to
Hi Rich,
The variables from each source file are placed either in the overlay or
data segment. But they are only subdivided by file, not by function or
even variable. And arrays or structs of course cannot be subdivided at
all. So the whole block of all variables from one source file is placed in
Hi Rich,
> Placing the variable definition in a source.c file instead of in a
> header.h file works very nicely to fill in the memory 'gap'.
>
> Placing the variable definition in a header.h file does not fill in the
> 'memory gap'.
Of course it doesn't. Only .c files are compiled into an object
Hi,
Is the user base coupled with SourceForge or should we
all register at this wiki again?
Maarten
> Dear sdcc users and developers,
>
> as you may already be aware, SourceForge is upgrading to a new platform
> (code-named Allura), and as a result, the Classic SourceForge platform
> will be
the mailer is not set up correctly
yet.
Maarten
> On 04. 12. 2012 23:22, Maarten Brock wrote:
> > Hi,
> >
> > Is the user base coupled with SourceForge or should we
> > all register at this wiki again?
>
> You have to register to wiki again.
>
>
o I disabled user
> self-registration. Please contact me if you need the write access.
>
> Borut
>
>
> On 06. 12. 2012 13:30, Borut Raem wrote:
>> I have to configire mailing...
>>
>> Borut
>>
>> On 06. 12. 2012 11:10, Maarten Brock wrote:
>>> H
Hi Don,
Why do you want to compile the header files? Is that what you do wih Keil
too? I think not. It would give a similar error as sdcc does. Header files
are not meant to be compiled, they are meant to be included.
I think you need to get through some C tutorial first. Probably best not
embedd
Hello Vincent,
The reason for this behaviour is that SDCC turns polling and then clearing
a bit/sbit into an atomic action (using JBC). This is very useful when the
bit is a semaphore or is set inside an interrupt handler.
Maarten
> Hi.
>
> I'm looking at asm generated for the following loop (80
GGER or any other hadrware dongle. So you'll have to use other
software that supports reading OMF files for debugging.
Maarten Brock
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows
Hi again,
> Thank you for your answers. I still have some misunderstanding
> below.
>
>>> 3. Will the debugger work with CCDEBUGGER and the CC2541?
>>
>> Well, that depends on the debugging software. SDCC can generate OMF
>> output which contains debugging info. But the SDCDB debugger does not
>>
Hi,
--L is wrong, it should be -L
And with --nostdlib not only the default path is ignored but also the
default library names. So you must specify them on the command line.
Maarten
> Hi
>
> according to the manual there is an '--L' option to specify
> the library paths but when I use it I get:
>
If you want to see which paths are searched and in which order, use
--print-search-dirs on the command line.
> On 14.2.2013 17.18, "Maarten Brock" wrote:
>
> Hi Maarten,
>
> and thanks.
>
>>Hi,
>>
>>--L is wrong, it should be -L
>
> Ok.
>> unsigned int debug = 1234;
>> float julianday = 6116.0;
>>
>> void main(void) {
>> float x = 6116.0;
>>
>> debug = julianday;
>> // expect 6116, obtain a vastly different (arbitrary?) number
>> }
[...]
> If this leaves the correct value in debug, the problem is with
> initializat
protocol is fully described in the user
manual.
Also note that SDCC is not binary compatible with IAR and thus it
will require intermediate assembly to call functions in the IAR BLE
library. Maybe you can ask TI for an SDCC library of the BLE stack
or even the sources.
Greetings,
Maarten Brock
101 - 200 of 538 matches
Mail list logo
