Re: [Sdcc-user] Z80 Assembly Development
Hello Peter, As stated in the documentation, the ABS areas "automatically invokes OVR" (Page 1-27, .area Directive), so (ABS) or (ABS,OVR) have the same effect, indeed I've tried what you suggested resulting in the same behavior. I think I've managed to workaround this issue in my case. I don't known if it's the best way to solved but is good enough for me. It seems that the sdld linker needs to be explicitly informed where to put the different areas, so I've declared an global symbol at the end of the boot.asm file: ; boot.asm .globl HexToU8, BOOT_END .area _START (ABS) .org 0 ldSP, #0x call HexToU8 BOOT_END: And used the linker flags "-i -b _CODE=BOOT_END -b _START=0" to inform the start address for the areas. The other files that uses the _CODE(REL,CON) area the linker relocate them as expected. Thanks. On 18-08-2016 00:02, Peter Van Epp wrote: > While I don't have sdcc loaded at the moment, and haven't used it > for Z80, isn't the OVR in .area _START (ABS,OVR) indicating that that > segment can be overlayed (which is not what you want)? I'd check the linker > manual or just try removing it and see if your problem goes away. > > Peter Van Epp > > On Wed, Aug 17, 2016 at 11:01:05PM -0300, Augusto Fraga Giachero wrote: >> I've tried what you suggested, linking the boot.rel first results in the >> opposite effect, the _START area gets overwritten by the _CODE area. >> Here a small showcase for the problem I'm having: >> >> >> ; boot.asm: >> .globl HexToU8 >> .area _START (ABS,OVR) >> >> .org 0 >> ldSP, #0x >> call HexToU8 >> > -- > ___ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] Z80 Assembly Development
On Fri, 19 Aug 2016 10:51:41 -0300 Augusto Fraga Giachero wrote: > Hello Peter, > > > As stated in the documentation, the ABS areas "automatically invokes > OVR" (Page 1-27, .area Directive), so (ABS) or (ABS,OVR) have the same > effect, indeed I've tried what you suggested resulting in the same behavior. > > > I think I've managed to workaround this issue in my case. I don't known > if it's the best way to solved but is good enough for me. It seems that > the sdld linker needs to be explicitly informed where to put the > different areas, so I've declared an global symbol at the end of the > boot.asm file: > > > ; boot.asm > > .globl HexToU8, BOOT_END > .area _START (ABS) > .org 0 > ldSP, #0x > call HexToU8 > BOOT_END: > > And used the linker flags "-i -b _CODE=BOOT_END -b _START=0" to inform the > start address for the areas. The other files that uses the _CODE(REL,CON) > area the linker relocate them as expected. It should be sufficient simply to link the startup module first with the start code first in the code segment and just leave _CODE as 0. Alan -- ___ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
[Sdcc-user] getting started with C8051
I'm just trying to write my first C8051 program:
__sfr __at(0xa0) P2;
__sfr __at(0xa6) P2MDOUT;
__sfr __at(0xe2) XBR1;
unsigned long int u = 0;
#define u 0ul
void main(void)
{
// Enable port output
XBR1 = 0x40;
P2MDOUT = 0x0c;
for(;;)
P2 = ((u / 10) & 0x03) << 2;
}
My board has LED on the P2.2 and P2.3. This program turns them off. But
when I remove the "#define u 0ul" line the LEDs are on.
I compile using
sdcc test.c
and put the program onto the µC using
ec2writeflash --port USB --hex /tmp/test.ihx
Philipp
P.S.: Using
sdcc 3.6.2 #9727
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] getting started with C8051
> I'm just trying to write my first C8051 program:
>
> __sfr __at(0xa0) P2;
> __sfr __at(0xa6) P2MDOUT;
> __sfr __at(0xe2) XBR1;
>
> unsigned long int u = 0;
> #define u 0ul
>
> void main(void)
> {
> // Enable port output
> XBR1 = 0x40;
> P2MDOUT = 0x0c;
>
> for(;;)
> P2 = ((u / 10) & 0x03) << 2;
> }
>
> My board has LED on the P2.2 and P2.3. This program turns them off. But
> when I remove the "#define u 0ul" line the LEDs are on.
> I compile using
> sdcc test.c
> and put the program onto the µC using
> ec2writeflash --port USB --hex /tmp/test.ihx
>
> Philipp
>
> P.S.: Using
> sdcc 3.6.2 #9727
Something that every SiLabs C8051Fxxx user bumps into as the first issue
is that the watchdog is enabled by default at shortest interval and that
our crt routines take longer than this interval. You should add an
_sdcc_external_startup() function that disables the watchdog. Some have
the watchdog in the PCA and some have a seperate one.
unsigned char _sdcc_external_startup(void)
{
WDTCN = 0xde;
WDTCN = 0xad;// Disable watchdog timer on e.g. C8051F120
PCA0MD &= ~0x40; // WDTE = 0 on e.g. C8051F340
return 0;// perform normal initialization
}
Maarten
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] getting started with C8051
> I'm just trying to write my first C8051 program:
>
> __sfr __at(0xa0) P2;
> __sfr __at(0xa6) P2MDOUT;
> __sfr __at(0xe2) XBR1;
>
> unsigned long int u = 0;
> #define u 0ul
>
> void main(void)
> {
> // Enable port output
> XBR1 = 0x40;
> P2MDOUT = 0x0c;
>
> for(;;)
> P2 = ((u / 10) & 0x03) << 2;
> }
>
> My board has LED on the P2.2 and P2.3. This program turns them off. But
> when I remove the "#define u 0ul" line the LEDs are on.
> I compile using
> sdcc test.c
> and put the program onto the µC using
> ec2writeflash --port USB --hex /tmp/test.ihx
>
> Philipp
Hi, I created some small examples for the C8051F***
https://github.com/merbanan/C8051F300_examples
I tried these examples on a F340 but something doesnt work correctly when
I send data over the serial port and sdcc. If I use Keil it works fine.
And the same code works fine on the F300.
I'd be happy to supply you with hardware if you are interested to
investigate the issue. Currently I use Keil which works with what I want
to do, but doing open stuff and needing a non free compiler causes an itch
I want to scratch.
MvH
Benjamin Larsson
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
Re: [Sdcc-user] getting started with C8051
>> I'm just trying to write my first C8051 program:
>>
>> __sfr __at(0xa0) P2;
>> __sfr __at(0xa6) P2MDOUT;
>> __sfr __at(0xe2) XBR1;
>>
>> unsigned long int u = 0;
>> #define u 0ul
>>
>> void main(void)
>> {
>> // Enable port output
>> XBR1 = 0x40;
>> P2MDOUT = 0x0c;
>>
>> for(;;)
>> P2 = ((u / 10) & 0x03) << 2;
>> }
>>
>> My board has LED on the P2.2 and P2.3. This program turns them off. But
>> when I remove the "#define u 0ul" line the LEDs are on.
>> I compile using
>> sdcc test.c
>> and put the program onto the µC using
>> ec2writeflash --port USB --hex /tmp/test.ihx
>>
>> Philipp
>
> Hi, I created some small examples for the C8051F***
>
> https://github.com/merbanan/C8051F300_examples
>
> I tried these examples on a F340 but something doesnt work correctly when
> I send data over the serial port and sdcc. If I use Keil it works fine.
> And the same code works fine on the F300.
>
> I'd be happy to supply you with hardware if you are interested to
> investigate the issue. Currently I use Keil which works with what I want
> to do, but doing open stuff and needing a non free compiler causes an itch
> I want to scratch.
>
> MvH
> Benjamin Larsson
Hello Benjamin,
Using a delay loop counting a non-volatile variable is asking for trouble.
This code has no side effects and can be completely removed by compiler
optimizations. And with an F340 running twice as fast as as an F300 the
delay won't be the same either.
A proper solution is to check the TI flag before starting every transmit.
Maarten
--
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
