dennis wrote:
> It seems the declarations and initialization of the xdata are what is
> breaking my firmware. The following is broken:
> > xdata BYTE buf[100];
> > xdata WORD count=0;
> If I instead initialize count to 0 inside main(), the firmware runs
> correctly:
>
> xdata BYTE buf[1
hi frieder --
frieder wrote:
> [EMAIL PROTECTED] schrieb:
> > along those lines, has anyone been successful at running the Keil
> > compiler .exe pieces under Wine? i did the experiment at one point,
> > and got the compiler to run, but since i hadn't configured a license
> > key (i didn't w
xiaofan wrote:
> On Thu, Sep 4, 2008 at 5:35 PM, Matthew Smith <[EMAIL PROTECTED]> wrote:
> > However, I think that most would say that a Windows
> > programme is one that interacts directly with the Windows API/GUI -
> > which would exclude all command-line programmes.
>
> It is correct to
bobby wrote:
> They are separate issues, but there is a common thread running through
> both. For example, remembering that "SDCC is a free software", or "feel
> free to do better if you can", doesn't provide me with a lot of comfort.
> Statements such as these recognize, explain and/or excu
didier wrote:
> Reusing the space occupied by a global variable would be very
> bad indeed. Is it what is happening here?
yes. sorry i wasn't clear in my earliest mail.
it happens because of the way sdcc treats "char at 0xf000 foo;".
it apparently doesn't actually enter "foo" into the symbol
didier wrote:
> Would'nt the "static" keyword take care of that?
i'm not sure how that would help.
>
> Is it that you want to know where the variable resides, or
> simply to make sure the memory space is not overlaid with
> another variable?
well, it's never my intention to inadvertently u
i've recently discovered sdcc's (highly unusual :-) trick of
letting two variables overlap, without much in the way of
user warning.
i have variables in xdata on an 8051 that need to be "locked
down" with something like:
unsigned char at GLOBAL_V_LOCATION+0x86 FooBar;
it turns out that sdcc wil
frieder wrote:
> Hi Arkadi
>
> Arkadi Shishlov schrieb:
> > Is it possible to get a warning from the compiler for suspicious lines of
> code like
> > some_var == 123;
> > that makes little sense.
> > ?
>
> Indeed!)
>
> This one probably makes even less sense but also
> passes witho
richard wrote:
> What is it that you fellows use to simulate 805x ASM code? I've found that
> the simulator bundled with SDCC for Windows doesn't operate on code that
> spans over 2 KB of memory, and I find I can't buy a "full" version of that
> simulator, as the company that owns/owned it
hi frieder --
frieder wrote:
> Hi,
>
> [EMAIL PROTECTED] schrieb:
> > 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|b|b|b|b|c|Q|Q|Q|
> > 0x10:|Q|Q|Q|Q|Q|Q| | | | | | | | | | |
> > 0x20:|B|T|a|a|a|a|a|a|a|a|a|a|a|a|a|a|
> > 0x30:|a|a|a|a|a|a|a|a|
maarten wrote:
> Hello Paul,
>
> They currently represent memory allocated in DSEG in
> different modules. If they are not in the .map file it
> means they come from library modules.
thank you maarten.
paul
=-
paul fox, [EMAIL PROTECTED]
-
hi -- can someone tell me how to understand the "Data" locations
(i.e, those labeled with 'a', 'b', and 'c' below) in the .mem
file? i can't seem to find corresponding entries in the .map file.
i think i must be missing something obvious.
paul
Internal RAM layout:
0 1 2 3 4 5 6 7 8 9 A B
frieder wrote:
> Hi,
>
> [EMAIL PROTECTED] schrieb:
> > [ beware -- list-crosspost ]
> >
> > it seems that at least some of the instability that i've been
> > seeing is that the interrupt routines (and/or some of the
> > routines they call) weren't reentrant, when i thought they would
>
[ resend to sdcc-users -- botched address first time. ]
hi -- i started this conversation privately with frieder the
other day, and he correctly pointed out that it would be better
taken to the openec or sdcc lists. so here i am. frieder has
already addressed some of my issues, but i'll include
14 matches
Mail list logo
