Georg Icking-Konert | 26 Feb 19:02 2015
Picon

Re: SDCC port of STM8 Standard Peripheral Library

hello Frieder,

thanks a lot for pointing this project out, I was not aware of it  :-)  However, are you sure this tool also works
for STM8? Because I can compile it without issue (OS X 10.10.2), but when I e.g. try to read the device ID I get
the following output:

————
iMac:stm32flash georg$ stm32flash /dev/tty.usbserial-A4009I0O

stm32flash 0.4

http://stm32flash.googlecode.com/

Interface serial_posix: 57600 8E1
Got NACK from device on command 0x01
————

Does it work with STM8 for you? For a brief feedback thanks a lot in advance!

Regards,
Georg

> Hi Georg,
> 
> Am 17.02.2015 um 21:05 schrieb Georg Icking-Konert:
>>  - created Win, Linux, and MacOSX batch scripts to compile and upload via https://github.com/gicking/STM8_serial_flasher
> 
> thanks! Just want to note, that there is another project with overlapping/similar functionality over here:
> https://code.google.com/p/stm32flash/
> Maybe there are synergies.
(Continue reading)

陳韋任 | 26 Feb 03:57 2015
Picon

Does stackauto make binary different everytime?

Hi All,

  I have a question about stackauto. When I enable #pragma stackauto
on the entire project, the binary has chance to be different. Most of
those difference are the order of local variable allocated on the
stack. Is it normal, or something goes wrong?

Regards,
chenwj

--

-- 
Wei-Ren Chen (陳韋任)
Homepage: http://people.cs.nctu.edu.tw/~chenwj

------------------------------------------------------------------------------
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
Master Postfach | 16 Feb 22:07 2015
Picon

Re: SDCC port of STM8 Standard Peripheral Library

hello,

with the great support by this community I am nearly done with an initial port of the STM8 Standard Peripheral Library to SDCC. 

Technical status:
  - applied SDCC specific changes to some headers and sources (marked with "SDCC“)
  - changed all ISR headers in examples to skip ISR declaration (see open points)
  - added flash r/w for 24b addresses via inline assembly (thanks Philipp!)
  - created a SDCC "template project“ (i.e. Makefile). See $(SPL)/Project/STM8S_StdPeriph_Template/
  - created Win, Linux, and MacOSX batch scripts to compile and upload via https://github.com/gicking/STM8_serial_flasher 
  - added Doxygen input for creating manual from sources, since provided UM is in Windows proprietary .chm format —> run Doxy to create HTML docu
  - all SPL examples can be compiled but require editing of Makefile. Functionality tested partly (see open points)

Open points —> questions to you:
  - I only have access to a STM8 Discovery Board and a custom PCB, so I can't verify all functionality -> additional checking is required
  - since I am used to IDEs, the provided Makefile is far from perfect. For example it lacks automatic dependencies. Any help is appreciated!
  - in the same content: a template project for an IDE would be nice, but which one…?
  - acc. to UM flash block operations must be executed from RAM. How do I compile/link code for RAM execution?
  - the trap handler requires a patch or recent nightly-build. If not present just comment out. However, traps shall be part of the next release (when?)
  - SDCC requires the interrupt token AFTER the function name in ISR declaration. I have fixed all examples, but this requires a manual fix for other libs that rely on SPL (see STM homepage). However, according to Erik and Philipp this would require a change of the SDCC parser with associated risks --> not likely to be changed

Legal status:
  - STM has indicated that they may approve of distribution of the modified sources. But nothing official, yet
  - I would still prefer STM to support SDCC officially to assert future consistency. But so far no news on this

Until one of the above happens, you can download the SDCC patch for the STM8 SPL v2.2.0 from https://github.com/gicking/SPL_2.2.0_SDCC_patch
For instructions on patching see e.g. http://jungels.net/articles/diff-patch-ten-minutes.html. Please let me know if the patch works.

My first impressions of the SPL are quite mixed. It seems much more complicated than e.g. Wiring for Arduino. However it is also much more versatile and, as said before, the STM8 SPL is very similar to the STM32 SPL. And for the latter with 100s of registers, a HW-lib is convenient to say the least. In addition STM provides a lot of ready-made software which is based on the SPL. So I guess it’s worth digging into… Let me know what you think!

Any feedback and/or support on the above open points is highly welcome! 

Regards,
Georg Icking-Konert


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

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Kustaa Nyholm | 18 Feb 06:23 2015

PIC16 port asm listing line numbers do not match

Hi,

it looks to me that the source code line numbers in the .asm file
for PIC16 port do match. Lines are missing and the code
generated does not correspond to the referred to lines.

Is this a known issue? Any workarounds? Worth reporting as bug?

br Kusti

Below is an example, starting from C-source code line 135:

int32_t get_position(uint8_t i) {
 uint8_t stp;
 uint8_t dlt;
 uint32_t pos;
 uint8_t dir;
 do {
  stp = g_low_pri_isr_guard;
  dlt = g_stepper_states[i].last_steps - g_stepper_states[i].steps;
  pos = g_stepper_states[i].position;
  dir = g_stepper_states[i].last_dir;
 } while (stp != g_low_pri_isr_guard);
 if (dir)
  pos += dlt;
 else
  pos -= dlt;
 return pos;
}

This gets compiled to:

; ; Starting pCode block
S_main__get_position code
_get_position:
; .line 135; main.c stp = g_low_pri_isr_guard;
 MOVFF FSR2L, POSTDEC1
 MOVFF FSR1L, FSR2L
 MOVFF r0x00, POSTDEC1
 MOVFF r0x01, POSTDEC1
 MOVFF r0x02, POSTDEC1
 MOVFF r0x03, POSTDEC1
 MOVFF r0x04, POSTDEC1
 MOVFF r0x05, POSTDEC1
 MOVFF r0x06, POSTDEC1
 MOVFF r0x07, POSTDEC1
 MOVFF r0x08, POSTDEC1
 MOVFF r0x09, POSTDEC1
 MOVFF r0x0a, POSTDEC1
 MOVFF r0x0b, POSTDEC1
 MOVFF r0x0c, POSTDEC1
 MOVFF r0x0d, POSTDEC1
 MOVFF r0x0e, POSTDEC1
 MOVLW 0x02
 MOVFF PLUSW2, r0x00
; ;multiply lit val:0x11 by variable r0x00 and store in r0x00
; .line 140; main.c if (dir)
 MOVF r0x00, W
 MULLW 0x11
 MOVF PRODH, W
 MOVWF r0x01
 MOVFF PRODL, r0x00
 MOVLW LOW(_g_stepper_states)
 ADDWF r0x00, F
 MOVLW HIGH(_g_stepper_states)
 ADDWFC r0x01, F
 MOVF r0x00, W
 ADDLW 0x08
 MOVWF r0x02
 MOVLW 0x00
 ADDWFC r0x01, W
 MOVWF r0x03
 MOVF r0x00, W
 ADDLW 0x06
 MOVWF r0x04
 MOVLW 0x00
 ADDWFC r0x01, W
 MOVWF r0x05
 MOVF r0x00, W
 ADDLW 0x0d
 MOVWF r0x06
 MOVLW 0x00
 ADDWFC r0x01, W
 MOVWF r0x07
 MOVLW 0x09
 ADDWF r0x00, F
 BTFSC STATUS, 0
 INCF r0x01, F
_00117_DS_:
; .line 141; main.c pos += dlt;
 MOVFF _g_low_pri_isr_guard, r0x08

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.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
Tomas Nordin | 16 Feb 22:16 2015
Picon
Picon

Writing an int to the CCPR1 register

Hi

I have a function that look like this:

void set_ccp1_rc2(unsigned int match_cnt)
{
	T1CONbits.TMR1ON = 0; // Stop timer.
	TMR1 = 0; //Clear timer.
	CCPR1 = match_cnt;
	CCP1CON = 0b00001001; // From here pin will be set. Cleared on match.
	T1CONbits.TMR1ON = 1; // Roll the timer.
}

It translates after compile to this:

S_timing__set_ccp1_rc2	code
_set_ccp1_rc2:
;	.line	87; SRC/timing.c	void set_ccp1_rc2(unsigned int match_cnt)
	MOVFF	FSR2L, POSTDEC1
	MOVFF	FSR1L, FSR2L
	MOVFF	r0x00, POSTDEC1
	MOVFF	r0x01, POSTDEC1
	MOVLW	0x02
	MOVFF	PLUSW2, r0x00
	MOVLW	0x03
	MOVFF	PLUSW2, r0x01
;	.line	89; SRC/timing.c	T1CONbits.TMR1ON = 0; // Stop timer.
	BCF	_T1CONbits, 0
;	.line	90; SRC/timing.c	TMR1 = 0; //Clear timer.
	CLRF	_TMR1
;	.line	91; SRC/timing.c	CCPR1 = match_cnt;
	MOVF	r0x00, W
	MOVWF	_CCPR1
;	.line	92; SRC/timing.c	CCP1CON = 0b00001001; // From here pin will be set. Cleared on match.
	MOVLW	0x09
	MOVWF	_CCP1CON
;	.line	93; SRC/timing.c	T1CONbits.TMR1ON = 1; // Roll the timer.
	BSF	_T1CONbits, 0
	MOVFF	PREINC1, r0x01
	MOVFF	PREINC1, r0x00
	MOVFF	PREINC1, FSR2L
	RETURN	

There is a problem with the running code on the device. It occurs to me
that only one byte is written to the _CCPR1 register (MOVWF _CCPR1).
Also I am confused to see direct writes to 16-bit equates in the
assembly code, is that possible?

Should the above translation work as intended or is there something
funky?

/

Tomas

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
Kustaa Nyholm | 16 Feb 20:03 2015

Optimizing code for PIC18F

Hi,

I'm optimising my code, mainly for size. Knowing how much better
code SDCC creates for global variables I made an interesting comparison
which I thought I share here, see code below.

Interestingly the code (bar4) that four times expands the whole
'get position'  calculation is smaller (585 < 622) than the more
conventionally coded subroutine (bar5) based version.

And, maybe not surprisingly, it is about four times faster.
(The execution times are of course estimate based on code
size and the execution path assumption).

Without testing conventional wisdom would have led me to
believe that the macro version would be much bigger than
the subroutine based one.

br Kusti

stepper_state_t g_stepper_states[4];

#define GET_POSITION(i) \
  (g_stepper_states[i].last_dir)?\
  ( g_stepper_states[i].position + (g_stepper_states[i].last_steps -
g_stepper_states[i].steps))\
 :\
  ( g_stepper_states[i].position - (g_stepper_states[i].last_steps -
g_stepper_states[i].steps))\

int32_t get_position(uint8_t i) { // bytes 434 cycles ~217
 return  (g_stepper_states[i].last_dir)?
  ( g_stepper_states[i].position + (g_stepper_states[i].last_steps -
g_stepper_states[i].steps))
 :
  ( g_stepper_states[i].position - (g_stepper_states[i].last_steps -
g_stepper_states[i].steps));
}

int32_t pos=0;

void bar4() { // bytes 582 cycles ~291
 pos=GET_POSITION(0);
 pos=GET_POSITION(1);
 pos=GET_POSITION(2);
 pos=GET_POSITION(3);
}

void bar5() { // bytes 188 cycles 188
 pos=get_position(0);
 pos=get_position(1);
 pos=get_position(2);
 pos=get_position(3);
 }

 // bar 4 = bytes 582               cycles  291
 // bar 5 = bytes 622 = 188 + 434   cycles ~1056 = 188 + 4 * 217~

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.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
Richard Hughes | 10 Feb 21:59 2015
Picon

Device reset when using __at() for BDT entries

Hi all,

I'm attempting to write a USB stack for a super simple low power
device using a PIC16F1454 (pic14) and SDCC (from svn trunk).

I'm defining these two structures

__at(0x2000) volatile BDT_t ep0Bo;
__at(0x2070) volatile setup_package_t setupPacket;

... and then doing "ep0Bo.ADDR = (uint16_t) &setupPacket;" but this
resets my device. I assume I'm using the BDT address in the wrong way,
but there doesn't seem to be many understandable pic14 USB examples
that can compile with SDCC. Breaking on the offending line shows that
&setupPacket does indeed equal 0x2070. I'm trying to use the 0x2070
buffer to receive the setup packet.

I've attached a minimal reproducer to show the problem. Any advice
very welcome, thanks!

Richard
Attachment (fixme.c): text/x-csrc, 1406 bytes
------------------------------------------------------------------------------
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
Richard Hughes | 10 Feb 21:59 2015
Picon

Device reset when using __at() for BDT entries

Hi all,

I'm attempting to write a USB stack for a super simple low power
device using a PIC16F1454 (pic14) and SDCC (from svn trunk).

I'm defining these two structures

__at(0x2000) volatile BDT_t ep0Bo;
__at(0x2070) volatile setup_package_t setupPacket;

... and then doing "ep0Bo.ADDR = (uint16_t) &setupPacket;" but this
resets my device. I assume I'm using the BDT address in the wrong way,
but there doesn't seem to be many understandable pic14 USB examples
that can compile with SDCC. Breaking on the offending line shows that
&setupPacket does indeed equal 0x2070. I'm trying to use the 0x2070
buffer to receive the setup packet.

I've attached a minimal reproducer to show the problem. Any advice
very welcome, thanks!

Richard
Attachment (fixme.c): text/x-csrc, 1406 bytes
------------------------------------------------------------------------------
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
Kustaa Nyholm | 8 Feb 15:59 2015

Symbol not previously defined: "_g_toad4_status" for static volatile toad4_status_t g_toad4_status;

With sdcc 3.4.0 I get

../obj/main.asm:17:Error[113]   Symbol not previously defined:
"_g_toad4_status"

for this in my source code:

volatile toad4_status_t g_toad4_status;

if I add the word 'static' as in the title of this message,
then this compiles ok.

3.2.0 did not choke on this ... is this a bug or new C-standard
that requires a separate declaration for  every definition?

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/
Kustaa Nyholm | 8 Feb 15:45 2015

Message[1301] Using default destination of 0 (Access Bank)

Now I'm getting bunch of warnings (see title of this message):

I found this:

https://sourceforge.net/p/gputils/support-requests/8/

so this is related to gputils/version, right?

What is the recommended way of getting rid of this
(false) warning?

It is false, right?

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/
Kustaa Nyholm | 8 Feb 15:07 2015

SDCC 3.4.0 PIC18 includes

Hi,

I just upgraded from 3.2.0 to 3.4.0 and now I get a lot of these
from a project that compiled clean under 3.2.0:

>make
/Users/nyholku/sdcc-3.4.0/bin/sdcc -c --no-crt --ivt-loc=0x800 -V -L
/Users/nyholku/sdcc-3.2.0/share/sdcc/non-free/lib/pic16
-Wl,-m,-s18f45k50.lkr -mpic16 -p18f45k50 --disable-warning 85 --std-sdcc99
--obanksel=3 --use-non-free usb_hid.c -o ../obj/usb_hid.o
/Users/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic16/main.c:701
setting interrupt vector addresses 0x800
+ /Users/nyholku/sdcc-3.4.0/bin/sdcpp -nostdinc -Wall -Dpic18f45k50
-D__18f45k50 -D__SDCC_PIC18F45K50 -DSTACK_MODEL_SMALL
-D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC_USE_NON_FREE
-DSDCC_USE_NON_FREE -D__SDCC_ALL_CALLEE_SAVES -D__SDCC=3_4_0 -DSDCC=340
-D__SDCC_REVISION=8981 -DSDCC_REVISION=8981 -D__SDCC_pic16 -DSDCC_pic16
-D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__
-D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include/pic16 -isystem
/usr/local/share/sdcc/include/pic16 -isystem
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/include -isystem
/usr/local/share/sdcc/include -isystem
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16
-isystem /usr/local/share/sdcc/non-free/include/pic16 -isystem
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include -isystem
/usr/local/share/sdcc/non-free/include  usb_hid.c
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16/pic18f45
k50.h:296: error 91: extern definition for 'UCON' mismatches with
declaration.
/usr/local/share/sdcc/include/pic16/pic18f2455.h:159: error 177:
previously defined here
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16/pic18f45
k50.h:310: error 91: extern definition for 'UCONbits' mismatches with
declaration.
/usr/local/share/sdcc/include/pic16/pic18f2455.h:172: error 177:
previously defined here
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16/pic18f45
k50.h:325: error 91: extern definition for 'USTAT' mismatches with
declaration.
/usr/local/share/sdcc/include/pic16/pic18f2455.h:147: error 177:
previously defined here
/Users/nyholku/sdcc-3.4.0/bin/../share/sdcc/non-free/include/pic16/pic18f45
k50.h:349: error 91: extern definition for 'USTATbits' mismatches with
declaration.

I can surely figure out the root cause, just checking out if there is
something I should know about...

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/

Gmane