Georg Icking-Konert | 21 Jun 20:54 2015
Picon

Update "STM8_serial_flasher"

hello all,

just in case you’re interested, I have uploaded an update of my STM8 flashing tool to https://github.com/gicking/STM8_serial_flasher (program via UART bootloader). Changes:
  • supports direct connection RasPi UART to STM8 UART. Note: without protection the STM8 has to be supplied with 3.3V to avoid damaging the RasPi
  • option "Reply Mode“ (for details see STM8 bootloader manual). Is required e.g. for the UART2 of the STM8S105 on the "STM8S Discovery Board"
  • reset of STM8 via RasPi GPIO18. Unfortunately this requires STM8_serial_flasher to run with "sudo“ permission…?
  • additional STM8 project "BSL_activate“, which can be flashed via SWIM and which enables the bootloader via option bytes
Today I tested the following setups (see Wiki in above Github):
  • RasPi B model 2 / STM8 Discovery Board with UART-UART and automatic reset
  • RasPi B model 2 / STM8 custom board with USB-UART and manual reset
  • MacOS X 10.10.3 / STM8 custom board with USB-UART and manual reset
  • Win Vista SP2 / STM8 custom board with USB-UART and manual reset
The easiest way to test it is to compile both "STM8_serial_flasher" and project "BSL_activate" via "make". Then type "make serial“ to flash the STM8 (if settings at bottom of Makefile are correct)… 

Have fun!  :-)

Regards,
Georg Icking-Konert

------------------------------------------------------------------------------
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Maarten Brock | 20 Jun 22:29 2015
Picon

SDCC 3.5.0 Release Candidate 2

Hello SDCC friends,

The second Release Candidate for SDCC 3.5.0 has just been put online.

For RC1 there was no test result from anyone, neither positive nor
negative. I wonder if that means it was pretty OK, nobody tested, nobody
noticed or even nobody cared. Still I ask again:

If you have the time, please verify it and report back with the positive
or negative results.

May the Source be with you,
Maarten Brock

------------------------------------------------------------------------------
Philipp Klaus Krause | 17 Jun 19:34 2015
Picon

FOSDEM talk video

At FOSDEM 2015, there was a talk on sdcc, which was recorded.
I haven't watched it yet, but noticed the video is online now (probably
has been for some time):

Philipp

------------------------------------------------------------------------------
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Maarten Brock | 9 Jun 23:55 2015
Picon

(no subject)

Hello SDCC friends,

Today the first Release Candidate (RC1) for SDCC 3.5.0 has been created.
As always it has been put online in our SourceForge File section.
https://sourceforge.net/projects/sdcc/files/

If you have the time, please verify it and report back with the positive
or negative results.

May the Source be with you,
Maarten Brock

------------------------------------------------------------------------------
Simon Dible | 9 Jun 17:09 2015
Picon

Re: Sdcc-user Digest, Vol 108, Issue 1


On 06/06/2015 13:00, sdcc-user-request@... wrote:
> Hi Philipp,
>
> you were quicker:) Simon, you probably have a chance to work around it with peephole rules requiring no
compiler modification at all.
>
>
> Idea is to use the JB bit,rel instruction to access the bit, peephole rule for that could look similar to:
>
>
> replace {
>          mov     c,%1
> } by {
>          ;       Peephole 1000.a     mov c,%1 workaround fix
> 	; push acc
>          jb	%1, . + x     ; adapt relative jump
> 	clrb	c
>          sjmp    . + y         ; adapt relative jump
>          setb    c
> 	; pop acc
> }
>
>
> Greetings,
> Frieder

HI,

Thanks for replying so fast and for the pointers with the peephole 
optimization rules, this appears to do exactly what I need. The same bug 
also exists in silicon on the CSR101x pio controller core, but currently 
its only use as31 so people are told to steer clear of those instructions.

Simon

------------------------------------------------------------------------------
Simon Dible | 5 Jun 16:12 2015
Picon

Prevent using broken instructions

Hi

I'm working on an 8051 FPGA image that has broken logical operations on 
the carry flag, at this time its not viable to fix them. Is there some 
way to make sdcc for the 8051 not generate these instructions, or work 
out what C code would generate them to avoid using it?

ORL C, /bit
ORL C, bit
ANL C, /bit
ANL C, bit
MOV C, bit

Many thanks
Simon

------------------------------------------------------------------------------
Giri Pushpanathan | 26 May 16:47 2015

Internal RAM Layout

Compiler version:2.6

HW:8051s (Microsemi)

 

I am using Soft Console IDE which uses SDCC.

The generated internal RAM map uses space from 0x46 to 0xFF; I thought SFRs start at 0x80.

Does the compiler needs to be told explicitly not to go beyond 0x7F?

I do intend to get the newer version of SDCC.

 

Internal RAM layout:

      0 1 2 3 4 5 6 7 8 9 A B C D E F

0x00:|0|0|0|0|0|0|0|0|I|I|I|I|I|I|I|I|

0x10:|I|I|I|I|I|I|I|I|a|a|a|a|a|a|a|a|

0x20:|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|

0x30:|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|

0x40:|b|Q|Q|Q|Q|Q|S|S|S|S|S|S|S|S|S|S|

0x50:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0x60:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0x70:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0x80:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0xa0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0xb0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0xc0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0xd0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0xe0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0xf0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|

0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, S:Stack, A:Absolute

 

Stack starts at: 0x46 (sp set to 0x45) with 186 bytes available.

 

Other memory:

   Name             Start    End      Size     Max    

   ---------------- -------- -------- -------- --------

   PAGED EXT. RAM                         0      256  

   EXTERNAL RAM     0x0000   0x08c9    2250    65536  

   ROM/EPROM/FLASH  0x0000   0x3863   14436    65536  

 

 

Thanks,

Giri

 

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
hernani | 20 May 11:20 2015
Picon

error: 25: Structure/Union expected left of '.->'

hello,

i have this code and give me this errors--->
i put line numbers and bold where give me errors


5.c:53: warning: warning 112: function 'Delay_ms' implicit declaration

p, li { white-space: pre-wrap; }

5.c:53: error: 101: too many parameters 

5.c:91: warning: warning 112: function 'Delay_ms' implicit declaration 

5.c:88: error: 25: Structure/Union expected left of '.->' 

5.c:89: error: 25: Structure/Union expected left of '.->' 

5.c:90: error: 25: Structure/Union expected left of '.->' 

5.c:91: error: 101: too many parameters 

5.c:92: error: 25: Structure/Union expected left of '.->' 

5.c:101: warning: warning 112: function 'Delay_ms' implicit declaration 

5.c:98: error: 25: Structure/Union expected left of '.->' 

5.c:99: error: 25: Structure/Union expected left of '.->' 

5.c:100: error: 25: Structure/Union expected left of '.->' 

5.c:101: error: 101: too many parameters 

5.c:102: error: 25: Structure/Union expected left of '.->'



--------------------------------------------------------------------- */
/* Template source file generated by piklab */
#include <pic18f4550.h>

/* ----------------------------------------------------------------------- */
/* Configuration bits: adapt to your setup and needs */


// Program to interface 16x2 LCD with PIC18F4550 Microcontroller using 4-bit mode

// Configuration bits
/* _CPUDIV_OSC1_PLL2_1L, // Divide clock by 2
_FOSC_HS_1H, // Select High Speed (HS) oscillator
_WDT_OFF_2H, // Watchdog Timer off
MCLRE_ON_3H // Master Clear on
*/

//LCD Control pins
#define rs LATA.F0
#define rw LATA.F1
#define en LATA.F2

//LCD Data pins
#define lcdport LATB

void lcd_ini();
void dis_cmd(unsigned char);
void dis_data(unsigned char);
void lcdcmd(unsigned char);
void lcddata(unsigned char);

void main(void)
{
unsigned char data0[]="EngineersGarage";
unsigned int i=0;
TRISB=0; // Configure Port B as output port
LATB=0;
lcd_ini(); // LCD initialization
while(data0[i]!='\0')
{
dis_data(data0[i]);
53-> Delay_ms(200);
i++;
}
}
void lcd_ini()
{
dis_cmd(0x02); // To initialize LCD in 4-bit mode.
dis_cmd(0x28); // To initialize LCD in 2 lines, 5x7 dots and 4bit mode.
dis_cmd(0x0C);
dis_cmd(0x06);
dis_cmd(0x80);
}

void dis_cmd(unsigned char cmd_value)
{
unsigned char cmd_value1;
cmd_value1 = (cmd_value & 0xF0); // Mask lower nibble because RB4-RB7 pins are being used
lcdcmd(cmd_value1); // Send to LCD
cmd_value1 = ((cmd_value<<4) & 0xF0); // Shift 4-bit and mask
lcdcmd(cmd_value1); // Send to LCD
}


void dis_data(unsigned char data_value)
{
unsigned char data_value1;
data_value1=(data_value&0xF0);
lcddata(data_value1);
data_value1=((data_value<<4)&0xF0);
lcddata(data_value1);
}

void lcdcmd(unsigned char cmdout)
{
lcdport=cmdout; //Send command to lcdport=PORTB
88-> rs=0;
89-> rw=0;
90-> en=1;
91-> Delay_ms(10);
92-> en=0;
}

void lcddata(unsigned char dataout)
{
lcdport=dataout; //Send data to lcdport=PORTB
98-> rs=1;
99-> rw=0;
100-> en=1;
101-> Delay_ms(10);
102-> en=0;
}

p, li { white-space: pre-wrap; }
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
hernani | 19 May 18:31 2015
Picon

help with code in c

hello,

i use piklab and sdcc in linux.

i have this code over internet and give me this error -->

4.c:11: error: token -> '0x3F3A' ; column 15 line 11 is bold


can someone help me??

sorry my english i'm portuguese.


thank you

p, li { white-space: pre-wrap; }

#include <pic16f877a.h>

/* ----------------------------------------------------------------------- */
/* Configuration bits: adapt to your setup and needs */
typedef unsigned int word;
word __at 0x2007 CONFIG = _RC_OSC & _WDT_ON & _PWRTE_OFF & _BODEN_ON & _LVP_ON & _CPD_OFF & _WRT_OFF & _DEBUG_OFF & _CP_OFF;

#define _XTAL_FREQ 20e6
11 -> __CONFIG(0x3F3A);
#define RS RB2
#define EN RB1
#define databits PORTD
/*----------------PIC INITIALIZATION------------*/
void pic_init()
{
    TRISB2 = 0;
    TRISB1 = 0;
    TRISD = 0;
}
 
/*-------------LCD FUNCTIONS BEGIN--------------*/
void LCD_STROBE(void)
{
    EN = 1;
    __delay_us(1);
    EN = 0;
}
 
void data(unsigned char c)
{
    RS = 1;
    __delay_us(50);
    databits = (c >> 4);
    LCD_STROBE();
    databits = (c);
    LCD_STROBE();
}
 
void cmd(unsigned char c)
{
    RS = 0;
    __delay_us(50);
    databits = (c >> 4);
    LCD_STROBE();
    databits = (c);
    LCD_STROBE();
}
 
void clear(void)
{
    cmd(0x01);
    __delay_ms(2);
}
 
void lcd_init()
{
    __delay_ms(15);
    cmd(0x38);
    __delay_ms(1);
    cmd(0x38);
    __delay_us(100);
    cmd(0x38);
    cmd(0x28);            // Function set (4-bit interface, 2 lines, 5*7Pixels)
    cmd(0x28);            // Function set (4-bit interface, 2 lines, 5*7Pixels)
    cmd(0x0c);            // Make cursorinvisible
    clear();            // Clear screen
    cmd(0x6);            // Set entry Mode(auto increment of cursor)
}
 
void string(const char *q)
{
    while (*q) {
        data(*q++);
    }
}
 
/*-------------LCD END--------------------*/
 
main()
{
    __delay_ms(50);
    pic_init();
    lcd_init();
    TRISC = 0;
    while (1) {
        cmd(0x80);
        string("HELLO WORLD");
        cmd(0xc0);
        string("IT IS WORKING:-)");
         
    }
}

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Kustaa Nyholm | 13 May 19:32 2015

Issue with 32 bit assignment in interrupt?

Hi,

I've been tracking a wierd problem, 100% repeatable although the
failures vary.

I'm using:

/Users/nyholku/sdcc-3.4.0/bin/sdcc -v
SDCC :
mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc0
8/s08/stm8 3.4.0 #8981 (Apr  5 2014) (Mac OS X i386)
published under GNU General Public License (GPL)

with PIC18F4550

I've tracked the problem down to these four innocent looking statements
in my interrupt routine:

   steppers[0].probePosition = steppers[0].position;
   steppers[1].probePosition = steppers[1].position;
   steppers[2].probePosition = steppers[2].position;
   steppers[3].probePosition = steppers[3].position;

If I comment these out, then all the weird symptoms I've been having
disappear.

The '.probePosition' and '.position' are both 32 bit ints.

Looking at the generated code I see that the compiler generates code:

                     00438 ;       .line   86; stepperirq.c
steppers[0].probePosition = steppers[0].position;
000086 C??? F???      00439         MOVFF   (_steppers + 7), r0x00
00008A C??? F???      00440         MOVFF   (_steppers + 8), r0x01
00008E C??? F???      00441         MOVFF   (_steppers + 9), r0x02
000092 C??? F???      00442         MOVFF   (_steppers + 10), r0x03
000096 50??           00443         MOVF    r0x00, W
000098 ????           00444         BANKSEL (_steppers + 24)
00009A 6F??           00445         MOVWF   (_steppers + 24), B
00009C 50??           00446         MOVF    r0x01, W
                      00447 ; removed redundant BANKSEL
00009E 6F??           00448         MOVWF   (_steppers + 25), B
0000A0 50??           00449         MOVF    r0x02, W
                      00450 ; removed redundant BANKSEL
0000A2 6F??           00451         MOVWF   (_steppers + 26), B
0000A4 50??           00452         MOVF    r0x03, W
                      00453 ; removed redundant BANKSEL
0000A6 6F??           00454         MOVWF   (_steppers + 27), B

which uses the r0x00 etc variables which the compiler defines like:

                      00320 .registers      udata_ovr       0x0000
000000                00321 r0x00   res     1
000001                00322 r0x01   res     1
000002                00323 r0x02   res     1
000003                00324 r0x03   res     1

Somewhere in the back of my mind I seem to recall that 'udata_ovr'
may cause problems if used both in main program and interrupt code.

My interrupt is defined as:

#pragma save
#pragma nojtbound
#pragma nooverlay
void stepperirq() __interrupt(1) {

in order to avoid overlaying.

So could this (use of overlaid compiler generated temp variables in
interrupt
and main program be a problem)???

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.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Kustaa Nyholm | 8 May 06:38 2015

CONFIG in PIC18F4550

Hi,

I've got a weird problem.

I have written a firmware:

https://github.com/nyholku/TOAD4

I have two versions 1.5.3 and 1.5.5 which both work fine for me.

For one user the version 1.5.5 shows very strange symptoms.

This is 100% repeatable, he program 1.5.3 and everything works,
he programs 1.5.5 and strange things start to happen.

We have identical setups starting from OS and the actual application.

He is using binary (.hex) compiled by me with SDCC 3.4.0 so even
the compiler version is out of the equation.

What is different is that he is using PICKit 3 with mplab_ide and
I'm using PICKIt 2 with pk2cmd.

Now, I'm wondering if the CONFIG bits could be different, if
I do not set them all, are the other left in the state they are?

In SDCC?

In the programming stage (PICKit 2/3 mplab_ide/pk2cmc)?

I know, I know, clutching at straws but hey, I'm desperately out
of ideas and things to try...

Some more possibly related info.

1.5.3 was the first version (according to my version control notes)
that used SDCC 3.4.0 before that I was stuck with 2.8.9.

Moving from the old SDCC to the new necessitated the change of the
CONFIG words syntax. Previously I set them all, now I'm don't
set every bit in the source code, only those that I think are
necessary.

But this does not explain why 1.5.3 and 1.5.5 work for me
abd not for him because they both are compiled with the same
SDCC version by me. Unless the after the compiler version change
some CONFIG bits are left 'undefined' and are not programmed in
which case his PIC18F4550 chip could have some CONFIG bits
differently than mine.

To complicate matters I tried to compile 1.5.3 again (after
7 months) and the resulting .hex is not identical to what
archived back then. So maybe, just maybe, the 1.5.3 was originally
compiled with SDCC 2.8.9 and my version control is screwed.

So any thoughts and ideas are welcome at this point!

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.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

Gmane