Kustaa Nyholm | 31 Jan 11:03 2015

ANNOUNCE diolan-plus2 bootloader

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 published it here as required by the GPL:

https://github.com/nyholku/diolan-plus2

thanks for all your help!

br Kusti

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
We will not be liable for direct, indirect, special or consequential damages arising from alteration of
the contents of this message by a third party or as a result of any virus being passed on or as of transmission
of this e-mail in general.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Georg Icking-Konert | 30 Jan 21:35 2015
Picon

Re: SDCC port of STM8 Standard Peripheral Library

hello again,

> I apologize for the ambiguity in my previous message; I was mainly trying 
> to reassure Philipp about the patch with respect to the non-stm8 backends. 
> I realize that what you are trying to accomplish probably will require 
> some modification to SDCC mainline to conform to the expected syntax.

whoops, sorry! That would indeed solve the first of my 2 problems...

> The patch has been applied in revision #9163 and will thus be in the
> next release (and in the snapshots from tomorrow).

:-)  see above. Do you already know when the next release is due? In any case I’ll download the snapshot

Regards,
Georg Icking-Konert
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Sdcc-user mailing list
Sdcc-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Georg Icking-Konert | 30 Jan 21:31 2015
Picon

Re: SDCC preprocessor issue

hello all, 

thanks a lot for your feedback! As for your mails see my comments below

> You forgot the option to modify SDCC so it accepts the __interrupt keyword
> either before or after the function :)

weeeellll I figured that is not really an option - is it???

> Are you sure? The Raisonance C compiler for ST7/STM8 appears to expect the 
> interrupt or trap keywords to follow the function parameters, like SDCC. 
> See pages 43-44 here:
> 
>   ftp://raisonance.com/pub/Support/RKit-STM8/RCSTM8.pdf
> 
> You might also want to double check that you have the current version of 
> the STM8-SPL. From the link you provided, I downloaded STSW-STM8069 
> version 2.2.0. It appears to provide compiler specific implementations of 
> a macro named INTERRUPT_HANDLER that takes two parameters: a function name 
> and a vector number. The macro forms a function declaration with interrupt 
> keyword either at the beginning or end of the declartion, as appropriate 
> for the detected compiler.

sorry I probably haven’t made myself clear. The macro INTERRUPT_HANDLER you mention is used for the
implementation and works just fine with SDCC. I was referring to the macro INTERRUPT (a few lines below)
which is only used for declaration in the ISR header file (see stm8s_it.h). Maybe in the end I have to do the
same as for Raisonance, which simply skips the declaration: not nice but works 

Best regards,
Georg Icking-Konert
(Continue reading)

Jesse Lackey | 30 Jan 05:15 2015

Re: Sdcc-user Digest, Vol 103, Issue 14

Be aware that XC8 doesn't support the extended instruction set... I had 
to disable it in the chip config for the compiler to produce output. 
Surprising.

<http://www.microchip.com/forums/m710874.aspx>

This may clarify the choice for you!
J

> Hi,
>
> I'm at cross roads, should I go on with SDCC (which I'm happy
> with and familiar) or move to MPLAB X compilers...
>
> The dilemma:
>
> I'm planning to use the Diolan bootloader which uses extended
> instructions set. That bootloader is very nice as it is in
> asm and fits (just!) into the boot block and offers encryption
> for the firmware to be bootloaded.
>
> Problem is that code compiled with SDCC does not work with
> the extended instruction set enabled and as this [extended
> instruction set mode] cannot be changed at run time this
> combination [SDCC and diolan] does not work.
>
> I converted the diolan bootloader to 'legacy' mode, but
> of course it did not fit. So I've optimised it and now it
> fits and runs, but the encryption does not work properly,
> obviously some of optimisations or conversion broke something.
(Continue reading)

Kustaa Nyholm | 29 Jan 21:09 2015

PIC18 extended instruction set support

Hi,

I'm at cross roads, should I go on with SDCC (which I'm happy
with and familiar) or move to MPLAB X compilers...

The dilemma:

I'm planning to use the Diolan bootloader which uses extended
instructions set. That bootloader is very nice as it is in
asm and fits (just!) into the boot block and offers encryption
for the firmware to be bootloaded.

Problem is that code compiled with SDCC does not work with
the extended instruction set enabled and as this [extended
instruction set mode] cannot be changed at run time this
combination [SDCC and diolan] does not work.

I converted the diolan bootloader to 'legacy' mode, but
of course it did not fit. So I've optimised it and now it
fits and runs, but the encryption does not work properly,
obviously some of optimisations or conversion broke something.

I'm working on fixing that but the big question is, if I
would be better of with MPLABX compilers in the long run...

In theory the MPLABX compiler with the extended instruction
set enabled should produce better and faster code so in
that respect the answer is obvious ... why go through all
the trouble making the diolan work with SDCC... OTH
emigrating to a new compiler is bound incur some pain and
(Continue reading)

Kio | 28 Jan 13:25 2015
Picon

Re: problem running Linux daily snapshot

Hi,
i have a problem running any daily snapshot for Linux.
i have a Linux Mint 17 (based on Ubuntu LTS) fully updated.
when i run sdcc i get this error message:
/usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./bin/sdcc)
I believe this indicates that you link against a version of libstdc++ which is newer than what i have
installed. Please tell me if i'm wrong. 
My question is: is this required or does it 'just happen' and can be changed? I'm probably not the only one
with this problem?
((I somehow need a build which is newer than 3.4.0 because you have changed some library function names (for
the Z80 port) and i already use the new names in my project. Though if it cannot be helped then i can add a
couple of symlinks and edit the library source files to include the old and the new label names.))

    ... Kio !
--

-- 
http://k1.spdns.de/Vintage/Sinclair/
GPG-ID: 80E6A1DA

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
(Continue reading)

Georg Icking-Konert | 26 Jan 20:51 2015
Picon

SDCC preprocessor issue

hello all,
 
as mentioned elsewhere I am trying to port the STM8-SPL library by STM to SDCC. Currently I got stuck at a seemingly simple problem. Here’s the technical background:

1) my target is to modify only the common headers, not the project specific header
 
2) all other supported compilers (Cosmic, IAR, Resonance) declare interrupt routines with the keyword BEFORE the function, e.g. “__interrupt void ISR(void);"

3) SDCC requires the interrupt keyword AFTER the function name, e.g. “void ISR(void) __interrupt;”
 
The SPL library has a common header (- can be modified) named “stm8s.h”, which defines a (compiler dependent) macro like

#define INTERRUPT __interrupt
 
The compiler independent headers for interrupt service routines (-> should not be modified) uses this define like

INTERRUPT void TIM1_ISR(void);
 
and this works fine for all supported compilers. But how can I modify the #define in stm8s.h for SDCC??? So far I tried (and failed with) the following ideas, sorted by my order of preference:
 
1) move the keyword to after the function. Unfortunately the original macro (and hence the project files) doesn’t use brackets like “#define INTERRUPT(name) __interrupt void name(void);” 

2) skip the declaration by a “comment macro” like “#define INTERRUPT /##/”. In this case the declaration would be skipped, but since an ISR is not actively called, I figure that would be ok. But apparently this doesn’t work for gcc/sdcc preprocessor. For reasons e.g. see http://stackoverflow.com/questions/15545520/how-to-create-a-c-single-line-comment-macro

3) prompt a warning but compile like ”#define INTERRUPT  #warning xxx”. In this case at least the user could be notified what to change in the respective project headers. But apparently macros cannot contain preprocessor commands
 
Now I ran out of ideas of how to solve this issue (without the user fixing every declaration manually)… But maybe one of you guys has an idea I didn’t think of!? For any advice on this thanks a lot in advance!!!

Regards,
Georg
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Georg Icking-Konert | 26 Jan 20:45 2015
Picon

Re: SDCC port of STM8 Standard Peripheral Library


> On Thu, 22 Jan 2015, Philipp Klaus Krause wrote:
> 
>> On 21.01.2015 19:36, Georg Icking-Konert wrote:
>>> 
>>> 1) how do I declare and implement the trap handler? According
>>> to http://sourceforge.net/p/sdcc/patches/224/ the keyword "__trap? is
>>> available via patch (2014-02-22). Is this already part of 3.4.0 (#8981;
>>> 2014-04-5) and, if yes, how do I use it? If not, is it planned for the
>>> next release which is due when?
>>> 
>> 
>> The patch has not been applied yet. It adds a new keyword, and I don't
>> feel familiar enough with all the backends at the moment do decide on
>> this. Maybe when looking at all the backends, there is a better way to
>> do it instead. If this is an important feature to stm8 users, I can
>> apply the patch (so it would be in the next release; if we come up with
>> a better way later, we can still change the syntax then).
>> 
>> Philipp
> 
> The patch seems reasonably safe to me. The __trap keyword would only be 
> active for the stm8 backend. However, it would be similar to the 
> __interrupt keyword in that it is expected to follow the function name 
> rather than precede it; I don't know if that would be a problem or not.
> 
>   Erik
> 

Hi Eric,

thanks for your assessment of the patch for __trap on STM8. However, if I understand correctly, you mean
that it’s safe for me to apply the path…!? The target of my porting is to make the STM8-SPL available for
the SDCC community. So, unless this becomes a standard feature in an official release, I probably won’t
use it. Anyway, thanks for the reply!

As for the "indicator before vs. after“ function name, this is indeed an annoying issue. Please see my
other post on this…

Georg
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Sdcc-user mailing list
Sdcc-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Kustaa Nyholm | 25 Jan 11:40 2015

Converting away extended instruction set on PIC18F4550

In removing extended instructions from the Diolan bootloader

I had to change a lot of instructions like:

<  subfsr FSR2, 3
---
>  ;subfsr FSR2, 3
>  movf POSTDEC2, W
>  movf POSTDEC2, W
>  movf POSTDEC2, W

<  addfsr FSR2, 4
---
>  ;addfsr FSR2, 4
>  movf POSTINC2, W
>  movf POSTINC2, W
>  movf POSTINC2, W
>  movf POSTINC2, W

And now the code won't fit ... any better replacements
for those 'addfsr' and 'subfsr' instructions?

br Kusti

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
We will not be liable for direct, indirect, special or consequential damages arising from alteration of
the contents of this message by a third party or as a result of any virus being passed on or as of transmission
of this e-mail in general.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
Kustaa Nyholm | 25 Jan 10:11 2015

Re: PIC18F4550 Extended instruction set / Re: memcpyram2ram crashes, debug ideas?


Blast from the past!

Debugging my 'memcpyram2ram problem' (going on for 20 hours now!)
I may have found the problem, I've yet to verify this but
it looks like my (Diolan's really) USB bootloader enables the
extended instruction set and searching the web I came across
this interesting exchange between Raphael and myself:

Raphael Neider <rneider <at> we...> - 2009-01-08 12:28:23
> Since SDCC r5276 (2008-11-25), the extended instruction set is
> automatically disabled by SDCC by meddling with the user-provided
> CONFIG4L byte (if no CONFIG4L byte is specified, Microchip states
> that XINST defaults to being disabled, so we are lucky).
> Prior to SDCC r5276, one had to explicitly state
>   static __code char __at(_CONFIG4L) _conf4l = something & _XINST_OFF;
> and if you missed _XINST_OFF, your program was bound to fail in
> various interesting ways, the cause of which was rather hard to find.

How prophetical!

I'm pretty sure that is the issue.

Anyways, for posterity, this is how I found this (potential) bug.

I run my code in 'gpsim' and it did not crash! So I next flashed
my code with PICKit and that code worked! Right, so something wrong
with the USB boot loading.

I disabled code protection so I could read back the code, on comparing
the pickit flashed and diolan bootloader loaded code the code
looked identical, except for the unprogrammed areas (still need to
investigate why and if that is a problem).

So I read back the config bits from both the working code and
non working code and went through them bit by bit and came
across the XINST bit.

To verify this I copied the config bits from the non-functional
to the functional code (in source code) and flashed that with PICKit.

Still the code worked!! Ok, so no problem with the config bits,
just to make sure I read back the config bits. WHAT? The XINST
bit was not set even though I set it in the source code! (That
was when I found that blast from the past above.)

Almost missed that one. I think it is a bit nasty that SDCC
changes that bit silently, I could have easily missed this
and be still searching. If the source code sets that bit
then obviously something is wrong and the compiler should
at least warn about it or better yet give an error.

Anyways, the real problem lies not with SDCC but the
fact that Dialan's bootloader turns on (and probably
uses) the extended instruction set. Now back to verifying
and rectifying the problem.

I seem to remember that someone has already made a version
that does not use the extended instruction set, yep,
it is called diolan-plus ... now if I can just find the code.

br Kusti

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
We will not be liable for direct, indirect, special or consequential damages arising from alteration of
the contents of this message by a third party or as a result of any virus being passed on or as of transmission
of this e-mail in general.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
Kustaa Nyholm | 24 Jan 12:45 2015

memcpyram2ram crashes, debug ideas?

Hi,

Background:

I've got a piece of code (USB HID and then some) that works.

Now I'm moving this to work with a UBS bootloader that allows
me to update the code via USB.

The bootloader naturally lives at 0x0000 so I've relocated
my code to 0x0800 by including a custom crt0iz.c which
locates the start up code to 0x0800 and I've changed
my linker file like this:

CODEPAGE   NAME=vectors    START=0x0800         END=0x829
PROTECTED
CODEPAGE   NAME=page       START=0x082A         END=0x7FFF

The works bootloader and loading the code works.

Also the bootloader starts my code and it starts, even
the interrupts seem to run ok.

However, it crashes at this line:

memcpyram2ram(&hid_tx_buffer, &g_toad4_status, 64);

(There is also something else wrong as the USB code
does not work, ie my device does not get enumerated).

This particular piece of hw I'm doing this on only
has one LED to help in debugging so I'm sort of
stabbing in the dark.

Here is what the .map says about those two variables
concerned in the crashing line.

           _hid_tx_buffer   0x0005b0       data     extern
../obj/usb_core.asm
          _g_toad4_status   0x000060       data     extern ../obj/main.asm

How do I know this is where it crashes? I insert a LED blink before
that line and it blinks, put it after that, and it won't.

My SDCC is:
nyholkus-MacBook-Pro:src nyholku$ /Users/nyholku/sdcc-3.2.0/bin/sdcc -v
SDCC :
mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08
3.2.0 #8008 (Jul  6 2012) (Mac OS X i386)

Any ideas how can memcpyram2ram crash?

br Kusti

This e-mail may contain confidential or privileged information. If you are not the intended recipient (or
have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
We will not be liable for direct, indirect, special or consequential damages arising from alteration of
the contents of this message by a third party or as a result of any virus being passed on or as of transmission
of this e-mail in general.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

Gmane