The test with normal and enhanced core PIC was done successfully. SDCC
is working well for me again.
Thanks for the effort.
Zsolt
$ sdcc -v
SDCC : pic14 3.2.0 #7959 (Jun 23 2012) (Linux)
$ gpasm -v
gpasm-0.14.2 #711 (Jun 23 2012)
$ uname -mrsv
Linux 3.2.0-0.bpo.2-686-pae #1 SMP Sun Jun 3 22:21:
Am 23.06.2012 15:47, schrieb Borut Raz(em:
Raphael,
thanks, I knew who I have to ask for help ;-)
There were many changes since the RC1 release, so I plan to make the
RC2 release earlier: 2012-06-24 and make the RC3 at the date RC2 was
originally planned: 2012-07-01.
I will apply Raphael's
Raphael,
thanks, I knew who I have to ask for help ;-)
There were many changes since the RC1 release, so I plan to make the RC2
release earlier: 2012-06-24 and make the RC3 at the date RC2 was originally
planned: 2012-07-01.
I will apply Raphael's patch immediately since the currently generated
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
On Sat, Jun 23, 2012 at 12:25 PM, Gál Zsolt wrote:
> Examing the macros.inc file in sdcc/device/lib/pic14/libsdcc/regular,
> it can help to answer the question:
>
> ; ---
> ; --- generic pointer access helpers
> ;
Examing the macros.inc file in sdcc/device/lib/pic14/libsdcc/regular,
it can help to answer the question:
; ---
; --- generic pointer access helpers
; ---
GPTRTAG_DATAEQU 0x00
GPTRTAG_CODEEQU 0
I have an impression that __code acts oposite as intendend: if __code is
defined, then _cinit is assumed to be in data memory - see the generated
asm with BANKSELs, which is wrong.
Omitting "__code" in line 71 is just a (ugly) workaround since "__code
cinit_t *cptr" seems to be correct: cptr IS a
