Re: Memory Weirdness

Dennis,

Initially you had --xram-loc=0x4000, but the FX2 has 
only 16kB RAM so there is nothing at 0x4000 unless you 
have external RAM connected. Without any --xram-loc SDCC 
puts xdata at 0x0000 but unless you have external ROM 
and EA=1 this memory is shared with code memory. So any 
write to xdata 0x0000 and up will overwrite the reset- 
and interrupt vectors and the rest of your program!

During initialization SDCC needs something like P2 on 
the original 8051 to output the high byte of the 
address. For the FX2 this is MPAGE (0x92) and you need 
to tell SDCC about it through defining _XPAGE.  An 
alternative is to reassemble crtxinit.asm for dual data 
pointer use as the FX2 supports that as well.

So if you only have internal memory, you best use --
code-size=0x3000 to limit the generated code size and --
xram-loc=0x3000 and --xram-size=0x1000 to make sure 
xdata does not overlap with code memory.

Maarten

> Dennis Muhlestein wrote:
> > Dennis Muhlestein wrote:
> >> I have a little test program I've been playing with to test different 
> >> variable sizes and locations.  I came across a weird situation and 
> >> I'm hoping someone can help me explain it.
> > I've traced this problem down to a smaller issue.

Re: Memory Weirdness

Maarten Brock wrote:
> Dennis,
> 
> Initially you had --xram-loc=0x4000, but the FX2 has 
> only 16kB RAM so there is nothing at 0x4000 unless you 
> have external RAM connected. Without any --xram-loc SDCC 
> puts xdata at 0x0000 but unless you have external ROM 
> and EA=1 this memory is shared with code memory. So any 
> write to xdata 0x0000 and up will overwrite the reset- 
> and interrupt vectors and the rest of your program!

The Development board does indeed have external ram shared with the code 
space at 0x0000 to 0x4000.  It has 64k total external ram (0x0000 to 
0xffff).  That is why starting at a higher number like 0x4000 works. 
The external memory can be turned off though depending on a couple 
jumper switches so that only up to 0x4000 is available for a program.

> 
> During initialization SDCC needs something like P2 on 
> the original 8051 to output the high byte of the 
> address. For the FX2 this is MPAGE (0x92) and you need 
> to tell SDCC about it through defining _XPAGE.  An 
> alternative is to reassemble crtxinit.asm for dual data 
> pointer use as the FX2 supports that as well.

If using _XPAGE works, I don't see a lot of reason to redo crtxinit.asm. 
  I do wonder if changing the way xdata is used by the compiler in 
general is worth looking at.  i.e., why use _XPAGE if you can always use 
dptr?

Re: PIC16 and proper use of printf()

Hello,

I would continue with the problem. Attached is my test code and LST. I compile C source with
> /opt/sdcc/bin/sdcc -V -mpic16 -p18f2580 main.c
+ "/opt/sdcc/bin/sdcpp" -nostdinc -Wall -Dpic18f2580 -D__18f2580 -DSTACK_MODEL_SMALL -obj-ext=.o
-DSDCC_MODEL_SMALL -DSDCC=284 -DSDCC_REVISION=5252 -DSDCC_pic16 -D__pic16
-I"/opt/sdcc/bin/../share/sdcc/include/pic16" -I"/usr/local/share/sdcc/include/pic16"
-I"/opt/sdcc/bin/../share/sdcc/include" -I"/usr/local/share/sdcc/include" "main.c"
main.c:215: warning 85: in function main unreferenced local variable : 'j'
+ "gpasm" -DSDCC_MODEL_SMALL -DSTACK_MODEL_SMALL -c "main.asm" -o "main.o"
+ "gplink" -I"/opt/sdcc/bin/../share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16"
-I"/opt/sdcc/bin/../share/sdcc/lib" -I"/usr/local/share/sdcc/lib" -w -r -o main main.o crt0i.o
libdev18f2580.lib libsdcc.lib libc18f.lib
message: using default linker script "/usr/share/gputils/lkr/18f2580.lkr"

> /opt/sdcc/bin/sdcc --version
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.8.4 #5252 (Oct 20 2008) (UNIX)

The output below is in HEX as ASCII is unreadable from address 0x1e. It begins with "PIC printf test" but then
in "CAN" loop, output gets garbled.

Does anybody have a clue what is going wrong ?

Thank you,
Vaclav

00000000: 50 49 43 20 70 72 69 6E 74 66 20 74 65 73 74 0A
00000010: 70 72 69 6E 74 66 28 29 20 74 65 73 74 16 FF 83
00000020: CB 3B 1B BB 66 90 FF E7 FF FF C0 78 FF FF FF FF
00000030: FF FF BE 4D B5 7E DF 5A 0A B3 C5 CE C4 C9 DE C7

SDCC with microchip controller stack

Hello,
I'm fairly new to PIC programming on Linux, though I've done a little
with assembler on Windows, a long long time ago...

I recently started a project where I want to use UDP on a PIC18F66J60.
I'd like to use microchip's TCP/IP stack, but I'm not sure how to get it
working with SDCC.

Any ideas or suggestions for different stacks would be appreciated.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

SDCC -mpic14 and TRISB_bits do not work ?

Hello, I use following short code:

#include <pic16f690.h>

void main(void)
{
  // config the application
  OSCCON = 0x70; //8MHz internal clock, sysclock defined in CONFIG
  ANSEL = 0x00;
  ANSELH = 0x00;

  // config SPI
  TRISB_bits.TRISB6 = 0; // SCK
  TRISB_bits.TRISB4 = 1; // SDI
  TRISC_bits.TRISC7 = 0; // SDO

  SSPSTAT = 0x80; // SMP=1, CKP=0
  SSPCON = 0x31; // CKE=1, enable, SPI master, Fosc/16

 while(1) ;

}

During comiplation I get erors:
> sdcc -V -mpic14 -ppic16f690 main.c
+ d:\v\sw\sdcc\bin\sdcpp.exe -nostdinc -Wall -obj-ext=.o -DSDCC_MODEL_SMALL -DSDCC=284
-DSDCC_REVISION=5264 -DSDCC_pic14 -D__pic14 -DSDCC_PROCESSOR="pic16f690" -isystem
"d:\v\sw\sdcc\include\pic14" -isystem "d:\V\sw\sdcc\bin\..\include\pic14" -isystem
"d:\v\sw\sdcc\include" -isystem "d:\V\sw\sdcc\bin\..\include" -isystem
"d:\v\sw\sdcc\include\pic" -isystem "d:\V\sw\sdcc\bin\..\include\pic"  "main.c" 

Re: SDCC -mpic14 and TRISB_bits do not work ?

Hello,

try to write  "TRISB6 = 0;" in place of " TRISB_bits.TRISB6 = 0;"
it should works better.

if not, write "TRISB=0x08;" it do the same jo, and the asm code is  
shorter and faster.

Sorry for my bad english. have fun.

MiGaNuTs

Le 20 nov. 08 à 13:11, Vaclav Peroutka a écrit :

> Hello, I use following short code:
>
> #include <pic16f690.h>
>
> void main(void)
> {
>   // config the application
>   OSCCON = 0x70; //8MHz internal clock, sysclock defined in CONFIG
>   ANSEL = 0x00;
>   ANSELH = 0x00;
>
>   // config SPI
>   TRISB_bits.TRISB6 = 0; // SCK
>   TRISB_bits.TRISB4 = 1; // SDI
>   TRISC_bits.TRISC7 = 0; // SDO
>

Re: SDCC -mpic14 and TRISB_bits do not work ?

> ----------------------------------------
> 
>   TRISB_bits.TRISB6 = 0; // SCK
>  

Hello, I just found that direct TRISB6 = 0; works properly. Even if I would like TRISBbits.TRISB6 = 0; as it is
done for PIC16 port. Is there any plans to synchronize it ?

I have another question. In SDCC manual I did not find it but maybe somebody can help me. I currently
initialize strings like that:
main() {
   __data unsigned char buf[10];

   buf[0] = 'H', buf[1] = 'e'; buf[2] = 'l', buf[3] = 'l', buf[4] = 'o'; buf[5] = 0x0d; buf[6] = 0x00;
   SendString( buf);
}

Is there any more clever way how to initialize buffer with "Hello\n" in data memory ? But I do not want to have
string in program memory and use GPTRGET. Or the way I did it is the only possible way ?

Thank you,
Vaclav

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SDCC -mpic14 and TRISB_bits do not work ?

I don't really see how you can avoid the constant being in the program area, 
but personally I would simply do this, below, although admittedly this would 
pull in some string manipulation library routines. Whatever you do, 
the "Hello\n" string is going to have to be stored somewhere that is not 
volatile in the first instance.

buf="Hello\n";

Another way might be to declare "Hello\n" as a constant, set up a pointer to 
that constant and then dereference the pointer into volatile memory using a 
loop, incrementing the pointer each time around, until the null string 
terminator is encountered, but you're probably not going to save much program 
space over the library routine that does the same job. You could use some 
inline assembly language of course...

On Thursday 20 November 2008 13:44:32 Vaclav Peroutka wrote:
> > ----------------------------------------
> >
> >   TRISB_bits.TRISB6 = 0; // SCK
>
> Hello, I just found that direct TRISB6 = 0; works properly. Even if I would
> like TRISBbits.TRISB6 = 0; as it is done for PIC16 port. Is there any plans
> to synchronize it ?
>
> I have another question. In SDCC manual I did not find it but maybe
> somebody can help me. I currently initialize strings like that: main() {
>    __data unsigned char buf[10];
>
>    buf[0] = 'H', buf[1] = 'e'; buf[2] = 'l', buf[3] = 'l', buf[4] = 'o';
> buf[5] = 0x0d; buf[6] = 0x00; SendString( buf);

Re: SDCC -mpic14 and TRISB_bits do not work ?

> Hello, I just found that direct TRISB6 = 0; works properly. Even if I  
> would like TRISBbits.TRISB6 = 0; as it is done for PIC16 port. Is there  
> any plans to synchronize it ?

You can use
#define NO_BIT_DEFINES 1
#include <pic14regs.h>

to disable bit defines, see the header files.
NO_BIT_DEFINES must be defined *before* including the device header!

> I have another question. In SDCC manual I did not find it but maybe  
> somebody can help me. I currently initialize strings like that:
> main() {
>    __data unsigned char buf[10];
>
>    buf[0] = 'H', buf[1] = 'e'; buf[2] = 'l', buf[3] = 'l', buf[4] = 'o';  
> buf[5] = 0x0d; buf[6] = 0x00;
>    SendString( buf);
> }
>
> Is there any more clever way how to initialize buffer with "Hello\n" in  
> data memory ? But I do not want to have string in program memory and use  
> GPTRGET. Or the way I did it is the only possible way ?

Why not use

void
main (void)
{

[ pic18f, simple program, no crt ]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user