>> I think the right way to go here should be to consider obsolete and
discourage
this way to define values for the configuration words and implement it
through pragmas (as pic16 already does), and extend it to also support
ID locations.
+1. It would be good to make pic14 and pic16 as similar as p
Sounds interesting, thanks for letting us know.
Any plans on submitting your changes to the different upstream projects
(OpenOCD, SDCC, etc.)? Any reason not to?
Cheers,
Diego
On Mon, Mar 6, 2017 at 1:34 PM, Åke Rehnman wrote:
> For all interested in STM8 and gdb debugger I hereby announce the
Thank you very much Maarten and all the SDCC developers for keeping this
great project!
Cheers!
On Wed, Jun 24, 2015 at 10:55 AM, Maarten Brock
wrote:
> Hello SDCC friends,
>
> Today a new release of SDCC was made. We are now at version 3.5.0.
> You can get it at:
> http://sourceforge.net/proje
Since every protection (code, eeprom, etc) seems to be disabled, why don't
you ask your user to read back what he programs so you can compare?
Regards,
Diego
On Fri, May 8, 2015 at 7:10 AM, Kustaa Nyholm
wrote:
> On 08/05/2015 08:58, "KHMan" wrote:
>
> >Has that been
> >ruled out?
>
> Good poi
Thanks a lot Kustaa. I think this can be useful to many people.
Regards,
Diego
On Sat, Jan 31, 2015 at 11:03 AM, Kustaa Nyholm
wrote:
> Hi,
>
>
> I'm happy to say that now my diolan's bootloader works with standard
> instructions
> set and the code compiled with SDCC works with it too!
>
> I've
I was doing something very similar for the SDCC PIC ports (Blinking LEDs
and 7 segment displays for the time being) with the idea of somebody
expanding it for the rest of SDCC ports (which I don't know about) so it
can serve as an entry point to SDCC.
Every now and then I see messages on the maili
Thanks for your work.
"The gpdasm shows the names of SFRs and bits, in addition shows the labels
in code."
Hell yes!! Thanks!
On Tue, Oct 14, 2014 at 10:05 PM, Gál Zsolt
wrote:
> Hello Károly,
>
> Thank you for a good news! Gputils is better than ever.
>
> Zsolt
>
> 2014-10-14 20:08 GMT+02:00 M
Let me add info of another PIC programmer, it's called USB PIC Prog (
http://usbpicprog.org/)
- It's open source (SW and HW)
- You can build the HW or buy it (20€)
- Works over USB
- Works on Windows, Mac and Linux
- Graphical or command line interface
Maybe the weakest point is not being able to
You can simply use variables (global or local/automatic depending on what
you need) and SDCC+GPUTILS will place them wherever they consider and
instructions for switching banks will be generated automatically when
accesing/using those variables.
So, unless you need variables to be on specific addr
Hi!
On Fri, Dec 20, 2013 at 6:49 PM, Masur Jonathan wrote:
> Sorry if what I'm asking is dumb.
>
> I'd like to get started helping to develop SDCC. However the first thing
> is that I should understand as well as possible how its internal works.
> I downloaded the sources and managed to compile
-Wl-sMylinkerScript.lkr test.c
Could you send both .lst files (the working and the not working one) for us
to inspect them?
Regards,
Diego Herranz
On Thu, Feb 28, 2013 at 10:25 AM, Butuza Tamas wrote:
> Dear sdcc users and developers,
>
> At the past I used sdcc for 14 bit pic dev
"Downgrading sdcc will work. But I would recommend upgrading gputils
instead."
Absolutely. There have been a lot of bug fixes and improvements for PIC
port since 2.9.0.
On Mon, Nov 12, 2012 at 11:58 AM, Philipp Klaus Krause wrote:
> On 12.11.2012 11:54, Soloviov Dmitry wrote:
> > Thank you!
>
Yes, crt0i initializes variables, stack, etc and calls main(). You can see
what it does more in detail here:
http://sdcc.svn.sourceforge.net/viewvc/sdcc/trunk/sdcc/device/lib/pic16/startup/crt0i.c?view=markup
.
Just an offtopic comment: I would write void main(void) instead of
void main().
On M
Hi Károly!
Thanks for helping the SDCC community. PIC port users will be very happy
with your contributions.
Regards,
Diego Herranz
On Tue, Oct 16, 2012 at 9:59 AM, Alexandre Martins wrote:
> Hello Károly!
>
> I am glad that you will work on adding more PIC support to SDCC. I wish
It looks related to this patch apllied in #8008:
http://sourceforge.net/tracker/?func=detail&aid=3539804&group_id=599&atid=100599
On Mon, Jul 9, 2012 at 3:38 PM, Diego Herranz wrote:
> I find an error with PIC16 code. I think that it is related with fuses and
> CONFIG. RC3
I find an error with PIC16 code. I think that it is related with fuses and
CONFIG. RC3 works fine, though.
I get the following errors:
[..]
test.asm:4892:Error[152] Executable code and data must be defined in an
appropriate section.
test.asm:4895:Error[152] Executable code and data must be def
PIC16 (18F4550) tested on linux x86. Exactly the same code generated than
RC2.
Regards,
Diego
On Fri, Jun 29, 2012 at 6:56 PM, Borut Ražem wrote:
> SDCC 3.2.0 Release Candidate 3 source, doc and binary packages for x86
> Linux, 32 bit Windows and universal Mac OS X are available in
> correspon
Tested for PIC16 (18f4550) on linux x86.
It seems to work fine and code reduction of about 0.3% versus a snapshot 1
month old.
Regards,
Diego Herranz
On Sun, Jun 24, 2012 at 8:54 PM, Borut Ražem wrote:
> SDCC 3.2.0 Release Candidate 2 source, doc and binary packages for x86
> Linux,
Great!
It would be fantastic to update the stable releases often.
Thank you two for the effort.
On Wed, Jun 6, 2012 at 12:28 PM, Philipp Klaus Krause wrote:
> Am 31.05.2012 17:44, schrieb Diego Herranz:
> > Any progress on Debian packages?
> >
> > Thanks!
>
>
Any progress on Debian packages?
Thanks!
On Fri, May 18, 2012 at 11:47 AM, Philipp Klaus Krause wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 18.05.2012 10:54, Gudjon I. Gudjonsson wrote:
> > Hi list
> >
> > Quite soon after the release of sdcc 3.1 I had a package ready for
>
Tested. It seems to work like a charm.
Thanks again!
On Mon, May 28, 2012 at 11:03 AM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:
> Great.
>
> I'll test it as soon as the snapshot is built.
>
> Thank you very much!
>
> On Mon, May 28, 2012 at 9:24 AM,
Great.
I'll test it as soon as the snapshot is built.
Thank you very much!
On Mon, May 28, 2012 at 9:24 AM, Borut Ražem wrote:
> #pragma config accepts underscore characters in svn revision #7797.
>
> Borut
>
>
>
> On Sun, May 27, 2012 at 11:51 PM, D
Great! Thank you.
On Sun, May 27, 2012 at 10:47 PM, Borut Ražem wrote:
> Yes, the problem are underscores :-(. I'll fix it ASAP.
>
> Borur
>
>
> On Sun, May 27, 2012 at 1:49 PM, Diego Herranz <
> diegoherr...@diegoherranz.com> wrote:
>
>> Sorry,
Sorry, line 31 was:
31 #pragma config FOSC = HSPLL_HS
On Sun, May 27, 2012 at 1:43 PM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:
> With 18f4550 and sdcc #7792:
>
> [...]
> 26 #pragma config PLLDIV = 1
> 27 #pragma config CPUDIV = OSC1_PLL2
> 28 #pragma con
With 18f4550 and sdcc #7792:
[...]
26 #pragma config PLLDIV = 1
27 #pragma config CPUDIV = OSC1_PLL2
28 #pragma config USBDIV = 2
29
30
31 #pragma config FOSC USBDIV = HSPLL_HS
[...]
Warnings:
MIDI_PEDAL_fuses.h:27: warning 191: #pragma config: bad argument(s); pragma
ignored
MIDI_PEDAL_fuses.h:3
Thanks!
On Sat, May 26, 2012 at 10:37 AM, Borut Ražem wrote:
> #pragma config is correct. #pragma configure was a mistake in sdccman. I
> alredy corrected it.
>
> Borut
>
>
> On Sat, May 26, 2012 at 3:26 AM, Diego Herranz <
> diegoherr...@diegoherranz.co
sdccman says:
#pragma config setting=value [, setting=value]
but just after:
#pragma configure CP0=OFF,OSCS=ON
The former is the correct one, isn't it?
Thanks
On Fri, May 25, 2012 at 9:27 PM, Borut Ražem wrote:
> On 25. 05. 2012 18:43, Richard Hughes wrote:
> > I've built master, and tried
BTW, do you know the state of gputils package? Is anybody maintaining it?
Thanks
On Fri, May 18, 2012 at 11:22 AM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:
> I would really love to see sdcc debian packages updated.
> As a PIC16 port user, I'd like to see the sdcc
I would really love to see sdcc debian packages updated.
As a PIC16 port user, I'd like to see the sdcc-non-free package too.
I hope you find a sponsor.
Thanks
On Fri, May 18, 2012 at 10:54 AM, Gudjon I. Gudjonsson wrote:
> **
>
> Hi list
>
> Quite soon after the release of sdcc 3.1 I had a pac
in case it is useful for somebody.
Regards,
Diego
On Tue, Jan 31, 2012 at 1:22 PM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:
> I don't need fuses in the file because fuses are determined but bootloader
> and you can't change them later.
> Fuses are out of the 3
I'm starting to think like Kustaa even tough I started this topic.
Anyway, I went on testing, and I think that eeprom8_write and
eeprom16_write are missing a return asm instruction.
If eventually we don't want to have this eeprom pointer access feature, it
would be nice to turn it into a library
Thanks, I'll test it and let you know.
On Sun, Apr 22, 2012 at 2:57 PM, Raphael Neider wrote:
> 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
On Fri, Apr 20, 2012 at 12:52 PM, Diego Herranz <
diegoherr...@diegoherranz.com> wrote:
> Thanks Raphael!
>
> I'll try to test it this weekend and I'll let you all know.
>
> Thanks a lot!
>
>
> On Fri, Apr 20, 2012 at 8:37 AM, Frieder Ferlemann <
&g
Thanks Raphael!
I'll try to test it this weekend and I'll let you all know.
Thanks a lot!
On Fri, Apr 20, 2012 at 8:37 AM, Frieder Ferlemann wrote:
> Hi Raphael,
>
> Am 20.04.2012 01:05, schrieb Raphael Neider:
> > starting with svn 7610, sdcc/pic16 allows read/write access EEPROM via
> > gen
Great!
I started the implementation of gptr/*.c and I had the same doubt: what to
do with EEADRH.
Let us know how you do it eventually.
Thanks for all your help.
Diego
On Mon, Apr 16, 2012 at 7:41 PM, Raphael Neider wrote:
> Hi,
>
> > Maybe I could help you with implementation of eeprom reads
Hi Raphael!
Accesing via generic pointers would be amazing. If you had time, I would
love to see it implemeted.
The __eeprom keyword can wait, hehe!
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
und
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 started thinking th
Thanks. This improvement is great!
I have had no time to test it but I'll let you know as soon as I do.
Thanks again!
On Sun, Feb 12, 2012 at 8:38 PM, Raphael Neider wrote:
> Hi,
>
> Update regarding __critical: __critical is implemented in SDCC r7307
> both as function attribute and in block-
Thanks for your help.
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?
Thanks again
On Sun, Feb 12, 2012 at 5:00
Thanks,
I think I'll use the MACRO. What about #pragma nooverlay? Is it a nop too?
Maybe the manual should say something about it in the PIC16 port section.
I'll think where to say it and write it, what do you think?
Thank you very much!
On Sun, Feb 12, 2012 at 1:36 PM, Raphael Neider wrote:
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? If it
doesn't, how do you do it?
Thanks a lot.
---
I don't need fuses in the file because fuses are determined but bootloader
and you can't change them later.
Fuses are out of the 32K region. That's why I added them because without
padding, I couldn't get the full 32K. Adding fuses, which are out of that
range, allowed dd to copy 32K.
Exactly, con
ze
>dd if=myprog.bin of=readyfordownload.bin bs=4096
>
> The 'bs=N' would be the size required by your loader to fill all of
> memory. 'dd'
> will fill the extra bytes with zeros.
>
>
> I'm just a lurker.
>
>
> HTH,
> *brianW
Hi!
I want to use a bootloader (Scene Double bootloader) for PIC16 and it
requires to export the full program memory range of your application (even
unused range), with no eeprom nor fuses.
This is the exact text present in the bootloader manual:
> Exporting a HEX File from MPLAB
>
Once you h
Thanks a lot Raphael.
On Oct 24, 2011 7:03 PM, "Raphael Neider" wrote:
> 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
Speaking about config:
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?
Thanks
On Mon, Oct 24, 2011 at 9:40 AM, Vaclav Peroutka wrote:
>
>
> > > So, please do not disable or exclude pic14 enh. support in the
> forth
Thanks a lot
On Oct 20, 2011 11:54 PM, "Raphael Neider" wrote:
> > Then it's not related to Tim's code at all, is it? I thought it was and I
> > didn't see the reason why.
>
> Yes, the deprecation warning on the use of __CONFIG is completely
> unrelated.
>
>
>
Thanks for your answer.
Then it's not related to Tim's code at all, is it? I thought it was and I
didn't see the reason why.
Thanks
On Thu, Oct 20, 2011 at 10:22 PM, Raphael Neider wrote:
> asm bails out with an error ("__CONFIG directive is not
> supported/rec
>
---
Why is there a warning on the __CONFIG directive?
Thanks
On Wed, Oct 19, 2011 at 8:58 PM, Raphael Neider wrote:
> and you should be fine, although the deprecation warning on the
> __CONFIG directive remains :-( Seems to work, though.
>
---
It's for pic 18f2550.
Using an auxiliary timer looks as a good idea.
El 07/10/2011 16:37, "Douglas Goodall" escribió:
> Which processor are you working with, regarding this question?
>
> Douglas
>
>
>
> On Oct 7, 2011, at 4:44 AM, Diego Herranz wrote:
>
>
Thanks for your answers.
I want it for PIC so Jeff Post's disassembler won't do it. Anyway the cycle
counting facility looks nice.
I guess that I'll need to hard check the longest path in ASM and calculate
the cycles, etc.
It would be really useful to have an automated tool.
Thank you
On Fri,
Hello!
I want to calculate the maximum execution time of a ISR and so estimate the
minimum frequency required for the microcontroller.
Does anybody know any software tool to calculate the maximum execution time
of a function?
Thanks!
--
But, PIC is configured to run with internal oscillator (_INTRC_IO), so no
xtal is needed.
On Thu, Jun 9, 2011 at 5:46 PM, Dave McGuire wrote:
> On 6/9/11 11:17 AM, Laurent FAILLIE wrote:
> > I think my powersupply is too noisy and the xtal doesn't stabilize
> > ... so the PIC doesn't start. I'll
hex.
Regards,
Diego Herranz
On Thu, Jun 9, 2011 at 1:51 PM, Laurent FAILLIE wrote:
> Ok, thanks all for your reply.
>
> > How did you know that the port/pin was stayed low? Did you
> > measured it
> > by osciloscope or by inspecting the LED (which was "never
> &
54 matches
Mail list logo
