Hi,
Thus wrote Philipp Klaus Krause (p...@spth.de):
> That these two are handled differently looks like a bug to me; I
> suggest to file a bug report.
I've just opened
https://sourceforge.net/p/sdcc/bugs/3495/
> Why not just use static_assert?
Using C11 and static_assert is the best option, y
Am 23.09.22 um 12:09 schrieb Martin Kaiser:
This function compiles
void dummy123(void)
{
{ enum { BLA = 2 }; };
{ enum { BLA = 2 }; };
}
but this one doesn't:
void dummy123(void)
{
{ enum { BLA = 2 }; };
volatile int a = 3;
{ enum { BLA = 2 }; };
}
That these two ar
Dear all,
I'm struggling to understand sdcc's behaviour regarding duplicate
symbols.
This function compiles
void dummy123(void)
{
{ enum { BLA = 2 }; };
{ enum { BLA = 2 }; };
}
but this one doesn't:
void dummy123(void)
{
{ enum { BLA = 2 }; };
volatile int a = 3;
{ enum {
On 20-05-15 11:20, hernani wrote:
hello,
i have this code and give me this errors--->
i put line numbers and bold where give me errors
5.c:53: warning: warning 112: function 'Delay_ms' implicit declaration
This is the first error and it says that Delay_ms is declared here
implicitly (no fo
hello,
i have this code and give me this errors--->
i put line numbers and bold where give me errors
5.c:53: warning: warning 112: function 'Delay_ms' implicit declaration
5.c:53: error: 101: too many parameters
5.c:91: warning: warning 112: function 'Delay_ms' implicit declaration
5.c:88: e
Hi Ricardo,
If you multiply 25586 by 4, you would get 102344... if your calculation
is done with "long". But you're using "int", so the intermediate result
is cut to 16 bits width, giving 102344 % (1 << 16) = 36808. This results
after the division by 5 to 7361.
HTH, Bodo
Good personal later
I'm having a problem in the calculation below, the result is coming out wrong,
signed long int xdata Resultado;
Resultado = 512;
Resultado = Resultado * EEPROM93xx_read( DesenhoCamadas );
// Resultado * 50 = 25600
Resultado = Resultado + ( EEPROM93xx_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 13.11.2013 14:09, schrieb Christophe VG:
>
> On 13 Nov 2013, at 01:03, Philipp Klaus Krause
> wrote:
>> Am 12.11.2013 23:29, schrieb Christophe VG:
>>> Hello,
>>>
>>> while getting sdcc up and running for a new project, I stumbled
>>> upon the f
On 13 Nov 2013, at 01:03, Philipp Klaus Krause wrote:
> Am 12.11.2013 23:29, schrieb Christophe VG:
>> Hello,
>>
>> while getting sdcc up and running for a new project, I stumbled
>> upon the following.
>>
>> $ cat minimal.c typedef unsigned long long QWORD;// 64-bit
>> unsigned typedef sig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.11.2013 23:29, schrieb Christophe VG:
> Hello,
>
> while getting sdcc up and running for a new project, I stumbled
> upon the following.
>
> $ cat minimal.c typedef unsigned long long QWORD;// 64-bit
> unsigned typedef signed long long LO
Hello,
while getting sdcc up and running for a new project, I stumbled upon the
following.
$ cat minimal.c
typedef unsigned long long QWORD;// 64-bit unsigned
typedef signed long long LONGLONG; // 64-bit signed
void main(void) {
}
$ sdcc minimal.c
minimal.c:1: error 206: invalid combinat
Please read chapter 3.4.1.7 of SDCC manual for the __sbit syntax in SDCC.
However, the port bits are included in the device headers, so you can do
e.g. the following:
#include <8051.h>
#define RELAY P1_4
#define K1P2_7
void main(void) {
if (!K1) RELAY = 0;
else RELAY = 1;
}
JW
On Fri, 2013-06-07 at 18:29 +0800, JIA Pei wrote:
>
> So, is there any suggestions by using sdcc?
> How can I make the code both built and work successfully by compiling
> with sdcc ?
The following should work :
#include <8052.h>
#define RELAY P1_4
#define K1 P2_7
void main(void)
{
if(!
#include <8051.h>
#define RELAY P1_4
#define K1 P2_7
void main()
{
if (!K1) RELAY = 0;
else RELAY = 1;
}
Albert
W dniu 2013-06-07 12:29:50 użytkownik JIA Pei napisał:
To whom it may concern:
I kept obtaining the following error message
error 2: Initializer element is not constant
On 07.06.2013 12:29, JIA Pei wrote:
>
> To whom it may concern:
>
> I kept obtaining the following error message
> *error 2: Initializer element is not constant*
> while building the following code using *MCU8051IDE*, from Compiler
> configuration, *MCU8051IDE *adopts *--std-sdcc89* .
>
> */1)
To whom it may concern:
I kept obtaining the following error message
*error 2: Initializer element is not constant*
while building the following code using *MCU8051IDE*, from Compiler
configuration, *MCU8051IDE *adopts *--std-sdcc89* .
*1) Code A*
*#include *
*sbit RELAY = P1^4;*
*sbit K1= P2
On 14.2.2013 15.26, "Kustaa Nyholm" wrote:
>
>Also, there must be something wrong because I also get:
>
>message: using default linker script
>"/usr/local/share/gputils/lkr/18f4550.lkr"
>
>
>although I specify the linker script on the command line, I must
>have something wrong on that command line
On 14.2.2013 10.28, "roelof 't Hooft" wrote:
>
Thanks for the tip, I may end up doing something like that,
however, it looks to me that I should be able to just tell
sdcc to use different path for libraries with -L option.
I've tried this:
/Users/nyholku/sdcc-3.2.0/bin/sdcc "-L
/Users/nyhol
On Thu, 2013-02-14 at 07:17 +0200, Kustaa Nyholm wrote:
> If so, how can I keep the old and new sdcc and gputils
> separate so that I can use both for the time being?
Hi,
What I do is to make seperate directories for each
version of sdcc in /opt/ and have a symbolic link
to it :
roelofh@castle:~
Hi,
I'm migrating some old code from:
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.8.9 # (Feb 10 2009) (Mac OS X i386)
to
SDCC :
mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
3.2.0 #8008 (Jul 6 2012) (Mac OS X i386)
and I've done the
Hello,
It looks like that I found the solution. The answer is here:
https://bugs.gentoo.org/show_bug.cgi?id=389881#c17
I tried this:
export LANG=C
and the problem disappeared.
Thanks for you advice.
Zsolt
2012/2/12 Raphael Neider :
> Hi Gál,
>
>> make[3]: Entering directory `/home/zsolti/svn/s
Hi Gál,
> make[3]: Entering directory `/home/zsolti/svn/sdcc/support/sdbinutils/bfd'
> rm -f targmatch.h
> sed -f ./targmatch.sed < ./config.bfd > targmatch.new
> *** glibc detected *** sed: double free or corruption (!prev): 0x0811a070 ***
You may have found a bug in sed ;-)
You can try compili
Hello,
I check out the latest version of SDCC with svn and start to compile
it. I got this message some minutes later:
make[3]: Entering directory `/home/zsolti/svn/sdcc/support/sdbinutils/bfd'
rm -f targmatch.h
sed -f ./targmatch.sed < ./config.bfd > targmatch.new
*** glibc detected *** sed: dou
Am 24.03.2011 13:05, schrieb Sébastien Lorquet:
> GCC is better designed for CPUs where all the different memories (RAM,
> ROM, etc) are accessible in an homogenous manner, such as x86 , ARM,
> MIPS,
>
> PIC and 8051, however, have different address spaces for program and
> data, and SDCC doe
GCC is better designed for CPUs where all the different memories (RAM, ROM,
etc) are accessible in an homogenous manner, such as x86 , ARM, MIPS,
PIC and 8051, however, have different address spaces for program and data,
and SDCC does a better job than GCC at managing them.
I don't know anyt
Hi Doland,
The program is perfectly fine. The simulation is producing the
expecting result as well. How are you simulating the program?
You should not call the assembler or linker explicitly. Let it be
called by sdcc itself.
Krish
On Wed, Mar 23, 2011 at 10:26 PM, duck donal wrote:
> Hi roelof
On Thu, 2011-03-24 at 00:56 +0800, duck donal wrote:
> #include
> #include<8051.h>
You only have to use the header which is appropriate for
the processor you are using, 2 mostly the same header
files is overkill :-)
> __sfr __at (0xfb) f_work;
> f_work=0x01;
> while(F1==0)
>
Am 23.03.2011 18:16, schrieb duck donal:
> Hi Krish,
>Thank u for the detail!
>Actually I've konwn the three stages.
>What I want to konw is the anatomy of each stage.e.g,for compile
> stage,a c source file need to pasing,generating icode etc,I want to konw
> that what's the Intermedia
Hi Krish,
Thank u for the detail!
Actually I've konwn the three stages.
What I want to konw is the anatomy of each stage.e.g,for compile stage,a
c source file need to pasing,generating icode etc,I want to konw that what's
the Intermediate language of SDCC,does it generate a language like
Hi roelof,
Thank u for ur advices!
I have a new trouble with simulating the .hex code on my 8051.
The newpp.hex according to the newpp.c(as follow):
//newpp.c
#include
#include<8051.h>
__sfr __at (0xf1) f_wren;
__sfr __at (0xf2) f_pp;
__sfr __at (0xf3) f_wr_adrH;
__sfr __at (0x
C compiler works in three stages --- 1) compiler, 2) assembler and 3) linker.
1) Compiler: Takes C code and generates assembly code.
2) Assembler: Takes assembly code and generates machine specific binary code.
3) Linker: Combines binary codes and fills up all address references.
SDCC and GCC are
Hi Donald,
On Wed, 2011-03-23 at 14:13 +0800, duck donal wrote:
> Hi,Krish
> Thank you so much for answering my questions detailedly!
Krish does a much better job in explaining then I do, I can
learn form him :-)
> I‘ve got it.Thus next time I'll check the <.h> file to find out
> the sp
Hi,Krish
Thank you so much for answering my questions detailedly!
I‘ve got it.Thus next time I'll check the <.h> file to find out the
specific register name of machine in SDCC.
Now I really want to know what SDCC compile flow is.How a c code become to
be a assembly code,even the machine c
Hi Donald,
I am trying to re-clarify the concept of __sfr and __sbit.
The statement '__sfr __at 0x9A MY_SFR' means that a new SFR is
declared at 0x9A which is identified by the name MY_SFR in this
program.
However, this does not mean that MY_SFR.0 or MY_SFR_0 can be used to
access the 'bit 0' of
Hi Maarten,
I want to know more about SDCC internal information,such as the SDCC
compile flow,What is the difference between SDCC and GCC
how SDCC combine the front-end with back-end,will SDCC generate RTL stuff
like that?
I know you are a superior,so could u give me some detail materials?
Th
Hi roelof,
Thanks for your help!
I run what you modify code in my pc,It can be compiled successfully!
However I have some questions to this code.
1.What you use library files(p89lpc938.h) seems not the standard 51
library files.Does that mean I can subsitute this library for standard
51
On Tue, 2011-03-22 at 10:02 +0800, duck donal wrote:
> Hi All,
> I'm a newbie for sdcc.
> A few days ago, I was in use of SDCC, ran into a problem.
> So,what is the solutions?To modify the program?How to do it?
> Or modify the sdcc?
Hi Donald,
Here is your example code back, I modified it a bit
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
Hi Donald,
The keyword 'sbit' is used to define special function bits, much like
the keyword 'sfr' for the special function registers. The good news is
that most of the SFRs in 8051 are already defined in <8051.h> Thus to
set the 4th bit of PORT-2 to 0, use the following code:
#include <8051.h>
Hi All,
I'm a newbie for sdcc.
A few days ago, I was in use of SDCC, ran into a problem.
Program (bee.c) is very simple, as follows:
#include
#include
sbit P10=P1^0;
sbit P17=P1^7;
int main(void)
{
unsigned char j;
unsigned int i;
while
Hi Jonathan,
> message: using default linker script
> "/usr/local/share/gputils/lkr/18f2431.lkr"
> warning: relocation of section ".idata" failed, relocating to a shared
> memory location
> error: linker script has no definition that matches the type of section
> ".idata"
Well, actually the
I'm new to sdcc, I have no idea whats going on here.
The code was written for pcm C, im hacking it about to see if sdcc will build
it.
$ sdcc --debug -mpic16 -p18f2431 matrix_led_7x10.c
matrix_led_7x10.c:20: warning 85: in function output_a unreferenced function
argument : 'ch'
matrix_led_7x10
Maarten Brock wrote:
> 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 feel a bit embarrassed--somehow I convinced myself that bank
assignment was being handled by sdcc. This also explains
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
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 from the linker:
?ASlink-Error-Insufficient ROM/EPROM/FLASH memory.
I assume that I will need to modify the linker script and manually link
th
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
---
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
Thanks to Maarten and Borut's help I was able to get --model-huge code
working on my system.
I did run into one issue: if my code contains a _sdcc_external_startup
routine, the stack gets blown up on return.
As far as I can tell, what happens is this:
1. We jump to _sdcc_gsinit_startup
2. _sd
Hi Borut,
thanks for the information and the fast reply. I'll check the SVN
repository during the coming week.
Thanks!
Best Regards
Bernhard
--
This SF.net email is sponsored by:
High Quality Requirements in a Collabora
Hi Bernhard,
the problem is that asranlib is a native win32 applications, so it
doesn't accept cygwin format paths (/cygdrive/c/...). We have to use
cygpath -w /cygdrive/c/... to convert cygwin format path to windows
format path (c:\...)
The asranlib invocation should look like:
../../bin/as
Hi,
I want to cross compile the sdcc-2.9.0 sources on cygwin. For this
reason, i moved the file "sdcc_cygwin_mingw32" to the root directory and
ran the script. However, I get a few error messages which are attached
below.
I also tried cross compiling sdcc-2.9.0 on linux (Kubuntu Gusty). I got
t
I must apologize! I have commented out lines 218, 219, 234 in temete1.c.
This is not a good patch indeed (it's just to be able to compile),
BECAUSE I can only use one interrupt (since it doesn't distinguish the
source of the interrupt). I also ignore if it might have any other
drawbacks.
So, plea
Hi Néstor,
>>> # sdcc -mpic14 -p16f877 --nooverlay
>>> -I/usr/local/share/sdcc/include/pic/ -I/usr/local/share/sdcc/include/
>>> -c temete1.c
>>> temete1.c:62: warning 85: in function PaintClockTest unreferenced
>>> function argument : 'x'
>>> temete1.c:62: warning 85: in function PaintClockTest u
Hi Raphael,
On Mon, Apr 6, 2009 at 1:46 PM, Raphael Neider wrote:
> Hi Nestor,
>
>> # sdcc -mpic14 -p16f877 --nooverlay
>> -I/usr/local/share/sdcc/include/pic/ -I/usr/local/share/sdcc/include/
>> -c temete1.c
>> temete1.c:62: warning 85: in function PaintClockTest unreferenced
>> function argumen
Hi Nestor,
> # sdcc -mpic14 -p16f877 --nooverlay
> -I/usr/local/share/sdcc/include/pic/ -I/usr/local/share/sdcc/include/
> -c temete1.c
> temete1.c:62: warning 85: in function PaintClockTest unreferenced
> function argument : 'x'
> temete1.c:62: warning 85: in function PaintClockTest unreferenced
Hello (and thanks in advance).
I'm having trouble when compiling an application. I'm using interrupts
to control a timer which changes a clock so it works as a countdown.
The problem arises when assembling the application, I get the
following error:
# sdcc -mpic14 -p16f877 --nooverlay
-I/usr/loca
Michelle,
I corrected it.
Thanks,
Borut
Michelle Konzack wrote:
> Hello *,
>
> In the website is written:
>
> March 22th, 2008: Small Device C Compiler 2.9.0 released.
>
> Released last year?
>
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
> Systemadministrator
> 2
Hello *,
In the website is written:
March 22th, 2008: Small Device C Compiler 2.9.0 released.
Released last year?
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linu
On Monday 28 July 2008, George M. Gallant wrote:
> Peter,
>
> The coding is similar. The RAM is organized in banks of 256 bytes, the
> stack is 31 entries deep, three index registers with 4 addressing modes,
> the stack is usable for data storage, and a 10MHz oscillator can be X4,
> loads of A/D.
>
Peter,
The coding is similar. The RAM is organized in banks of 256 bytes, the stack
is 31 entries deep, three index registers with 4 addressing modes, the
stack is usable for data storage, and a 10MHz oscillator can be X4,
loads of A/D.
And SDCC works!
George
Peter Chant wrote:
> On Sunday 27
On Sunday 27 July 2008, George M. Gallant wrote:
> Since the pic16f877a has 386 bytes of RAM, saving a few hundred words
> would be significant. The pic18f2620 is in the same package with almost
> 4k bytes of RAM at a very similar price. Just my 2 cents, but if you are
> that
> close to the limits,
Since the pic16f877a has 386 bytes of RAM, saving a few hundred words
would be significant. The pic18f2620 is in the same package with almost
4k bytes of RAM at a very similar price. Just my 2 cents, but if you are
that
close to the limits, it is time to consider different hardware.
George
Dan
I'm new to the SDCC, but I think that, generally, there are two linker
files for each PIC - one for use with the debugger and one for
"production." The one for the debugger allocates memory in the PIC for
the debugger. If you're linking with that file, you could recover some
memory by linking
> error: no target memory available for section "ID_piccode_1"
You ran out of data memory (ID_xxx is initialized data). The message tells
you that the linker was unable to put initialized PLUS uninitialized data
into the available memory banks.
Try splitting you data structures into multiple sour
Hi,
I'm trying to compile a program with 3kb, but I'm getting this message:
error: no target memory available for section "ID_piccode_1"
The device is a pic 16f877a, which has 8kb of program memory.
Is there something that i could do to compile this code without rewritting a
smaller code?
Than
David Henningsson schrieb:
> I'm trying to link my program (using sdcc windows snapshot from
> yesterday), using this command:
>
> sdcc -mpic14 -p16f877 main.o sci.o lcd.o delay.o buttons.o trital.o
Try adding
-Wl-s16f877.lkr
to the sdcc call and copy the appropriate lkr file to you project
I don't know the answer to your question, but I think I see a
problem with the Makefile.
Try replacing this line
$(CC) $(CFLAGS) $?
With this:
$(CC) $(CFLAGS) $^
The $? variable gives you "the names of all the prerequisites that
are newer than the target," but you don't want a partial l
I'm trying to link my program (using sdcc windows snapshot from
yesterday), using this command:
sdcc -mpic14 -p16f877 main.o sci.o lcd.o delay.o buttons.o trital.o
And I receive this error:
error: linker script not specified
Any clues? Here's the entire makefile:
--
CC = sdcc
CFLAGS =
Hi!
I am trying to port some code from avr-gcc to SDCC to the mcs51
architecture.
Version:
d:\pjrc\nutbld\c>sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.7.0 #4818 (May 31 2007) (MINGW32)
The stripped-down code is:
// code starts on NEXT line
Hi Milan,
> I can compile it, but building all produces an output:
>
> sdcc -mpic16 -p18f1220 -V -Wl-c -Wl-s/usr/share/gputils/lkr/18f1220.lkr
> -I/home/milan/ide/piklab/sdcc/ad_test/ -I/usr/share/sdcc/include/pic16/
> -oad_test.hex adtest.o
> warning: processor mismatch in "/usr/bin/../share/s
Sorry, I am newbie and I am playing with Piklab + sdcc.
This little testing code:
#include"pic18f1220.h"
#include "adc.h"
void main() {
long temp;
adc_open(ADC_CHN_1, ADC_FOSC_4, ADC_CFG_5A_0R, ADC_FRM_RJUST);
while (adc_busy()) ;
temp = (adc_read());
}
I can compile it,
Hi,
this is the part of the code which passes the arguments to the sdcc
which work fine some time some time gives error...
void MainWindow::compile()
{
QString fileName = projectFileList.at(0);//File path which is to be
compiled
if(!fileName.isEmpty()){
QString program = "sdcc.exe";
I've seen an error like this when the directory I am trying to compile
to doesn't exist.
In your example, does the directory 'abc' exist? It could be that your
IDE is using an unexpected directory as its working directory.
Abhishek / TRI Technosolutions Pvt. Ltd. wrote:
>
>
>
>
> Hi
> i m dev
/*
Just a suggestion: compile this little source and use it instead of SDCC.
You'll see what your IDE gives the compiler, and I'm sure the error will be
apparent in the file written.
*/
#include
int main(int argc, char *argv[]) {
FILE *dump;
dump = fopen("ide2sdcc.log", "w");
if (dump !
Hi
i m developing the IDE for sdcc i have successfully connected the sdcc with
my front end ..
now when i m compiling using this IDE sdcc gives an error "-:0: error 4:
'fopen' failed on file '/abc/document1.asm' "
can any one just help me out in solving this error...
--
Regards-
Abhishek..
Hi again,
forgot to answer your questions...
> I want to know one more thing in pic16f877 to start an a/d convertion
> we have to set the GO/Done bit in the adcon0 .but in the header file
> it this bit is defined in three ways GO , NOT_DONE,GO_DONE will you
> plz tell which bit i have to set to b
> So, more banksels can be removed if the compiler will allocate the
> addresses for the variables.
Yes but the linker is there to allocate the space.
It would be sufficient for the compiler to know some blocks
of variables which must be allocated in the same bank, leaving
the linker scope to ass
Dear All,
> The new code (some time before 2.6.3) is more pessimistic and always
> generates banksels unless it is sure that a banksel is not required.
> Thus 2.6.3 emits more banksels than 2.6.0.
> The patch contributed by Alex identifies another class of redundant
> BANKSELs and removes them.
I
On Thursday 25 January 2007 12:10, Raphael Neider wrote:
> Am Donnerstag, den 25.01.2007, 15:57 +0530 schrieb george john:
> > But the problem is with the compiler if we compile the above code
> > with sdcc 2.6.0 it will work but with sdcc 2.6.3 it will not work.
>
And I'd say its not as much a p
Am Donnerstag, den 25.01.2007, 15:57 +0530 schrieb george john:
> But the problem is with the compiler if we compile the above code
> with sdcc 2.6.0 it will work but with sdcc 2.6.3 it will not work.
After 2.6.0 was released I meddled with the banksel generation code in
the compiler because the
But the problem is with the compiler if we compile the above code with sdcc
2.6.0 it will work but with sdcc 2.6.3 it will not work.
On 1/25/07, Ernst Bachmann <[EMAIL PROTECTED]> wrote:
On Thursday 25 January 2007 08:50, george john wrote:
> > EECON2 = 0x55; // Wr
> Latest snapshots only available trough SVN ?
Seemingly. According to the SF Compile Farm Status Page
http://sourceforge.net/docman/display_doc.php?docid=10472&group_id=1#top, the
compile farm is more or less down since 2007-01-05.
SVN works, however.
Regards,
Raphael
--
Hi Raphael,
Latest snapshots only available trough SVN ?
Regards,
KTy
Quoting Raphael Neider <[EMAIL PROTECTED]>:
> Hi,
>
> > Depending on the compiler optimization, redundand banksels etc, your EECON2
> > writes won't be translated into the exact reqired ASM sequence.
> >
> > Please check th
Hi,
> Depending on the compiler optimization, redundand banksels etc, your EECON2
> writes won't be translated into the exact reqired ASM sequence.
>
> Please check the intermediate ASM code generated by SDCC if that is the case.
Ernst is right, SDCC inserts a redundant BANKSEL before updating
On Thursday 25 January 2007 08:50, george john wrote:
> > EECON2 = 0x55; // Write "password" to EECON2
> > EECON2 = 0xAA;
> > WR = 1; // Initiate a write cycle
> >
Well, the PIC Datasheet claims that an exact timed sequence is ne
I forget to point out one thing when i use the sdcc version 2.6.3 it
compile successfull but the data was not written on the eeprom.When the same
code compiled with sdcc 2.6.0 then it work successfully,data is written on
the eeprom.Is this a bug of sdcc 2.6.3.If it is abug of that version plz
inf
#define __16f877A
#include"pic/pic16f877a.h"
void WriteByteToEE(unsigned char d, const unsigned char ad);
void main(void)
{
WriteByteToEE( 0x45,0x01);
while(1)
{
}
}
void WriteByteToEE(unsigned char d, const unsigned char ad)
{
//EEADRH=0x21;
EEADR = ad; // Ad
Floating point arithematics is working well in sdcc.I set up an A/D
convertor with an accuracy of .0048V .Using sdcc the convertion is very
easy.
On 1/19/07, Raphael Neider < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi John,
> > >
> > > > sdcc:
> > >
/home/users/s/sd/sdcc-builder/build/sdcc-bui
The problem is solved it is some wrong with the code
On 1/20/07, george john <[EMAIL PROTECTED]> wrote:
Is OR and AND operation is supported in SDCC .whether hearder file is
required or not
TRISD=0x00;
PORTC = PORTC|0x04; //rs=0,rw=1,E=2 for command rs=0 rw=0 and
en=1(0100)
PORTD=x;
OR and AND operators are supported without a need for a header files, these
are built in language operators.
However registers like TRISD, PORTC etc. are defined in a header file.
--
Ori Idan
On 1/20/07, george john <[EMAIL PROTECTED]> wrote:
Is OR and AND operation is supported in SDCC .whet
Is OR and AND operation is supported in SDCC .whether hearder file is
required or not
TRISD=0x00;
PORTC = PORTC|0x04; //rs=0,rw=1,E=2 for command rs=0 rw=0 and
en=1(0100)
PORTD=x;
PORTC=PORTC^0x04;
this code is not working plz replay me
On 1/20/07, george john <[EMAIL PROTECTED]> wrote:
i am using sdcc version SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3 #4543
(Dec 31 2006) (UNIX)
I solved the compilation problem by typecasting value5 and value6 now
compilation is ok.I am not sure about the result.now i am trying to check
that part.I want to know
Hi John,
> sdcc:
> /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609:
> genModOneByte: Assertion `result->aop->size == 1' failed.
> Caught signal 6: SIGABRT
Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the report.
> void multiply()
> {
> value=ADRESH
I use sdcc to compile a program to read a analog input and display it on an
lcd .but i get the following error.
sdcc:
/home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609:
genModOneByte: Assertion `result->aop->size == 1' failed.
Caught signal 6: SIGABRT
.
#include"pic/pic
> In fact, this must be quoted:
> -Wl,"-s /usr/share/gputils/lkr/18f442.lkr"
> or replaced with
> -Wl,-s -Wl,/usr/share/gputils/lkr/18f442.lkr
> as both -s and the path need to become arguments to the linker.
Or separated by commas:
-Wl,-s,/usr/share/gputils/lkr/18f442.lkr
-
> Also to be ignored or be suppressed via
> -Wl,-s /usr/share/gputils/lkr/18f442.lkr
> to tell explicitly, which linker script to use.
In fact, this must be quoted:
-Wl,"-s /usr/share/gputils/lkr/18f442.lkr"
or replaced with
-Wl,-s -Wl,/usr/share/gputils/lkr/18f442.lkr
as both -s and the path nee
> Anyone Know how to solve this??
Jepp.
> --
> ~$ sdcc -mpic16 -p18f442 led.c
> Processor: 18f442
> warning: processor mismatch in
> "/usr/bin/../share/sdcc/lib/pic16/crt0i.o"
Solved by ignoring or passing -Wl,-w to sdc
Anyone Know how to solve this??--~$ sdcc -mpic16 -p18f442 led.cProcessor: 18f442warning: processor mismatch in "/usr/bin/../share/sdcc/lib/pic16/crt0i.o"
message: using default linker script "/usr/share/gputils/lkr/18f442.l
98 matches
Mail list logo
