W dniu 2013-06-10 10:46:56 użytkownik Maarten Brock
napisał:
> If SDCC requires the second char then that is a bug.
Second char isn't required.
> Even if SDCC accepts the second char it is a bug.
That is I point out, less explicit than you ;-)
>
> The C standard requires that only the first
W dniu 2013-06-10 00:53:12 użytkownik Antonio Todo Bom
napisał:
YES !
But almost that:
const char * const menu_str[][] = ...
const char * const char menu_str[5][2] =...
char identifier was missing, and we need to declare the number of itens or will
note compile.
And Henry,
My ta
#include <8051.h>
#define RELAY P1_4
#define K1 P2_7
void main()
{
if (!K1) RELAY = 0;
else RELAY = 1;
}
Albert
W dniu 2013-06-07 12:29:50 użytkownik JIA Pei napisał:
To whom it may concern:
I kept obtaining the following error message
error 2: Initializer element is not constant
Hello!
I ported some working code to SDCC (PIC14, SVN ver. 8444).
And probably find bug in sdcc.
Striped down and preprocessed code looks OK
***test.c**
extern __at(0x0007) __sfr PORTC;
typedef struct
{
unsigned RC0 : 1;
OMG. My point of view:
Current wersion PIC16 is OK. We have sfr16 keyword and proper libdev.
In libdev is space allocated for REGL and REGH. Thus for REG too.
In user header files we have declarations:
extern __at(addr) __sfr REGL;
extern __at(addr+1) __sfr REGH;
extern __at(addr) __sfr REG; //3
W dniu 2013-01-13 09:53:00 użytkownik Molnár Károly
napisał:
...
> Something left out of the calculation. In the case of TMRx, differ the read
> and write sequence.
> write: first TMRxH, second TMRxL
> read: first TMRxL, second TMRxH
>
:-)
As for mcs51:
SDCC manual (http://sdcc.sourceforge.ne
On 10. 01. 2013 18:09, Raphael Neider wrote:
...
> So code generation is ready (and a lot of things actually just fall
> into place -- its magic :-D).
> Did you also already use overlapping SFR definitions (TMR1 and TMR1L above)?
...
As /sdcc/device/non-free/lib/pic14/libdev/* is created in sdcc b
On 10. 01. 2013 18:09, Raphael Neider wrote:
> Hi,
>
>> sfr16 keyword exist for pic16.
>
I> t does? Well, that would be news to me ... Does it work?!?
Yes, and works fine. As pic14 with patch from my previous post.
...
> I agree that this feature would be nice. However, this needs support
> in
Hello!
sfr16 keyword exist for pic16.
There is no reason for discard it from pic14 implementation.
Together with change duplicate SFR names in non-free include files from ie:
extern __at(0x000F) __sfr TMR1;
extern __at(0x000F) __sfr TMR1L;
...
to
extern __at(0x000F) __sfr16 TMR1;
extern __at(0
