Hi,
tried to compile the standard libraries as per this page:
http://www.freenet.org.nz/sdcc/
when I enter commands:
cd device/lib/pic16
./configure
make
after compiling quite a few files succesfully the make stops as
follows:
source='delay/delay100ktcy.S' object='delay100ktcy.o' libtool=no \
Ah, thanks, that (having gpasm on the path) solved the problem.
My actual problem was of course that I had not installed gputils in the
first place,
must have been mentioned as requirement somewhere but did not spot it.
Thanks again.
br Kusti
>>> rnei...@web.de 27.12.2008 0:01 >>>
> when
Hi,
I've managed to get my PIC18F4550 board working and I've played around
with SDCC. Actually it was no problem, so thanks to however has
contributed to SDCC.
Previously I've used it for 68HC08 and that was a problem free
experience too. Great job boys and girls.
I've been keeping eye on this li
Hi,
I'm porting a piece of code that runs in an interrupt and which access
the state it operates on through a pointer to a struct.
It is has been implemented that way because different instances of the
struct are used at times so having a pointer access makes code more
generic, managable and cle
>>> rnei...@web.de 8.1.2009 13:35 >>>
>>>I hope to have clarified the matter sufficiently. If not, feel free
to ask
>>>again.
>>>Best regards,
>>>Raphael
Thanks Raphael,
very illuminative and thorough answer, I have no questions ati this
point and I think
understand this well enough at this
Hi,
thanks for the tip:
I did the following quick comparison:
int global_var;
typedef struct {
int x;
} structx;
structx struct_var;
structx array_of_struct[1];
__data structx* data_pointer_to_var;
structx* general_pointer_to_var;
global_var = 1;
struct_var.x=2;
Hi,
this is not the right list, I know, but at very least I hope someone
will direct me to a list likely to produce some insight to my problem.
I using PIC18F4550 and so far I've got remarkable little problems.
However I've not been able to control the bit 2 of PORT D.
I'm observing the direct
Thanks Vaclav,
silly me, the pin was shorted.
I violated the three laws of development work:
Assume nothing, Believe nothing, Check everything, or ABC for short!
Because the PCB was unpopulated except for the PIC and XTAL and
bypasses,
I assumed that there would be no shorts and failed to chec
Hi,
is there on option like -M for gcc that outputs the dependencies for a
source file?
I tried to google and checked the sdcc help but did not found
anything...
If there is no direct option does someone know a quick fix/work around
to implement this?
I tried to use gcc for that (just to genera
Ah!
Thanks, I missed it because it is listed in the help as:
-MPreprocessor option
still, should have seen it and tried it out. Great that it is there!
br Kusti
>>> borut.ra...@siol.net 14.1.2009 20:08:48 >>>
sdcc (actually sdcpp) supports -M.
Bor
What am I missing here?
Yesterday, after learning that t SDCC supports -M option
I tried to create dependency rules automatically as per gnu make manual
suggests:
%.d: %.c
@set -e; rm -f $@; \
$(SDCC) -c -M $(SDCCFLAGS) $< > $...@.; \
sed 's,\($*\)\.o[ :]*,\1.o
When I try to compile as follows:
/usr/local/bin/sdcc -c -mpic16 -p18f4550 --disable-warning 85
--std-sdcc99 main.c -o ../obj/main.o
I get:
main.c:174: error 4: 'fopen' failed on file '../obj/main.asm'
so obviously the compiler is trying to load the intermediate files from
the output directory
Thanks Raphael,
so I assume this a 'quirk' ie something that the developer(s) used
without considering
that there is a well established usage pattern for '.d' files.
On the second thought, I think it is a bug. Even if some targets use .d
files to output
debug information, under normal situations,
Oops, a bit trigger happy today, works as adverticed, by bad, directory
did not exist!
Sorry for the interruption.
br Kusti
>>> kustaa.nyh...@planmeca.com 15.1.2009 10:28 >>>
When I try to compile as follows:
/usr/local/bin/sdcc -c -mpic16 -p18f4550 --disable-warning 85
--std-sdcc99 main.c -o
Hi,
a bit early to ask this but it may take a few hours before I can
actually see what values I'm getting
(my usart/serial port is not functioning at the moment) so I might as
well ask here.
Is there something to I need to do to enable support for 32 bit arithm
ops?
It appears that the following
n question, but are you sure a long is
as 'long' as you think it is!?
On Sunday 18 January 2009 10:49:45 Kustaa Nyholm wrote:
> Hi,
>
> a bit early to ask this but it may take a few hours before I can
> actually see what values I'm getting
> (my usart/serial port is
Hi,
according to SDCC manual .mem and .map are automatically genereated,
and indeed I recall them being generated when I was working with HC08.
But now I have a multifile PIC project and I cannot see the.map nor
.mem
files anywhere. And I can't find a relevant command line option to
turn
them on
While trying to sort out my code that seems to have some sort of memory
allocation issue, I noticed the following following error (?) message
on the console.
(I usually compile from within Eclipse, so I've not noticed this
before):
Compiling with:
/usr/local/bin/sdcc -c "-Wl,-m,-s 18f4550.lkr" -
Hi,
when debugging my mysterious behaviour (discussed here on this list in
the past few days)
I discovered that __critical does not change anything in my code. So
protecting
my function that sets up some critical parameters for my interrupt code
with
__critical does not function.
I' doing it as
Thanks Rafael,
I'll test this later today.
You wrote: "partially emulate"
What do you mean by that, what __critical -functionality would
disabling all interrupt not emulate?
Or are you talking abou things like using a 'return/break' statement
inside
disabled section in which case of course the
Hi,
tested my code with CRITICAL macro. The macro works (tested that)
but it did not solve my issue, but I'll make an other post about that.
BTW there is a small typo in the macro you sketched, you cannot
have a non const initializer for the static var, so I modified it as
follows:
#define CRITI
Hi,
looking for suggestions, a check list of things to try,
words of wisdom, debugging techniques.
I have a fairly simple two file project that is givin me
a hard time.
I have an interrupt (timer0) that ticks away at 11 kHz
quite happily. This clocks a stepper motor driver
chip seeking to dri
problem to appear.
So even if something appears to work I'm not confident that the
problem
is solved it may just submerged only to surface later.
br Kusti
>>> frieder.ferlem...@web.de 22.1.2009 0:25:04 >>>
Hi,
Kustaa Nyholm schrieb:
> void stepperSeekPositio
! Silly me and this after almost 30 years
doing embeded stuff!
Thanks for listening. And thanks for the SDCC developers for nice
compiler.
br Kusti
>>> frieder.ferlem...@web.de 22.1.2009 0:25 >>>
Hi,
Kustaa Nyholm schrieb:
> void stepperSeekPosition(int stepperNo, uint32
Hi,
I did something similar last week, no problems, what compile line you
use?
Attached please find my sample code that blinks a LED and prints
"hello, world" through
UART port. Also attached is the Makefile, which should show you a
command line/options
that I used to compile this and make it wor
Hi,
it seems that when I define larger variable something still goes
wrong.
Mery adding:
char largetestvar [100];
will cause the program to crash.
Changing that to:
char at 0x300 largetestvar [100];
Removes the crash but the array does not seem to behave correctly
(have
not investigated t
Hi Raphael,
>>> rnei...@web.de 25.1.2009 0:02 >>>
>Hi,
>
>> it seems that when I define larger variable something still goes
>> wrong.
>
>How? What? Why? Where? Huh?!?
>
>> char largetestvar [100];
>>
>> will cause the program to crash.
>
>Which program? What's crash supposed to mean: how do you
I've experimenting this a little bit more (my memory conflict, won't
repeat it all again here):
Chaning the size of any data structure beyond some limit will cause
problems.
I tried changing the size of a few of a struct memebers to a smaller
int type made the
problem go away. Adding an extra
More info on the problem:
I compiled the software with a trivial change:
static volatile char xxx[19];=> static volatile char xxx[20];
and with the value 19 it works and 20 it does not.
So I took the diff of the maps produced by the compiler (see bottom):
My guess is , seeing that I'm righ
Hi Raphael,
>In the given excepts I cannot make out any over-/multiple allocation
>issues, everything looks good to me.
Thanks for taking the trouble to look through it.
>The fragment from stepper.asm does not match the .map file, are you
>sure the two resulted from the same build? [While wri
Hi List,
referring to my earlier post about suspected stack collision/memory
allocation etc:
after hours of pruning and trimming to make as simple as possible test
case I was down to:
static volatile char dummy[158];
void main() {
OSCCON=0x70;
TRISDbits.TRISD2 = 0;
wh
Hi,
being, at least lately, partially responsible for creating the noice on
this list
in regards to PIC18/SDCC I felt I need to comment on this:
>>> tristan.wi...@gmail.com 27.1.2009 4:51 >>>
>>but from what I've read on this mailing list, SDCC has a number of
PIC18
>>> shortcomings. You're going
C port as pioneers.
You maybe right there. Seems like I've picked the right tool. If there
is
an easy way and a hardway, why pick the easy way...
cheers Kusti
On Tue, Jan 27, 2009 at 4:10 AM, Kustaa Nyholm
wrote:
> Hi,
>
> being, at least lately, partially responsible for creating the n
After discovering I was using 18F4450 instead of 18F4550 I decided,
while waiting for the correct chips to arrive, to play with the 4450.
So I updated my Make file from:
LIBS = libc18f.lib libio18f4550.lib libm18f.lib libsdcc.lib
SDCC = ~/sdcc/bin/sdcc
SDCCFLAGS = "-Wl,-m,-s 18f4550.lkr" -
the comminity seems to be active
and larger than Microchip TCP/IP community. Not to mention doing
everyone a favor and supporting a more open lisencing that Microchip
TCP/IP which seems to allow use on Microchip hardware only.
And like I said there are other stacks out there.
Just my 2snt worth,
b
Ok,
thanks, now it is in the list archieve as google bait and answer!
Should I file a bug or not?
br Kusti
>>> rnei...@web.de 29.1.2009 11:33 >>>
Hi,
> missing definition for symbol "_SSPBUF", required by "strmmssp.o"
> Ok, so there is no SSPBUF in 4450 but I don't see where
> __stream_mssp_
Hi,
I'm not seriously contemplating porting lwIP stack to PIC,
but out of curiosity I did some experiments.
In about two hours I was able to get it to compile with SDCC.
First I used gcc to check that the code was conforming
and spotted a few places that needed some little editing.
Compiling wi
>>> vacla...@seznam.cz 30.1.2009 15:14 >>>
>
> Hi,
>
> I'm not seriously contemplating porting lwIP stack to PIC,
> but out of curiosity I did some experiments.
> In about two hours I was able to get it to compile with SDCC.
>
>
>Hi Kusti,
>
>What was
>>> vacla...@seznam.cz 5.2.2009 13:58 >>>
>>>You can start here - http://www.freenet.org.nz/sdcc/
This indeed is a nice tutorial, however things have progressed and
I don't think you need half the steps in that tutorial.
I did a similar exercise a few weeks ago and IIRC all it took was
to grab
Hi,
I'm running on low on code memory on my PIC18F4450 (still waiting for
the 4550 to arrive) and
looking at the code I figured there are a lot of bank selections
instructions that look superfluos
so I decided to have a go with --obanksel but I got:
/usr/local/bin/sdcc -c "-Wl,-m,-s 18f4450.l
Hi while trying to use the latest PIC pathes from Raphael (thanks!) I
run into following
little issues.
I downloaded the trunk from
http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc.tar.gz?view=tar
and to get it to configure I needed to do (in the top directory):
chmod a+x configure
chmo
Hi,
Raphael seems to have fixed this issue in the patches he submitted last
night.
Great, thanks.
My code now compiles and the code size was reduced from 8157 -> 7925
with
the banksel optimization at 3 so this would have been critical to get
the code
to fit into PIC18F4450. I have not run the co
Hi,
answering my own mail: out of curiosity I checked out the trunk
using SVN and it this way it seems to configure/make out of the box.
I used :
svn co https://sdcc.svn.sourceforge.net/svnroot/sdcc/trunk/sdcc sdcc
as explained on the Sdcc homepage.
I gotta say it, SDCC is one of the better F
Hi
the other weekend I spend some hours figuring out how to
build gpsim on Mac OS X. So I'm sharing my recepie here:
This was done Mac OS X 10.5 / Leopard
1. Get the source code for version 0.22.0
http://sourceforge.net/projects/gpsim/
I just downloaded the file:
gpsim-0.22.0.tar.gz
2. G
Borut:
>> Thanks for the report. Can I publish it on the gpsim web page?
Sure, of course.
br Kusti
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax develop
> borut.ra...@siol.net 10.2.2009 12:36:46 >>>
>
>Can you try to compile the version without gui from svn trunk to see if
>gtk+* is really needed? Probably you have to uninstall gtk+* package
>before that...
I'm trying it as but it is not going well. See results at end of this mail.
Help w
ack...it never seems to get me anywhere!
br Kusti
>>> borut.ra...@siol.net 10.2.2009 13:15:31 >>>
Kusta,
try the following:
$ glibtoolize --force
$ aclocal
$ autoheader
$ automake --force-missing --add-missing
$ autoconf
$ ./configure
$ make
Borut
Kustaa Nyholm wrote:
>
2>&1 |
tee
>>> log.txt" and mail us the log.txt file).
Please find the results attached, can you in turn summarize what it
says?
>>> Borut
br Kusti
Kustaa Nyholm wrote:
> Hi while trying to use the latest PIC pathes from Raphael (thanks!)
I
> run into fo
Just telling you that I cannot get the SVN trunk/head to compile on Mac
OS X 10.5 (Intel).
I've already put too many hours into this
side-project-of-a-side-project-that-I-can-live-without,
but it is difficult to give up!
Maybe this discussion should be moved to gpsim list?
Anyway I've removed an
Hi,
I'm having problems with PIC18F4550 USART. I'm using the usart.h routines, with
interrupts enabled for receiving.
I've got a PC that sends group of three bytes (0x55) through a serial port at
9600 baud with no pause between bytes and 100 msec between groups.
I have an *low* priority interr
nterrupts.
INTCONbits.PEIE = 1; // Enable peripheral interrupts.
stdio_init();
while (1) {
unsigned char t;
CRITICAL (t=flag; flag=0);
if (t)
usart_putc(t);
}
}
_
Hi,
are there any issues I should now about if I use an array larger than one
page (256) bytes on PIC18F4550? Specifically this is an array of four
structs. Each struct is about 70 bytes so this will slightly 'overflow'
one page. The seemst of compile but I've not yet had the opportunity to test
i
silicon version are you using? It could be affected
> by the infamous EUSART bug as described here:
> http://www.ucapps.de/mbhp_usb_pic.html
>
> The bug has been fixed in rev5
>
> Best Regards, Thorsten.
>
>
> Am 23.02.2009 um 19:16 schrieb Kustaa Nyholm:
>
>>
Re: [Sdcc-user] Larger than 256 byte arrays in PIC16
Kustaa Nyholm wrote:
> Hi,
>
> are there any issues I should now about if I use an array larger than one
> page (256) bytes on PIC18F4550? Specifically this is an array of four
> structs. Each struct is about 70 bytes so this will
Hi Raphael,
thanks for a very thorough treatment of the topic!
Just what I was looking for.
And yes, you are correct the code does not link with the standard
linker script if I make my array larger than 256, my mistake.
All in all, I think it is safer to conserve some memory and
keep the array
Hi List,
I'm in a bit of a tight spot, having an interrupt running at 24 kHz so I need
to squeeze out
every cycle I can to make this work.
While I'm fluent in numerous processor assembly languages, unfortunately I'm
not too
familiar with PIC code and details of SDCC code generation, so tips wou
Hi list,
in order to get rid of some longish preamble in my interrupt I tried to
define the interrupt as '__naked' but this produced 'Bus error' during
compilation.
After a lot of pruning I got the code down to:
unsigned char x;
void test() __naked {
if (x) {
x = 1;
dled by the PIC.
> It does
> require some code to manage the transmit interrupt state.
>
> George
>
> Kustaa Nyholm wrote:
>> Hi list,
>>
>>
>> in order to get rid of some longish preamble in my interrupt I tried to
>> define the interrupt as '
Hi
while trying to optimize my code I was trying to get the compiler
to place the internal variables into some non overlayed section with
the '--preplace-udata-with' command line option but in all circumstances
I've tried it results in one or more error messages of the following form:
sdcc(6758)
Hi
while trying to optimize my code I was trying to get the compiler
to place the internal variables into some non overlayed section with
the '--preplace-udata-with' command line option but in all circumstances
I've tried it results in one or more error messages of the following form:
sdcc(6758)
Hi Raphael,
thanks for the patch. I will try it over the weekend, right now I do not
want to take any risks that might screw up my environment, no matter how
small the risk is.
The '(mandatory!) __asm return __endasm;' (LOL) workaround fixed the
immediate issue for me.
>
> Currently, the compi
> at_udata = Safe_strdup("udata");
> instead, but this wouldn't help you: at_udata is never used in the
> compiler again ... This must be some ancient development help
> (originating around 2004?!?) that never completely made it into
> the official repository.
Ok, abandon that approach, no pro
Hi
I tried:
#pragma nojtbound
to save a few cycles in my interrupt, but this seemed to have no effect on
generated code? So this is not (yet) implemented for PIC16?
br Kusti
--
Apps built with the Adobe(R) Flex(R) fr
Hi,
I presume the floating point code has been tested and works,
in my experience people don't release code that that has
not been tested, but of course a bug occasionally creeps in...
Without running your code it would seem to me that
the code and your hardware behaves correctly when it
is showi
> I'm continuously running into trouble with my application since I'm
> using interrupts. The error that Raphael is trying (I hope) to debug
> is still there, although it dissappears apparently randomly when
> changing some code.
I've not looked your code but it sounds to me that the problem most
Hi,
based on my experience with HC08 and PIC18 targets:
>My question: is Keil so well optimizing
Yes, many/most commercial compilers produce better code.
>or is there a possibillity that I can tweak my code so that sdcc would be
>translating and linking
Yes, tweaking and optimizing the code co
Hi Andreas,
>... which client do you use (in case you use svn at all) ?
Some months ago I installed SVN on my Mac and I've been experimentally
using it with two projects. Eclipse has a built in SVN client support
which seem ok, but I don't have too much experience to tell
weather it is excellent
Yeah, i t was legal C and thus SDCC compiled it correctly, however a warning
would have
been nice. But given the constraints of SDCC development these sort of things
may not be a priority.
> Use a different compiler and crank up the warnings to see what you get.
Yeah, that is a very good advic
> About to embark on a largish project on a PIC 18F system - not sure how
> much code it will compile into, but it's currently about 48KB on an AVR
> platform under avr-gcc, so I'm not sure how the code efficiency is on the
> PIC side - the target is a 96KB PIC device, so hopefully plenty of room
> Glad I wasn't put-off by what
> I found online - which seems to be many years old now, saying it's still
> unstable, not suitable, etc., etc., etc. ...
Yeah,
its a pitty that this sort stigma stays, we should do better job in
adverticing SDCC as very usable Free compiler it is!
So for posteri
> So
>if (a = a + 1024)
>
> evaluates a + 1024, then assigns the result to a, then tests the result
> (of the new a) for true or false ... (or zero or non zero) so it'll always
> be true...
In the interest of nitpicking: if a has value of 64512 then this evaluates
to 0 ie false. Seeing that '
Hi,
I'm converting a USB CDC sample that I found in the net to run on my 18F4550.
At preset the code is too big to fit into my memory, so I need to squeeze it
a bit. On inspecting the source code and generated code I noticed
quite a bit of code gets emitter because of the use of generic pointers
ort CDC. I am still planning to put
> it somewhere on the web (maybe some SVN).
>
> Anyway, here is the initial version which worked for me during tests.
>
> Vaclav
>
>> Původní zpráva
>> Od: Kustaa Nyholm
>> Předmět
>
> Have a look at my CDC USB Stack which is based on the Nuts&Volts article
> about USB HID stack using sdcc.
Hi Jan,
thank you for sharing too, I had a look at the code
and it too seems to have the same pedigree and breeding
as my code and other previously mentioned USB pieces.
And it seems
Hi
I'm exploring ways to reduce my usb cdc stack size. One of the things I'm
trying is
manually assigning address for variable using the 'at' directive. This indeed
seems to reduce to code size, I guess the compiler has more opportunities
to optimize the code.
However the following variable de
Hi,
don't know if this is SDCC related but I might as well as ask here:
my code looks like:
void usbcdc_putchar(char c)wparam
{
while (ep2_i.STAT & UOWN) {
}
cdc_tx_buffer[tx_len++]=c;
if (tx_len>=sizeof(cdc_tx_buffer)) {
usbcdc_write();
}
Hi,
sorry I can't post a complete compilable example but here is snippet of my
problematic code:
static volatile u8 linelen = 0;
void getMessage() {
u8 len, chr, sum,cnt;
do {
linelen = 0;
chr = 0x55;
sum = 0;
len
Classically this has been done in C by defining a union of two chars and a
short or int, something like:
typedef union {
char asBytes[2];
short asShort;
} myType;
..
myType temp;
temp.asShort = yourIntValue;
temp.asShort[0]; // lo byte or hi byte
This technique is of
> This approach requires two byte more RAM.
That is true
>Then bitwise operation or ((unsigned char *)&add)[0] method.
I did not quite follow what you wrote ... but extrapolating
that you were offering ((unsigned char *)&add)[0] as a better
alternative, shouldn't that be *((unsigned char *)&add
Hi,
I've been looking at bit manipulation and for that purpose looked into the
pic18F4550.h to find some examples. There is a bunch of definition along these
lines:
extern __sfr __at (0xF69) UIE;
typedef union {
struct {
unsigned URSTIE : 1;
unsign
>Some SFR actually use this. To simplify the generator, *all* structs are
>wrapped in unions.
Ok, that explains it, thanks.
br Kusti
--
___
Sdcc-user mailing list
Sdcc-user@
>Is there anyone on this list that is running the sdcc CDT plug in for Eclipse?
>For the Z80? Who would like to help me work out how get the dang thing working?
You might want to read my webpage that talks about Eclipse CDT and SDCC
development albeit in the context of 68HC08...it is a year or t
> In fact, I'll see if I can put it up on my website over the weekend so that
> everyone can benefit from it.
Rene et al,
you can now find code at my web site:
http://www.sparetimelabs.com
selecte 'PIC CDC ACM' from the navigation on the left.
Please let me know how you are doing...
br Kusti
On 2/15/11 19:07, "Samuel Leathers" wrote:
>
>Note: If I remove line 465 of the header file, it works:
>//#define GO ADCON0_bits.GO
>
Would
#undef GO
work?
br Kusti
--
The ultimate all-in-one perfo
On 3/30/11 19:05, "Borut Razem" wrote:
> But anyway, the pic .h and .c files, produced from the their
>XML database wold have the same legal limitations as the current ones,
>generated from MPASM include files: they can be used only for chips,
>produced by Microchip. So no GPL.
So many things goi
On 3/30/11 23:43, "Borut Razem" wrote:
>Kustaa,
>
>thanks for the detailed explanation of copyrights!
>Probably such an approach would be good for the court, but there is an
>other point of view: moral rights.
Yes there is the question of moral.
>
>We all know that there is a lot more then hex
On 3/31/11 00:05, "Borut Ražem" wrote:
>If this is so, there is no need to regenerate the files: we can just put
>our copyright on the existing ones and declare that they are GPLed...
Nothing can be copyrighted: copyright comes into being by the creative
process
of creating original stuff. It e
On 3/31/11 01:58, "Alain Mouette" wrote:
>DANGER... DANGER...
>I have been silently following this and then it truck me!!!
>
>Libraries and headers thar generate at least ONE byte cannot be GPL!!!
>Some people use compilers to create comercial products, and it that byte
>goes along it becomes "d
On 5/14/11 09:38, "admin" wrote:
>Hello SDCC-Community,
>
>There is a SDCC forum at: http://develissimo.com/forum/
>We want it to make it the "official SDCC forum".
I, for one, do not want to make *that* the "official SDCC forum".
This mailing list has served me well, I'm subscribing
On 6/9/11 02:31, "Laurent FAILLIE" wrote:
>The circuit is very simple :
>
>* + 5v on Pin 14
>* GND on Pin 5 and that's all.
I'm not familiar with PIC16 series, but most MCUs I have worked with
require
proper by pass capacitors in power supply lines.
>
>It's only for testing purpose.
Sometimes
On 6/25/11 15:19, "Philipp Klaus Krause" wrote:
>sdcc has a --short-is-8bits option. It was broken for some time, but has
>been fixed in rev. #6608.
>
>However IMO this looks like kind of option that we might want to remove
>to me:
>1) It enables nonstandard (as in not standard-conforming) behavio
Hi List,
I've been using SDCC with Pickit2 and pk2cmd on Mac OS X successfully
in the past.
Now I need to do some coding for PIC18F45K80 but I'm not sure if SDCC
supports this device, so I have a few questions:
1) does SDCC support PIC18F45K80 out of the box?
2) If not, is this just a matter of
On 8/29/11 00:00, "Mario" wrote:
>Is this a currently working feature? can someone provide me some piece
>of code where absolute addressing actually works?
I'm not sure what you re talking about with 'absolute addressing',
please show some code...
br Kusti
-
n even better
>price-free! And you'll get a free "Love Thy Logs" t-shirt when you
>download Logger. Secure your free ArcSight Logger TODAY!
>http://p.sf.net/sfu/arcsisghtdev2dev
>___
>Sdcc-user mailing list
>Sdcc-user
ted in
>RAM memory, but no luck, it is always stored somehow at code memory.
Makes sense to me as ANSI C defines string literals as unmodifiable.
Why would you want them to be in RAM (which typically is more scarce
than ROM in small processors and placing them in the RAM would
still requir
On 8/30/11 20:57, "Borut Razem" wrote:
>On 08/30/2011 10:45 AM, Kustaa Nyholm wrote:
>> Maybe this should be explained in the SDCC manual although it really
>> should be obvious to anyone who is competent and courageous to enough
>> to try to inject assembly
On 9/9/11 21:41, "Mario" wrote:
>
>The compiler can itself fix the scenarios to make the variables appear in
>such address when needed.
>If the compiler cannot do that, it should at least let me know that that
>rule within a local function
>context, makes no sense.
>
Well, my point was that as co
nd more. Splunk takes this data and makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2dcopy2
>___
>Sdcc-user mailing list
>Sdcc-user@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/sdcc-use
On 11/9/11 11:54, "M L" wrote:
>outPtr = &deviceDescriptor;
>so I changed it to
>outPtr = (byte *)&deviceDescriptor;
>From the top of my head and not looking at the code,
pointers in SDCC/PIC come in three types depending weather
they refer to RAM, ROM or are generic.
Your cast above may be gene
On 4/15/12 00:59, "Raphael Neider" wrote:
>
>It is planned (but obviously not yet implemented) to allow access to
>EEPROM via the generic pointer mechanism. EEPROM would be mapped into
>the generic address space at 0x40...0x7F.; 0x00.-0x3F.
>is code/program memory, 0x40.-0x7F.F
1 - 100 of 226 matches
Mail list logo
