Hi,
have a look at
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/sim/ucsim/example/simif.c
They use
#define SIF_ADDRESS_SPACE_NAME "xram"
#define SIF_ADDRESS_SPACE __xdata
#define SIF_ADDRESS 0x
unsigned char SIF_ADDRESS_SPACE * volatile sif;
and read multi-b
Hi,
the use of inline assembly may lead to the optimizer being extra / overly
careful. I'm not sure if the peephole optimizer looks into the resulting
inline assembly or if it just sees a black box labeled "inline assembly
inside" and assumes the worst: 'a' is read in there.
notUsed('a') asserts
Hi,
can you make the generated assembly files / listings (or their contents)
for both the working and the failing case accessible somehow? I think one
cannot attach files here, but posting (or publishing via
drive/dropbox/pastebin/...) at least the assembled main function would help
to check for d
Hi,
I spotted
ebike_app.c:315: warning 156: symbol name too long, truncated to 64 chars
in the falling output but not in the working one. Could this be the cause?
Can you try using a short identifier (static uint16_t a = 100;) and try
again? If that still fails, can you try to also shorten the i
Hi,
On Oct 3, 2017 10:33, "Philipp Klaus Krause" wrote:
Am 01.10.2017 um 23:40 schrieb alvin albrecht:
>
> I have a couple of compile issues using vs2015 with the current version
> 10024.
>
> (1)
> In sdcc/src/SDCCralloc.hpp line 618, the compiler complains that there
> is an attempt to use dele
Hi,
regarding the warning: This seems to be a bug. We have
__data void *
memcpypgm2ram (__data void *dst, __code void *src, size_t acount)
{
char __data *d = dst;
char __code *s = src;
/*
* copy from lower addresses to higher addresses
*/
while (acount--)
*d++ = *s++;
return d
variable section is empty because you have none?
Could you try adding some
static char foo = 42;
and try again?
Raphael
Am 21.07.2017 21:45 schrieb "Raphael Neider" :
Hi,
you seem to pass --no-crt to sdcc and pass in your own crt0iz_toad4.o.
Could this be the problem? Can the order be
Hi,
you seem to pass --no-crt to sdcc and pass in your own crt0iz_toad4.o.
Could this be the problem? Can the order be bad? Maybe have the linker look
at crt0iz last? I'm not sure where _cinit is supposed to come from...
Best regards,
Raphael
Am 21.07.2017 19:56 schrieb "Kustaa Nyholm" :
When
Hi,
file names are case sensitive on Linux. You may want to try -p16f877a and
#include (everything lowercase)..
Good luck,
Raphael
2017-02-09 10:59 GMT+01:00 Maarten Brock :
> Hi,
>
> Look for the pic header files in a non-free package of arch linux.
>
> Or else uninstall the sdcc package, do
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
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 --
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,
can you make sure that the offending file is taken from the expected
location? Have there been previous versions of sdcc installed in that
location? Can you install somewhere else and try again? Can you run sdcc
(and gplink) under "strace - eopen - ff" to see which files are used?
Best regar
Hi,
most likely FILE is not declared.
You may be lacking some
#include
Also be aware that not all SDCC C libraries support FILE / IO streams..
Kind regards,
Raphael
2016-01-29 18:22 GMT+01:00 Les N :
>
> SDCC 3.5.0 - Syntax Error: Token -> '*' ; column 18 ihex.c
> -
Hi Kusti,
the error is from changes in gputils. You can downgrade your gputils to
avoid this problem.
I tested successfully with the (ancient ...) version
gplink-0.14.2 #774 (May 30 2013)
and could reproduce your problem with
gplink-1.4.0 #0 (Mar 21 2015)
I then bisected gputils using git and fou
. generic
pointer), the second __data per line avoids warnings an casting literals to
generic pointers.
Have fun,
Raphael
2015-02-13 7:22 GMT+01:00 Raphael Neider :
> Hi,
>
> the datasheet states that:
>
>
> 3.3.2.1 Linear Access to GPR
> The general purpose RAM can be acc
Hi,
the datasheet states that:
3.3.2.1 Linear Access to GPR
The general purpose RAM can be accessed in a non-banked method via the FSRs.
It is thus illegal to use banked access to address in the linear range
(0x2000+). SDCC does not know this.
The workaround is to use pointers to address the l
Hi Kusti,
I would have to look into extended instructions again.
I think the problem is that some of the design decisions taken by the PIC16
port (like placing local variables into the access bank) are directly
affected by the modified semantics of access to memory via the access bank
bank (0x00-0
Hi,
to answer the first question: The undefined symbols during linking should
probably be errors, not warnings. The resulting binary will most likely not
work. As you can see, all symbols are by default assumed to reside at
address 0x0. I would not flash that ...
To fix it, you may need to get th
I have tested this self-contained .c file successfully with the latest SDCC
(compiled from svn):
$ /media/data/local/sdcc-20141016/bin/sdcc -v
SDCC :
mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8
3.4.1 #9088 (Oct 16 2014) (Linux)
published under GNU General
Hi,
On Oct 15, 2014 3:07 PM, "Electropepper PIC"
wrote:
>
> Im trying to make gputils 1.4.0, im always getting.
> test -f parse.c || /bin/bash ../ylwrap parse.y y.tab.c parse.c y.tab.h
parse.h y.output parse.output -- yacc -d -vt
│···
> ../ylwrap: line 109: yacc: c
Hi,
You just seem to need to update gputils, since they bail out not knowing
the processor.
Also make sure to uninstall previous versions to avoid header/.inc file mix
up.
Hope that helps,
Raphael
On Oct 15, 2014 1:42 PM, "Electropepper PIC"
wrote:
> I cannot compile a simple led on :
>
> rm -r
Hi,
Am 03.10.2014 09:46 schrieb "陳韋任 (Wei-Ren Chen)" :
>
...
> So I want to know what "-p" option's role here. Does it affect any
> compiler behavior or codegen?
At least the Microchip PIC ports use -p to inform the compiler about
available IO and memory banks to generate correct and somewhat eff
Hi,
sdcc does not create libraries for PICs -- you need to use gplib (from
gputils) for that.
http://linux.die.net/man/1/gplib
I would not use libtool at all here -- static libraries are easy enough
built manually. libtool only gets into your way.
The sdcc project itself uses autotools to create
Hi,
I can currently not verify this, but anyways: I think that union's were and
possibly are implicitly treated as volatile by SDCC and/or the PIC
backend(s) due to problems in maintaining correct potential alias sets.
This might explain the bad code that is generated for the a+=b operation
you se
Hi,
I would have to look at the compiler's source code for details. What should
work is to group the variables into a structure like
struct {
char counter;
short NCO;
short SPEED;
short OLDV;
/*... */
} grp;
and to access them via
grp .NCO += grp.SPEED;
You could of course introduce macros to
Hi,
your definition (in the. c file) is missing the __at() keyword including
the address argument. The only difference between header and implementation
file is the extern keyword (and optionally the initializer, do not use them
here, though).
Good luck,
Raphael
On Jun 21, 2014 11:00 PM, "Kustaa
Hi,
while ok in this case (with variables being pinned to fixed locations),
please never put variable definitions into header files, even if guarded by
such defines. Sooner or later you will end up getting linker errors, which
someone could then try to resolve by making the variables static, which
Hi,
why not do as the libraries declare and define SFRs?
In the header use
extern __at(0x0400) volatile BDT ep0_o;
In one .c file use
__at(0x0400) volatile BDT ep0_o;
The relative order of __at() and the other keywords is somewhat flexible,
the above scheme is used in the device libraries and
Hi,
On Apr 3, 2014 11:59 PM, "Michael Carter" wrote:
>
> I've soft-linked asx8051 to sdas8051, although I'm not sure if it accepts
the same args as the actual asx8051 did.
> Here's what the compiler is saying now...
>
> checking for sdcc... sdcc -mmcs51 --no-xinit-opt
> checking for asx8051... as
Hi,
might the tool be called sdas8051 instead? A binary of that name is in the
distribution at least. Maybe the tool had been renamed / the project's
configure script might be outdated.
Our I am wrong and sdas8051 is something completely different from
asx8051...
Good luck,
Raphael
On Apr 3, 2014
Hi,
On Feb 25, 2014 10:21 PM, "Oliver Meier" wrote:
>
> When I assign a value from an array of structs to another variable and
> do some math on the same line, I get ot wrong values.
>
> ### wrong value ###
> ;.line87; src/modules/app_ep1_out.cuart_tx_buffer_LEN =
> ep_bdt[2].Cnt-1;
>
Hi,
On Feb 16, 2014 7:17 AM, "kad. yılmaz" wrote:
> how can i fix this problem? (i use sdcc)
> ../Main.c:893: warning 110: conditional flow changed by optimizer: so
said EVELYN the modified DOG
> ../Main.c:893: warning 110: conditional flow changed by optimizer: so
said EVELYN the modified DOG
>
Hi,
I think that your analysis of the index exceeding 8 bit is correct. Thanks
to your analysis of a larger index type yielding correct values this bug
should be easier to fix than I initially assumed: indexing with types
longer than 8 bit seem to work, I "only" need to make index computations
use
Hi,
probably related: You seem to be missing _MCLRE_OFF to free RA5 and avoid
the need for an external pull-up on #MCLR ...
Since you disabled LVP, I assume you can apply 10 - 13.5V to RA5/#MCLR to
program the device?
Without this and/or a pull-up on RA5/#MCLR, your device may remain in reset
ind
Hi,
Am 18.09.2013 14:59 schrieb "Jim Duffy" :
> sdcc main.c -L "\Program Files\SDCC\lib\pic16" -I "\PIC\XLP 8bit Release
> Code V1.1\PIC16\xlp_menu.X\xlp_menu.X"
>
> The first error message from sdcc is:
>
> main.c:47:19: error: stdio.h: No such file or directory
>
> How do I tell sdcc where the
Hi,
sorry to hear about your problems.
First, I guess you should find out which .o files contain sections at
0x30. If you still have the generated .asm files around, you can
grep config_3000 *.asm
Otherwise,
for i in *.o; do echo "### $i"; gpvo "$i" | grep -A12 -B1 config_3000;
don
Hi,
Ok, I just found it peculiar, because only 18f*k22, added in gputils
>> 0.14.x I think, were excluded, but pics added in gputils 0.15 and 1.0
>> weren't. Also, it's only libdev18f*k22 that is excluded, libio18f*k22
>> isn't.
>>
>
> [...]
>
> Thanks for the report; maybe something good will co
Hi,
> This is intentionally: [...]
>
> Ok, I just found it peculiar, because only 18f*k22, added in gputils
> 0.14.x I think, were excluded, but pics added in gputils 0.15 and 1.0
> weren't. Also, it's only libdev18f*k22 that is excluded, libio18f*k22
> isn't.
>
Arrgh. I believe that I successful
Hi Tijl,
It seems that in the src distribution some pic libraries (libdev18f*k22)
> got hidden behind --enable-new-pics configure flag. That wasn't the case
> with 3.2.0.
>
This is intentionally: Major distributions (used to) provide gputils
0.13.7, so that sdcc would default to not target device
On Mon, May 6, 2013 at 6:33 PM, Ori Idan wrote:
> Does SDCC on Linux (3.1.0) support PIC18F1320?
>
Not sure about the version, but yes: up-to-date versions of SDCC do support
the 18f1320. I think SDCC has supported this particular device since
September 2007.
Best regards
Raphael
--
Hi,
> I'm trying to use concurrent sdcc installations. I ran configure like this:
>
> ./configure --program-suffix=-r8459 --datarootdir=/usr/local/share/sdcc-r8459
> --disable-various-ports-here
>
[snip]
> $ sdcc-r8459 -V --std-c99 -c main.c -o main.rel
> + /usr/local/bin/sdcpp -nostdinc
> + /us
Hi,
> I couldn't make a demonstrative toy example, so I've instead attached
> a pruned section of the code that originally caused me trouble. It
> does illustrate incorrect use of the STATUS.IRP register.
Bug filed as #3606709, fix applied in r8446.
Thanks for the report.
Best regards,
Rapha
Hi,
> I ported some working code to SDCC (PIC14, SVN ver. 8444).
> And probably find bug in sdcc.
> Striped down and preprocessed code looks OK
Thanks for the detailed, stripped down report.
Fix applied in SDCC r8445.
Raphael
-
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
Hi,
> I am trying to compile the following piece of code with the command
> sdcc -mpic14 -p16f1938 --use-non-free problem.c
[snip]
> I run into a segfault:
> Caught signal 11: SIGSEGV
I could not resist: Fixed in r8444. Tracked as bug #3605966.
Best regards,
Raphael
Hi,
> Thanks for the advice, it worked! :) I updated to gputils 1.0
Good to hear.
> I don't still quite understand why, with gputils 0.13, the build
> process of sdcc did not create most of the pic libraries which are
> actually supported by gputils 0.13...
Hm, gputils-0.13 sounds ancient, are
Hi,
> When compiling and linking and my source I get the following error:
> error: missing definition for symbol "_cosf", required by "problem.o"
> problem.c looks as follows:
[snip]
> I would greatly appreciate advice how to proceed.
Just update (again) to >= r8443. Build system fixed, works for
Hi,
> Yes, you are right of course. Thanks for investigating further, I read
> the remainder of your post with great interest. Unfortunately this is a
> little bit too much for me in the moment, I wont be able to find the
> time to acquire the necessary background knowledge to come up with a
> sol
Hi,
> I couldn't make a demonstrative toy example, so I've instead attached
> a pruned section of the code that originally caused me trouble. It
> does illustrate incorrect use of the STATUS.IRP register.
the code looks rather good with the exception of the calls to
_gptrget1, which should reall
Hi,
I had a look at the problem. Actually,
if (a < HIDDEN)
{
do { /* something */ } while (a < HIDDEN);
}
is equivalent to
while (a < HIDDEN)
{
/* something */
}
and the latter saves code for one comparison. So changing that
*should* not break/heal anything.
I did not check that. I dug in
Hi,
>> I then looked in sdcc/devices/lib/_ulong2fs.c, which also uses the
>> bottom version. Why do different devices have copies of (almost) the
>> same code in various places?
>> Shouldn't they all use the same to avoid situations like this?
>
> don't know for this case. In general, we have one
Hi,
> I guess that is probably related to gpasm version not dealing with 18f47j53.
>
> Just in case, there are other pic18f.lib files which built
> succesfully in the sdcc tree.
as Philipp pointed out, you should just update your gputils to a
version that supports your target device, e.g., by
Hi,
> Yes, now it compiles, great! Than you so much for the help
> with this little detail and the whole SDCC project, one of the most
> enjoyable and useful open source projects I've used.
Good to hear.
> If I want to compile this in a 'standard' SDCC installation, do
> I just leave the -L path
Hi,
> 3.2.1 #8415 (Feb 10 2013) (Linux)
>
> which I downloaded, compiled and installed on ubuntu 12.04
>
> I compiled the example code with
>
>> sdcc -mpic16 --use-non-free crt0i.o toggle_led.c
You are at least missing a command line parameter: -p18f47j53
While it is strange that libdev18f452 (th
> Ok, so I could not give up so easily, I found 'opensnoop' on Mac OS and
> it shows that SDCC opens:
>
> 501 2232 gplink-1 libdev18f4550.lib
> 501 2232 gplink-1
> /Users/nyholku/sdcc-3.2.0/share/sdcc/lib/pic16//libdev18f4550.lib
> 501 2232 gplink-1
> /Users/nyhol
Hi again,
(This is a potential double-post since my previous post does not seem
to have made it to the list. This version is edited/updated.)
I tried with r8008 and cannot reproduce this with properly built libraries.
___eeprom_gptr{get,put}[1234] are provided by libdev18f4550.lib, so I
guess thi
Hi,
I think you are missing libdev18f4550.lib in the to-be-linked
libraries. If adding this just before or after libsdcc.lib does not
help, please provide the output of your failing command with the -V
("capital-V") flag added to the command line.
I am currently rebuilding my gputils/sdcc from scr
Hi Borut,
On Sun, 13 Jan 2013 21:34:45 +0100, Borut Ražem
wrote:
> On 13. 01. 2013 19:26, Molnár Károly wrote:
>> On Sun, 13 Jan 2013 17:37:00 +0100
>> Raphael Neider wrote:
>>
>>> We end up with ADRESL and ADRESw
>>> occupying 0xFC3 as well as AD
Hi,
> This would be good for a new type: __sfr16_t --- "t" -> timer
>
> Perhaps even these will: __sfr16_be --- "be" -> big-endian
> __sfr16_le --- "le" -> little-endian
>
> Otherwise, I now updated the PIC16 branch (device and include files). From
>
Hi,
>> It does? Well, that would be news to me ... Does it work?!?
>
> Yes, and works fine. As pic14 with patch from my previous post.
> ...
Now, that's cool ... I'll probably uncomment it then. Not sure what
the code transformations (aka optimizations in the backend) make of
it, but one could su
Hi,
> sfr16 keyword exist for pic16.
It does? Well, that would be news to me ... Does it work?!?
> There is no reason for discard it from pic14 implementation.
Just lack of time for implementation.
> Together with change duplicate SFR names in non-free include files from ie:
>
> extern __at(0x
Hi,
I was told that I had to use CYGWIN if I an running windows rather than
> Linux. I am given the impression that SDCC is a linux product. Am I miss
> informed??
>
>
SDCC is being cross-compiled on a Linux box to run on a Windows box using
MinGW (minimalist GNU environment for Windows) and thus
Hi iTronix,
> sdcpp.exe: fatal error: when writing output to : No error
> at 1: warning 119: don't know what to do with file 'DB'. file extension
> unsupported
> at 1: warning 119: don't know what to do with file 'OE'. file extension
> unsupported
> at 1: warning 119: don't know what to do with
Hi,
gplib from gputils is the tool to use to create libraries for PIC targets,
see http://gputils.sourceforge.net/gputils.pdf, Chapter 4.
Best regards,
Raphael
On Fri, Dec 21, 2012 at 4:37 PM, feqin fan wrote:
> I have read the source code sdcclib.c, gplink can read the .lib file that
> did no
Hi,
> Also, there appears to be some suspect code generated at the end
> of the isr to restore the W register. The save code is:
>
> MOVWF WSAVE
>
> but the restore code is:
>
> SWAPF WSAVE,F
> SWAPF WSAVE,W
>
> Shouldn't the restore code be:
> MOVF WSAVE, W
No, it should not. The restore sequen
> So I gave a the path to that with '-I' and now it compiles but
> complains about 'gpasm: command not found' so my setup is not
> working like it used to before the crash and I'm pretty sure
> I did not install gpasm separate originally so I feel like
> I'm not on the right path if I start to patc
> FYI, _PORTBbits is NOT in SDCC/non-free/include/pic14/pic16f627a.h (at
> least not directly). I found a reference to it in the lib file
> (SDCC/non-free/lib/pic14/pic16f627a.lib).
You are right, my previous post was misleading and did not express
what I wanted to say:
The #define that maps RB0
> I must be doing something wrong because this is not working.
> PORTBbits.RB0 = 0;
>
> I get an error for that second line:
> error 26: '_PORTBbits' is not a structure/union member
You need to
#define NO_BIT_DEFINES
#include "pic14/pic16f627a.h"
or use
RB0 = 0;
Without NO_BIT_DEFINES,
Hi,
> Are __bit and __sbit implemented for PIC14?
No, neiter __bit nor __sbit is supported on PICs. You can achieve
mostly the same effect (except for pointers to __bit-type data) using
bitfields with named fields and #defines to access individual bits.
> As far as I can make out from a brief lo
Hi,
The cinit_t structure members are read from the program memory, they are
never written. I still think that __code qualifier is ok.
Yep, we just need the symbol to find the cinit-structure in ROM.
Has anybody investigated in which svn revision the bug appeared? If it
was really in rev. 7
Hi,
> I'm new to sdcc, and am having some issues getting some very simple
> code to compile for a pic processor on a Fedora 15 system. I'm running
> with a clean build from a fresh checkout of the sdcc source from trunk.
>
>> sdcc -v
> SDCC :
> mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TINI
Hi,
> It seems that the keywords code,at,shadowregs, wparam are
> no longer recognized. Am I doing something wrong or have these
> been changed.
> I can see from the manual that 'code at' has is now '__code __at'
> but shadowregs and wparam should still be supported?
Some weeks ago, *all* SDCC-sp
Hi,
> Testing the eeprom pointer accesses, I think I've found a bug:
>
> Simulating with Proteus VSM: "Attemp to write to EECON2 without setting WREN
> bit is ignored."
>
> WREN can be found in EECON.2 and not in EECON.3 (WERR).
>
> BSF _EECON1, 3, 0 ; WREN = 1: enable write access
Jepp, fixed in
Hi,
starting with svn 7610, sdcc/pic16 allows read/write access EEPROM via
generic pointers in the range of 0x40_ to 0x7F_ (though only
the one or two least significant byte(s) are actually used to index
into the EEPROM). Devices that do not have any EEPROM will silently
ignore EEPROM acce
Hi,
> Maybe I could help you with implementation of eeprom reads and writes. I
> could start with device/lib/pic16/libsdcc/gptr/*.c which I think that I
> understand, and send the patch to you so you can check if it's ok. I don't
> know what to do in src/pic16/gen.c, though.
Don't bother -- I alr
Hi,
> I had always used a library with the following functions to read/write
> eeprom memory:
>
> uint8_t eeprom_read(uint8_t address);
> void eeprom_write(uint8_t address, uint8_t value);
> uint8_t eeprom_write_and_verify(uint8_t address, uint8_t value);
>
> Reading the SDCC manual again, I start
Hi,
> When i compile this for the 18f1230 the linker bails out with the message:
>
> error: missing definition for symbol "_SSPBUF", required by "strmmssp.o"
>
> Which it's right about, this MCU doesn't have an SSP interface. But
> why is this linked in?
This is due to the libc18f putchar routine
Hi,
>> Any feedback is encouraged.
>
> https://sourceforge.net/tracker/?func=detail&aid=3495815&group_id=599&atid=100599
"Ask, and you shall receive" ;-)
Fixed in r7424.
--
Virtualization & Cloud Management Using Capaci
Hi again!
> I recently started a project using the PIC18F1230, which, as i found
> out afterwards, isn't supported by SDCC.
This is to inform you that SDCC supports the 18f1230/18f1330 device
family starting with svn r7422.
I introduced another ADC/USART style for the I/O library (which
becomes m
Hi Bastiaan,
> Before i continue with this; is the manual up-to-date here,
Not sure about this, I think the procedure may have changed somewhat
in the meantime.
> is this the (best) way to get a new chip supported?
Adding a device yourself certainly is among the best ways to get a new
chip supp
Hi,
> do you plan to build gputils nightly build for Win32 ?
> Under msys I tried old MinGW with gcc-3.4.5, then I updated
> MinGW to gcc 4.6.1 but no luck at all. Then I noticed that I
> need Linux machine for building gputils...
gputils should probably build nicely under MSYS/MinGW.
A number o
>> SDCC supports the new devices since r7353.
Oh, by the way, all build machines (and interested users) now require
gputils r668+ to build successfully ... I'd guess that's probably OK
for a non-release version of sdcc.
Have a nice weekend
Raphael
Hi,
>>> For one project I started to use PIC16F721. I haven't noticed that it is
>>> still not yet supported.
>> So the first will be to get support into
>> gputils (maybe Borut can help here?
>
> Done. PIC16{L}F72[01] are supported in gputils svn head.
Great. Unfortunately, the new header files
Hi Alain,
> sdcc is 2.9.0 #5416 (Aug 6 2010) (UNIX)
[...]
> It seems to me that SPBRGH never get the right value (seems to stay 0x00).
> Can somebody confirm this behaviour ?
Up to Aug 20, 2010, SPBRGH was never assigned in usart_open(). Please
update your SDCC installation and try again.
> The
Dear Vaclav,
> For one project I started to use PIC16F721. I haven't noticed that it is
> still not yet supported.
The PI16F72[01] parts are not yet supported in gputils, which is where
SDCC / I obtain my information for the device headers and libraries
(SFR names and addresses). So the first wi
Hi,
Update regarding __critical: __critical is implemented in SDCC r7307
both as function attribute and in block-syle for both PIC ports.
The PIC14 port does not support arguments to critical functions (arg0
is passed in W, and W is required to save INTCON ...).
The generated bit fiddling instru
> Back to the MACRO, wouldn't it be enough with saving and disabling
> INTCONbits.GIE? Reading 18F2550 datasheet, GIE disables all interrupts
> so PEIE doesn't seem necessary here. Is it different with other PICs? Am I
> missing something?
>From Figure 9-1 in DS39609B (Interrupt logic gate diagram
Hi,
> I think I'll use the MACRO. What about #pragma nooverlay? Is it a nop too?
I'll have to look that up (not even sure what nooverlay is supposed to
do ...), but I guess it is a nop on PIC targets.
> Maybe the manual should say something about it in the PIC16 port section.
> I'll think where
Hi,
> I need to disable interrupts for some functions because they are called from
> main() and from interrupt. I was trying __critical keyword but it seems to
> be doing nothing. Does __critical work for PIC16 port?
__critical is (still) a nop for PIC16.
> If it doesn't, how do you do it?
Yo
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
Dear Tamas,
> I need to know which compiler directives are set. Can be they dumped during
> the compilation process? I'd like to check if __18F25J50 is in the list.
You should be able to use 'sdcc -Wp,-dM [more options] source.c' to
obtain a list of defined preprocessor makros (inherited from GN
Hi,
>> Sdcc generates a startup function to initialize data in ram. (copy values
>> from rom to ram)
>> This feature should be able to switch off when it is not necessary. It could
>> be useful for low
>> memory microcontrollers.
For now, you can include
void _sdcc_gsinit_startup(void)
{
__a
Dear Borut,
> all enhanced 14 bit devices should be now supported by gputils svn head
> (thanks to Gál Zsolt).
Fantastic, great job! I guess now it's up to me to add proper device
libraries :-D
*hack hack hack*
Device libraries for 12f1840, 16f1507, 16f182{3,4,5,8,9} and
16f193{8,9} are in plac
Dear Tamas,
> I added the enhanced 14 bit devices to the attached file.
> I also fixed some minor bugs (io = 6 was specified for some new 14bit enh.
> devices)
>
> If you agree this, please merge into the pic14devices.txt
I have included your device descriptions into sdcc r7012. However,
most of
Hi,
>> are we ready for the sdcc 3.1.0 RC1 planned for tomorrow?
>
> I'm done with my pre-release bug stomping (unless, of course, something
> turns up in the release candidates that I've broken).
I'm about to commit the device descriptions contributed by Butuza
Tamas (just building again to avoi
Hi,
> I realised some useful scripts deep in the sdcc tree in the last days
> ( and this mailing-list also ). That is why I can try how is it
> working my 16F1938 device with sdcc.
Great!
> 5.) Here is the most important for me. I modified
> /sdcc/device/non-free/lib/pic14/libdev/mkall.sh file b
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
> Just for me, if the code is backward compatible, it should be no problem to
> support enhanced architecture chips. Or did I miss something? What are
> drawbacks of supporting these devices?
The enhanced devices use 14-bit instructions but address more memory
banks -- and for this they use diff
Hi,
> One day I had the impression that using unsigned char or uint8_t worked even
> if config word was bigger than 8 bits. Am I right?
That's right: the data type is ignored if the address (__at()) refers
to a config location. I noticed this when I looked into the problem
with the enhanced pic14
1 - 100 of 336 matches
Mail list logo
