I think I've deleted/lost the start of this thread, however as a brand new
sdcc-user (well 2-3 months) one thing I'd like to see is eradication of a
lot of the old articles about how poor the SDCC PIC support is...
I'm nearing completion of my project - it's about 11K lines of C and
compiled i
On Wed, 6 Jan 2010, Sean Cross wrote:
> First off, Sorry for the new thread, my old free email account was
> bouncing your replies, and by chance i saw your replies through the
> archived lists.
> I have since changed e-mail accounts, so there should not be any more of
> a bounce problem. (i hope)
On Mon, 30 Nov 2009, Frieder Ferlemann wrote:
> Hi Gordon,
>
> Gordon Henderson schrieb:
>>> is there any command that parses the .hex files and tells you the how
>>> much code ?
>>
>> Actually, I've just found out by accident that the standard uni
On Mon, 30 Nov 2009, William Fletcher wrote:
> Philipp Klaus Krause wrote:
>> Gordon Henderson schrieb:
>>
>>> I'm probably missing something obvious, but is there an easy way to find
>>> out how much flash and ram my project is using? (PIC18 target).
>&
On Sat, 28 Nov 2009, Philipp Klaus Krause wrote:
> Gordon Henderson schrieb:
>> I'm probably missing something obvious, but is there an easy way to find
>> out how much flash and ram my project is using? (PIC18 target).
>
> I don't know about the PIC18, but on th
I'm not sure this is a compiler issue (or is it?), but I hit an
interesting error tonight - gplink failed with this:
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"
I'd added
I'm probably missing something obvious, but is there an easy way to find
out how much flash and ram my project is using? (PIC18 target).
The gpvo and gpvc doesn't seem to be much help - the map file says:
47908 program addresses used
but I'm sure it's more than that (device has 96KB of fla
On Tue, 24 Nov 2009, Raphael Neider wrote:
>> Specifically during compiler generated calls to _mullong although I
>> haven't tried any others yet.
>
> A quick look at the generated .asm shows that sdcc replaces the local
> union-type variables x, y, t, t1, and t2 with global variables -- which
> a
On Tue, 24 Nov 2009, Michel Bouissou wrote:
Le mardi 24 novembre 2009, Gordon Henderson a écrit :
Any thoughts, anyone?
As a workaround, you might disable (mask) interrupts in your main() code just
before the instruction that calls _mullong, and re-enable them immediately
after, so you&#x
On Tue, 24 Nov 2009, Frieder Ferlemann wrote:
> Hi Gordon,
>
> Gordon Henderson schrieb:
>> void mathTest (uint16_t x)
>> {
>>uint32_t y ;
>>uint32_t i = 0 ;
>>
>>for (;;)
>>{
>>
>> y = (uint32_t)x * 9668 +
On Thu, 12 Nov 2009, Gordon Henderson wrote:
> I'll give it a go and let you know :)
So a while back, I asked about interrupts, etc. and now I'm letting you
know what happened...
I see data corruption )-:
Specifically during compiler generated calls to _mullong although I
have
On Mon, 16 Nov 2009, Michel Bouissou wrote:
> Hi Gordon,
>
>> Saw this posting recently which made me think... Especially as I'm doing a
>> lot of floating pint work which would no-doubt be accellerated by the
>> hardware multiply, however I've just had a look at some of the code in my
>> project.
On Mon, 16 Nov 2009, Jan Waclawek wrote:
> This is a well-documented feature, see e.g.:
> http://sdcc.sourceforge.net/doc/sdccman.html/node182.html
>
> "Certain words that are valid identifiers in the standard may be
> reserved words in SDCC unless the --std-c89 or --std-c99 command line
> opti
On Tue, 10 Nov 2009, Michel Bouissou wrote:
> Hi there,
>
> Well, I've finally converted my PIC16 project to PIC18, and I was taking a
> look
> at the first SDCC .asm output that accepted to compile OK.
>
> My attention was drawn by the following SDCC-generated comment in the .asm
> file
> :
>
>
On Mon, 16 Nov 2009, Raphael Neider wrote:
> Hi,
>
>> This (contrived example) fails to compile:
>>
>>void test (int data)
>>{
>> int i ;
>> i = data ;
>>}
>>
>> Compile command:
>>
>>sdcc -mpic16 -p18f4685 -c test.c
>>
>> Gives:
>>
>>test.c:5: syntax error: token ->
On Mon, 16 Nov 2009, Vaclav Peroutka wrote:
>
>> Noticed this when porting code from an AVR platform (using gcc-avr) - it's
>> not drastically important, as I've just renamed 'data' in my code to
>> something else which then compiles and works fine, but FYI...
>>
>> Thanks,
>>
>> Gordon
>>
>
> Yes
This (contrived example) fails to compile:
void test (int data)
{
int i ;
i = data ;
}
Compile command:
sdcc -mpic16 -p18f4685 -c test.c
Gives:
test.c:5: syntax error: token -> 'data' ; column 10
test.c:6: error 159: in function test: name omitted for parameter 1
On Fri, 13 Nov 2009, Raphael Neider wrote:
> Hi,
>
>> extern SIGHANDLER(rtcHandler) ;
>>
>> DEF_INTHIGH (high_int)
>> DEF_HANDLER (SIG_TMR1, rtcHandler)
>> END_DEF
>>
>> and in a separate file:
>>
>> SIGHANDLER (rtcHandler)
>> {
>> ...etc
>> }
>>
>> it compiles fine
Compiling this function: (PIC16 target if that helps)
void delay (uint32_t delay)
{
setCounter (delay) ;
while (!counterTriggered ())
;
}
Gives the error:
dross.c:435: error 98: conflict with previous definition of 'delay' for
attribute 'type'
from type 'unsigne
I'm using interrupts and using the signal.h include as that looks like a
reasonably efficient way to dispatch interrupts from different sources -
however I want the interrupt code in a different file, so in my main
interrupt handling file I have:
(cut-down example)
extern SIGHANDLER(rtcHa
On Thu, 12 Nov 2009, Roel Adriaans wrote:
> On Thu, Nov 12, 2009 at 02:33:29PM -0300, Marcos Chaparro wrote:
>>
>> A few mates didn't use sdcc just because it lacks some libraries like this :(
>>
>
> I've been thinking that a site with diferent libraries for SDCC would be a
> nice idea. Need to ha
On Thu, 12 Nov 2009, Raphael Neider wrote:
> Hi,
>
>>> it would make life easier if I can use multiple interrupts - however
>>> inside an interrupt routine I need to be able to call other functions
>>> and do some floating point math. I also need the main interrupt to be
>>> reentrant, so the long
On Thu, 12 Nov 2009, Bruno de Pádua Mélo wrote:
Hi guys, I'm playing with SDCC for a while, always using RS232 for debug
and communication, recently replaced my workstation for a notebook and
no more serial ports available, so I decided to just abandon the RS232
and go for the USB.
I've been wo
... or what can't I do?
Essentially I have a little real-time system which currently runs on an
AVR chip (with GCC) which I'm porting to PIC18 and SDCC. So-far so good
and SDCC is managing about 8000 lines of C very well.
So before I end up shooting myself in the foot, I thought I'd ask a
qui
On Sun, 8 Nov 2009, Gudjon I. Gudjonsson wrote:
> Hi
>I do have the problem that version 2.9.0 doesn't compile on a current
> Debian system and then the question is: Shall I patch the package, make a
> package out of the current SVN version or wait for the next sdcc release? The
> current SVN
On Sat, 31 Oct 2009, Anton Staaf wrote:
>Hello, I am trying to compile a simple test program for the
> PIC18F67J60 using the Ubuntu Karmic version of SDCC. The version
> information is:
>
> SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
> 2.9.0 #5416 (Aug 15 2009) (UN
tle RTOS which I'm using on
the AVR platform, shouldn't be hard for me to port it to the PIC.
Cheers,
Gordon
>
> On Wed, Oct 28, 2009 at 7:55 PM, Gordon Henderson wrote:
>>
>> About to embark on a largish project on a PIC 18F system - not sure how
>> much code
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 to
s
28 matches
Mail list logo
