Maarten,
It's an ADuC832 8051 compatible from Analog Devices.
I did some research about _sdcc_startup_external and read the datasheet of
the controller again and inserted the following into my code:
unsigned char _sdcc_external_startup(void)
{
CFG832 |= 0x01;
return 0;
}
Since i enabled the LSB of that special function register, the 2k internal
RAM is mapped in the XRAM space starting from address 0
When i do the following now:
unsigned char * test;
test = (unsigned char *) malloc(1);
*test = 0x05;
P2 = ~(*test); // inversion cause P2 contains leds that are powered on with
a 0
I see 2 happy leds forming the binary number 5 :)
Now that's a happyness creator! :)
Thank you very much for the humangeous tip :) i just had not the experience
with this things yet.
Kind regards
Bart
2009/7/21 Maarten Brock <sourceforge.br...@dse.nl>
> Bart,
>
> Did you ever mention which mcu you're using? You say it has 2kB of
> internal ram. But have you checked if you need to enable it? SDCC will not
> do that for you! The best place to do it is in _sdcc_external_startup().
>
> Maarten
>
> > Hello Bodo & Maarten
> >
> > My apologies for the very late reply, i was very busy at work with
> getting
> > these things done but without the malloc cause i had some deadline
> > pressure.
> >
> > For the moment of this mail i'm not able to look at the outputs with a
> > scope
> > or something so i will do that as soon as i get back in the lab at work.
> I
> > neither have a simulator about the specific controller.
> >
> > Another problem is that i can't put the value of the pointer to my output
> > LED's on P2, type mismatch he says + i can't shift a pointer, compile
> > error,
> > that i understand, as for as i know only + and - are allowed operations
> on
> > pointers so i'm not sure how to view the values of the other bytes of the
> > pointers.
> >
> > I don't think it's an hardware problem, i forgot to mention that in this
> > case i'm only working with the internal program flash memory of my
> > controller and it's internal ram.
> > There is no external flash or ram connected.
> > I only know he has about 62k program flash, 4k data flash, 2048 bytes
> ram,
> > all of them are on chip.
> >
> > I don't know if i need to enable something to use the ram for malloc, as
> > far
> > i read in the sdcc manual, sdcc takes care of it so i didn't mind about
> > that.
> >
> > Again sorry for the late reply and i will test my output pins asap and
> let
> > you people know the results.
> >
> > Very much thx for all the replies
> >
> > Kind regards
> >
> > Bart
> >
> > 2009/7/4 Bodo Wenzel <bodowen...@web.de>
> >
> >> Hi Bart,
> >>
> >> Your analysis is well done, and I appreciate your assembler knowledge.
> >>
> >> However, I'm not sure that I do understand what you mean by "Gives
> >> nothing
> >> on
> >> the output port P2." For the moment I assume that each line of P2
> >> doesn't
> >> change its level, i.e. it stays at "1" which is the default after a
> >> reset.
> >> So
> >> it's possible that P2 is written with 0xFF.
> >>
> >> BTW, you can check such a write with a pulldown resistor that lowers the
> >> voltage at a pin down to 3/4 or 1/2 of VCC. An oscilloscope will show
> >> the
> >> write access with a small impulse to VCC because the 8051 ports will
> >> reduce
> >> the builtin pullup value for two clock cycles.
> >>
> >> My suggestion for the next steps would be:
> >>
> >> If you can't use a simulator with the hex file, and if the only
> >> watchable
> >> output is P2,
> >>
> >> 1. Run three tests, each setting P2 with one byte of the generic
> >> pointer.
> >>
> >> 2. Check that the external (or internal?) memory at that address is
> >> working
> >> or
> >> at least should be by the schematics.
> >>
> >> 3. Invert the value before assigning it to P2, like "P2 = ~*stream;" I'd
> >> expect then every bit at "0".
> >>
> >> If you have a simulator at hand, run the program with it. Well, you will
> >> have
> >> to step through the builtins, but perhaps the simulator can run a
> >> subroutine
> >> as one step.
> >>
> >> Another issue is the malloc stuff. I'm not using SDCC currently and so I
> >> don't
> >> know how it works here. But I played a bit with z88dk, and there I had
> >> to
> >> set
> >> up malloc with some special functions and variables to get it working.
> >>
> >> To say it shortly, these are the two most probable reasons:
> >>
> >> - The memory pointed to by the return value of malloc() can't store
> >> anything
> >> because of a hardware problem. So a read from it returns 0xff which can
> >> be
> >> the value of an open databus.
> >>
> >> - malloc() returns an arbitrary but reproducable pointer because the
> >> allocation management is not initialized. And the memory pointed to
> >> can't
> >> store any value and always returns 0xFF.
> >>
> >> Bodo
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> 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
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
