Le 30/01/2015 15:43, Kustaa Nyholm a écrit :
> DIP unfortunately.
Yep... A more recent TQFP version would "just" require an adapter board...
But we're in real life, I know...
Sébastien Lorquet
--
Dive into the World of
On 30/01/2015 16:22, "M L" wrote:
>2015-01-30 14:03 GMT+01:00, Kustaa Nyholm :
>> First of all, I'm talking about existing code and hardware.
>>
>> The existing code (without the bootloader) already pretty much
>> fills the PIC18F4550.
>>
>> I can't just willy-nilly move to a bigger device, there
2015-01-30 14:03 GMT+01:00, Kustaa Nyholm :
> First of all, I'm talking about existing code and hardware.
>
> The existing code (without the bootloader) already pretty much
> fills the PIC18F4550.
>
> I can't just willy-nilly move to a bigger device, there is
> existing hardware on the field.
> I d
On 30/01/2015 14:15, "M L" wrote:
>Hi,
>I don't really get it, why You trying (so hard) use a bootloader which
>won't fit in boot block, so what?
>Bootloader can be with any size, just move user code to location
>after bootloader (to first free block of flash erase boundary).
>
>If size of user
Hi,
I don't really get it, why You trying (so hard) use a bootloader which
won't fit in boot block, so what?
Bootloader can be with any size, just move user code to location
after bootloader (to first free block of flash erase boundary).
If size of user code+bootloader won't fit into device - choo
> I'll try to give it a shot this weekend. If you are willing to help in
> testing (at least reporting what does not/no longer work once the changes are
> made ;-)), we should be able to find a solution here.
Hi Raphael,
that is brilliant! Sure I will help all I can.
br Kusti
Hoping to report
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
On Wed, Jul 9, 2014 at 11:59 AM, Joshua Lansford <
joshua.lansf...@laserlinc.com> wrote
>
> strlen is used from the string.h header file which I am assuming is
> /home/user/sdcc/sdcc/device/include/pic16/string.h
>
> Anyone know what I am missing in the call to gplink so that it can find
> the lib
On Wed, Jul 9, 2014 at 9:52 AM, JuanPi wrote:
> In the makefile that I sent you you could see that I was renaming the
> .o into .rel.
> Works fine like that.
>
>
Here is my millage.
I tried renaming the .o's to .rel's and then with the pic flag still
enabled sdcc complains it doesn't know what a
In the makefile that I sent you you could see that I was renaming the
.o into .rel.
Works fine like that.
On Wed, Jul 9, 2014 at 3:25 PM, Joshua Lansford
wrote:
> On Wed, Jul 9, 2014 at 9:07 AM, Maarten Brock
> wrote:
>>
>> The only issue is that gputils uses .o instead of .rel object files and
On Wed, Jul 9, 2014 at 9:07 AM, Maarten Brock
wrote:
> The only issue is that gputils uses .o instead of .rel object files and
> thus you see no .rel ;-)
>
>
Ah ha. Ok.
However as sdcc doesn't understand the .o files "warning 119: don't know
what to do with file 'count.o'. file extension unsupp
>> And where is the -c in this line?
>>
>>
> Ooops, here is act 2 of the six shooter.
>
>
> user@enj:~/sdcc/proj/count$ ls
> count.c
> user@enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free
> -p18f97j60 -c --verbose count.c
> Processor: 18f97j60
> sdcc: Calling preprocessor...
> sdc
> And where is the -c in this line?
>
>
Ooops, here is act 2 of the six shooter.
user@enj:~/sdcc/proj/count$ ls
count.c
user@enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free
-p18f97j60 -c --verbose count.c
Processor: 18f97j60
sdcc: Calling preprocessor...
sdcc: Generating code...
> user@enj:~/sdcc/proj/count$ sdcc --std-c99 -mpic16 --use-non-free
> -p18f97j60 count.c --verbose
> Processor: 18f97j60
> sdcc: Calling preprocessor...
> sdcc: Generating code...
> sdcc: Calling assembler...
> sdcc: Calling linker...
> message: Using default linker script
> "/usr/local/share/gputi
On Tue, Jul 8, 2014 at 4:03 PM, Unix Savvy Brian wrote:
> Please provide some output with the error message you are getting. You
> might want to add -v option to show the intermediate steps actually taken
> by the SDCC front-end.
>
> that would be helpful.
>
>>
>>
Here is the command and the out
> When using the -mpic16 flag the compiler doesn't seem to produce rel files
> when -c is supplied.
It works for me here without problems. I am using 3.4.0.
https://github.com/kakila/libdwengo-sdcc/blob/master/lib/Makefile.am
On Tue, Jul 8, 2014 at 9:40 PM, Joshua Lansford
wrote:
> Hello folks
Le lundi 16 novembre 2009, Gordon Henderson a écrit :
> It's doing a mighty fine job on my project.
In mine too... In the earlier setps of my project I had first started
converting some fast interrupt code into asm, expecting more compact and
performing code, but I soon realized that there was l
> 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
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.
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... Although it has that warning, it is using the MUL
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
> :
>
>
Dear everybody,
Just after I have sent the email, I have found the problem.
I did not managed properly the control lines of the LS7166.
Upon request, I share my code for thoose, who wants to look at it.
Alex
> Dear Everybody,
>
> I think this is slightly off topic, but anyway must I ask.
>
>
22 matches
Mail list logo
