Thomas Zepf via Sdcc-user wrote on 2024-12-30 03:34:
SDCC v4.4
I need to add some lowlevel asm functions to my project. Since i dont
like output files in my src directory i am using relative paths. All
outputs go to my ./SDCC/ob/j sources are at ../src/
When i am doing "sdas8051 -losg .\obj\lowle
SDCC v4.4
I need to add some lowlevel asm functions to my project. Since i dont like
output files in my src directory i am using relative paths. All outputs go to
my ./SDCC/ob/j sources are at ../src/
When i am doing "sdas8051 -losg .\obj\lowlevel ..\src\lowlevel.as" all outs are
in .\obj\ e
Am 09.12.18 um 10:22 schrieb 晓锋 李 via Sdcc-user:
> Hi:
>
> 我想我遇到一个SDCC关于除法取余运算的BUG。
> I think I came across an SDCC bug about the divide operation.
>
> 测试代码如下
> Test code is as follows：
>
> void modtest2(unsigned int t)
> {
> while(t != 0){
> t % 10;
> printf("t
Hi:
我想我遇到一个SDCC关于除法取余运算的BUG。
I think I came across an SDCC bug about the divide operation.
测试代码如下
Test code is as follows：
void modtest2(unsigned int t)
{
while(t != 0){
t % 10;
printf("t = %d, mod10 = %d\r\n", t, t%10);
t = t
> On 7 Sep 2016, at 00:24, Raphael Neider wrote:
>
> Hi,
>
> I have now created the ticket: https://sourceforge.net/p/sdcc/bugs/2543/
>
> I'm currently trying to get (regression) tests for pic16 running with gpsim,
> but setup, execution, assertions, ... seem to not work for me :-(. Needs --
Hi,
I have now created the ticket: https://sourceforge.net/p/sdcc/bugs/2543/
I'm currently trying to get (regression) tests for pic16 running with
gpsim, but setup, execution, assertions, ... seem to not work for me :-(.
Needs -- again -- more looking into...
How to proceed? I could check-in the
>Please create a bug ticket in http://sourceforge.net/p/sdcc/bugs/, and attach
>your patch.
>
>Thanks.
Was the ticket created?
wbr Kusti
--
___
Sdcc-user mailing list
Sdcc
>I believe I have a fix for all issues you reported:
I can report that I'm now able to build from source and test this and
initial impression is that this fixes the issue, still need to put back
my original and see that it works alright in this situation and
that I don't see regression anywhere e
n...
wbr Kusti
From: "rnei...@web.de"
Reply-To: "sdcc-user@lists.sourceforge.net"
Date: Tuesday, 30 August 2016 03:12
To: "sdcc-user@lists.sourceforge.net"
Subject: Re: [Sdcc-user] Bug in 'removed redundant BANKSEL' ?
Hi,
I believe I have a fix f
Please create a bug ticket in http://sourceforge.net/p/sdcc/bugs/, and attach
your patch.
Thanks.
在2016年08月30 08时12分, "Raphael Neider"写道:
Hi,
I believe I have a fix for all issues you reported:
- useless MOVFF x,x removed (in this particular situation -- there may be more
situations l
Hi,
I believe I have a fix for all issues you reported:
- useless MOVFF x,x removed (in this particular situation -- there may be
more situations like this)
- missing BANKSEL added (incorrect removal was caused by the useless MOVFF,
because it used an operand that -- if we had a BANKSEL for it --
Here is a minimal self contained test case that produces the problem:
//--
typedef struct {
char member;
} test_type;
extern test_type g_test1[];
extern test_type g_test2;
void foobar() {
g_test2.member = g_test1[0].member;
g_test2
>>
Reply-To:
"sdcc-user@lists.sourceforge.net<mailto:sdcc-user@lists.sourceforge.net>"
mailto:sdcc-user@lists.sourceforge.net>>
Date: Monday, 29 August 2016 10:56
To: "sdcc-user@lists.sourceforge.net<mailto:sdcc-user@lists.sourceforge.net>"
mailto:sdcc-user@
Hi Kusti,
I fear that you are right: there seems to be a banksel missing for
g_stepperstate before 01020 - and if that's added, the one removed in 01021
needs to stay.
I also agree that the movff statements should not be in there.
I'll try to look into this tonight and tomorrow evening, but it has
Hi,
spent a better part of the evening trying to figure out why my code does not
work.
In the early hours of the morning I came up with this test code (in "main.c"):
void testxxx() {
hid_tx_buffer.uint8[33] = g_stepper_state[1].position.uint8[1];
hid_tx_buffer.uint8[34] = g_step
Good Morning,
I'm pruning some dead wood from my code and so I happened across this
this situation:
In the .h file I've got:
extern volatile stepperState __at( 0x0600 ) steppers[];
and in the .c file:
volatile stepperState __at( 0x0600 ) steppers[NUM_OF_MOTORS];
the arrays/variable 'st
Dear Tamas,
I use piklab software to write my PIC projects. Normally it does all
compilation and links fine.
I invite you to enjoy it too.
I was looking about ande bellow the arguments used by piklab to compile and
link. [NOTES] introduced here to clean my specific files. Please replace by
the y
Hi,
> (looked into lst file and checked the content of the hex file).
>
> When there are no interrupt routine specified, the main code was put directly
> to 0x00 address.
> It works, but not good practice, because it overlaps the interrupt vectors.
> Even without interrupt routines defined, the i
On 03.03.2013 19:25, Philipp Klaus Krause wrote:
> Sounds like you don't link a crt0.o or not the right crt0.o.
Read crt0.rel for crt0.o.
Philipp
--
Everyone hates slow websites. So do we.
Make your web apps faster wit
On 01.03.2013 13:33, Butuza Tamas wrote:
> Hello, I made some further investigations.
>
> (looked into lst file and checked the content of the hex file).
>
> When there are no interrupt routine specified, the main code was put directly
> to 0x00 address.
> It works, but not good practice, becaus
Hello, I made some further investigations.
(looked into lst file and checked the content of the hex file).
When there are no interrupt routine specified, the main code was put directly
to 0x00 address.
It works, but not good practice, because it overlaps the interrupt vectors.
Even without inter
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
Hi,
I don't know if you're doing it right or not, but for pic16 I always had success
by using the routines and helpers from signal.h
The only thing you can't do is declare an interrupt routine in a H file and
define it elsewhere (and I don't know why :) ).
Regards,
Sebastien
Le 28/02/2013 10:25
Why not compiling, assembling and linking in one command:
sdcc -mpic16 -p18f46k22 test.c
SDCC assembles and links the needed libraries by default. I think the -I.
is not necessary.
If you need a custom linker script (e.g. MylinkerScript.lkr) it can be
provided like this:
sdcc -mpic16 -p18f46k22
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 at the
beginning.
I tried to use timer interrupt, but my program was not able to run. After some
investigation, I foun
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
>
> ;---
SDCC revision 7520
;
; File Created by SDCC : free open source ANSI-C Compiler
; Version 3.1.4 #7520 (Mar 31 2012) (MINGW32)
; This file was generated Fri Apr 06 04:20:22 2012
;
Hi,
> There is a bug around interrupt handling on pic14 enhanced core devices
> (PIC16F1936, 12F1822, ...):
[...]
> Could you please implement this (it means now disable an existing feature for
> these devices) in sdcc?
I have augmented the pic14devices.txt in r6998 to declare enhanced
cores as
Dear sdcc developers,
There is a bug around interrupt handling on pic14 enhanced core devices
(PIC16F1936, 12F1822, ...):
Now sdcc generates these instructions inside the interrupt routine:
MOVFFSR,W
MOVWF ___sdcc_saved_fsr
It is a bug: Pic 14e devices has no FSR register,
Hi SDCC developers,
I've written some code for the PIC18F2620 that uses function pointer
arrays. Whilst mucking around doing some debugging, I found that the
pic16 port of SDCC crashes when attempting to handle an array of const
pointers that is declared without an initialiser. As an example, for
Thanks Maarten. I have posted it as a bug in the tracker system.
Krish
On Mon, Feb 21, 2011 at 10:50 PM, Maarten Brock
wrote:
> 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
> be
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 following code:
>
> -
Dear All,
Consider the following code:
-
struct S1
{
char a, b, c;
};
typedef void (*foo_t)(void *arg);
struct S2
{
__xdata void *p;
foo_t f1, f2, f3;
};
void foo1 (void *arg) {arg;}
void foo2 (void *arg) {arg;}
void foo3 (void *arg) {ar
Am 21.11.2010 20:57, schrieb Lin Rongrong:
> Finally I installed a Linux and compiled Nov 21 snapshot.
> Following Alexander's way, after changing SDCCpeeph.c both "127" in line
> 210 and line 253 to "100", now my 300k bytes binary Z80 software works.
> What Alexander did, only change line 210 to
a safe
value.
Woody
http://palmmicro.com/woody/
- Original Message -
From: "Philipp Klaus Krause"
To:
Sent: Monday, November 22, 2010 4:22 AM
Subject: Re: [Sdcc-user] bug #3109557
> Am 21.11.2010 20:57, schrieb Lin Rongrong:
>> Finally I installed a Linux and c
Finally I installed a Linux and compiled Nov 21 snapshot.
Following Alexander's way, after changing SDCCpeeph.c both "127" in line
210 and line 253 to "100", now my 300k bytes binary Z80 software works.
What Alexander did, only change line 210 to "125" does not solve my problem.
Compared with 2.
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 look at the sample codes:
>
Hi, all
We post this message for someone who might be put in a great
quandary like us.
Please look at the sample codes:
#define NR_TEST_FUNCS 2
typedef code struct test_funcs {
void (*non)(void);
} test_funcs_c;
test_funcs_c * data t
Last news,
I have debugged the application, and the problem is not with the
comparison. I'm sending another email to clarify this and ask for help
in a different thread.
Thank you.
On Tue, Mar 24, 2009 at 3:32 PM, Néstor wrote:
> Dear Raphael,
>
> On Tue, Mar 24, 2009 at 1:40 PM, Raphael Neider
Dear Raphael,
On Tue, Mar 24, 2009 at 1:40 PM, Raphael Neider wrote:
> Dear Néstor,
>
>> // This reads memory until it gets to the correct language.
>> for (i=0; i>language; i++)
>> {
>> while (text[0] != 0)
>> {
>> text[0] = SerialReadPostIncr();
>> }
>> }
>
> Did you m
Dear Néstor,
> // This reads memory until it gets to the correct language.
> for (i=0; i>language; i++)
> {
> while (text[0] != 0)
> {
> text[0] = SerialReadPostIncr();
> }
> }
Did you mean `for (i=0; i < language; i++)' with i LESS THAN language
here?!?
I did not even
I have found an error when comparing two variables. No matter of the
values, it always gives FALSE.
In this app an error happens in line 110 when comparing two variables.
It's been compiled for a 16F877 PIC with SDCC version (compiled from
repository):
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14
I've submitted a bug report as requested.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost i
Maartan,
I think it is a lo risk change, so go ahead and fix it before you run
away to Colombia :-)
Bourut
Maarten Brock wrote:
> 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 kno
Hi Andy,
Andy Green schrieb:
> The code for printf (printf_large.c) is as follows. My question is,
> should the space conditions be '>=' rather than just '>' ? (I did some
Yes, good catch! Could you file a bug report so this is automatically
seen on sdcc-devel?
(if it's too much hassle I'll fil
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 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
raw byte dumps of a __code U08 *, and the type was 0x80. And with the
change made, I get the correct output from printf!
Cheers,
Andy
Hi,
I found a bug regarding the file mc68hc908jkjl.h of the HC08 port. I found the
include file contains some not-valid register names. I have corrected and
attached it to this email. There were repeated names, my project now compiles
without any troubles. I have checked its functionality with
-
¡Capacidad ilimitada de almacenamiento en tu correo!
No te preocupes más por el espacio de tu cuenta con Correo Yahoo!:
http://correo.yahoo.com.mx/--- Begin Message ---
Hi,
I found a bug regarding the file mc68hc908jkjl.h of the HC08 port. I found the
Hi,
1. How are the SFR's defined? Are you using both the "sfr" and "at"
keyword? Are you trying to initialize them in the same line where
they are defined?
2. Where does "-b CSEG = 0x" come from? SDCC no longer
automatically uses that line. It uses "-b HOME = 0x" instead.
Maarten
> M
Moving a 8051 project for EZUSB (Cypress FX2LP CY7C68013A) from SDCC version
2.3.8 to 2.7.0 encounted two linker problems:
1. wrongly counts the SFR space in the DATA memory size as a result
displayes "Insufficient space in data memory."
as\link\mcs51\lkmem.c line: 182
2. the program won't run if
I've done quite a bit of searching for CRC algorithms using
polynomial 0x1021 and testing them. Without even looking at your
code, let me tell what I've found.
Only one algorithm of the four I found returns the "correct" value
of 0xE5CC on the 9-character test string when initialized to
0x.
On Mon, 11 Dec 2006, Greg Mann wrote:
> I am beyond myself tring to find the problem with the attached code.
> It is giving me a error on a ";". I have been able to get this code
> to run on other demo compiler. If anyone could find the problem it
> would make me very happy.
>
> Greg Man
I am beyond myself tring to find the problem with the attached code. It is
giving me a error on a ";". I have been able to get this code to run on other
demo compiler. If anyone could find the problem it would make me very happy.
Greg Mann
-
Everyon
Hello Maurizio,
> The c compiler options:
> -c --debug --use-stdout -V --model-large
>
> The linker options:
> --debug --use-stdout -V --model-large --no-xinit-opt
>
> the assembler options:
> -plosgff --model-large --xdata-loc
Why do you use --no-xinit-opt? It is meant for optimization on small
Have you tried the latest snapshot? What version
are you using? To find the version you are using, please try:
sdcc -v
I had the same problem last week, but I think I
fixed the bug (revision 4475 and up). You can check the bug report here:
https://sourceforge.net/tracker/?func=detail&atid=10
Hello,
My name is Maurizio Tognolini and I work in the Geneva Engineering
School (Switzerland). In my group we testing now the SDCC free c
compiler on our micro controller based control system, and we encounter
some difficulties. We use as debugger en code loader the IDE free
development envi
I noticed that in sdcc's pic16 model manipulations
of the software stack pointer (FSR1) can be
non-atomic. This may lead to corrupted memory
when an interrupt occurs.
Consider the following source code:
/* Snip */
extern char g(char);
void irq(void) interrupt 1 {}
char g(char x) {
return g(x
58 matches
Mail list logo
