From: WWW A. <am...@ai...> - 2005-06-26 09:00:05
|
Hi, I have been using SDCC to port the Contiki OS (http://www.sics.se/~adam/contiki/) to the Amstrad CPC 8-bit computer. (Z80 CPU, 64k RAM) I have made good progress and a binary of it can be downloaded here (http://andercheran.aiind.upv.es/~amstrad/download/contiki12d1.zip). This can be run on most Amstrad emulators. To get the port to this stage I have done the following to SDCC: - Modified link-z80 so that it will generate relocation data. This data is appended to the end of the generated binary file. When the file is loaded a Z80 function uses this data to relocate the file to an absolute address. This is used in the module loader of Contiki. - I have created some peephole optimisatuions which make use of the relative jump (JR) of the Z80. - I have started to work on the Z80 backend to make it emit more optimal code. - I have modified some of the tools; and made some of my own to help build Amstrad binary files using SDCC. The source to Contiki can be downloaded here: http://andercheran.aiind.upv.es/~amstrad/download.html Here you can also find my tools and my patches to SDCC. My aim is to have Contiki OS running a webserver on the Amstrad 8-bit computer which will serve webpages to the internet. Unfortunatly SDCC code generation in my opinion is not optimal, and I don't have the memory left to run the OS, graphics driver and webserver together. So this is the reason I am working on the z80 backend now. I am hoping to make it generate more optimal code so I can run all of these elements together. I would like to commit my changes to CVS so that they could become part of the next release of SDCC. Who do I contact regarding this? Many thanks Kevin Thacker |
From: Richard E. <ed...@id...> - 2005-06-27 14:58:11
|
Has anyone successfully used SDCC in combination with the Maxim/Dallas 89C4x0 types? Does it actually utilize the second data pointer, and/or other features of that device series, e.g. extended SFR set? You'd think it would be pretty popular ... What "special" treatment does it require? RE |
From: Frieder F. <fri...@we...> - 2005-06-27 17:09:40
|
Hi, Richard Erlacher wrote: > Has anyone successfully used SDCC in combination with the Maxim/Dallas > 89C4x0 types? There are definitions for the DS89C420 in the combined include file mcs51reg.h (since Nov 9, 2000). The file is part of the distribution. A direct link: http://cvs.sourceforge.net/viewcvs.py/sdcc/sdcc/device/include/mcs51/mcs51reg.h?view=markup > Does it actually utilize the second data pointer, and/or > other features of that device series, e.g. extended SFR set? You'd It's supported as a plain 8051 with no fancy features. If you want to make use of dptr toggle/increment tricks you could use inline assembly. This is comparatively easy with SDCC. Remember to disable interrupts when using any of the "auto DPTR stuff" autoincrement/autodecrement/autotoggling. Greetings, Frieder |
From: Richard E. <ed...@id...> - 2005-06-27 17:15:12
|
Thanks for this information. This gives rise to yet another question, however, and that's, "How can I persuade the software to execute code in the 1 KB MOVX RAM? Is there some trick to this? Can it be done with a call or other control transfer without discrete "fiddling" with CPU resources?" thanks, RE ----- Original Message ----- From: "Frieder Ferlemann" <fri...@we...> To: <sdc...@li...> Sent: Monday, June 27, 2005 11:09 AM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > Hi, > > Richard Erlacher wrote: >> Has anyone successfully used SDCC in combination with the Maxim/Dallas >> 89C4x0 types? > > There are definitions for the DS89C420 in the combined include file > mcs51reg.h > (since Nov 9, 2000). The file is part of the distribution. A direct link: > http://cvs.sourceforge.net/viewcvs.py/sdcc/sdcc/device/include/mcs51/mcs51reg.h?view=markup > > > Does it actually utilize the second data pointer, and/or >> other features of that device series, e.g. extended SFR set? You'd > > It's supported as a plain 8051 with no fancy features. > > If you want to make use of dptr toggle/increment tricks > you could use inline assembly. This is comparatively easy > with SDCC. > Remember to disable interrupts when using any of the > "auto DPTR stuff" autoincrement/autodecrement/autotoggling. > > Greetings, > Frieder > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Dave M. <mc...@ne...> - 2005-06-27 17:26:07
|
Richard Erlacher wrote: > This gives rise to yet another question, however, and that's, "How can I > persuade the software to execute code in the 1 KB MOVX RAM? Is there > some trick to this? Can it be done with a call or other control > transfer without discrete "fiddling" with CPU resources?" mcs51 is a Harvard architecture, with separate code and data memories. Unless the Maxim/Dallas parts do something very strange (and architecturally incompatible with mcs51), this won't be possible. -Dave -- Dave McGuire Cape Coral, FL |
From: Richard E. <ed...@id...> - 2005-06-27 20:34:09
|
There are some specific features of this particular family that enable code execution from the MOVX RAM, specifically, allowing it to occupy either code or data space. My interest in it is limited, but for little more than academic reasons, I'm interested in exploiting the feature that it (the 89C420) can be induced to run code at 50 MHz from the RAM, but not quite at that speed from the flash. Several years ago, when I first took an interest in these ultra-high-speed devices, I was interested because the spec indicated the parts would operate at that (50 MHz) rate. When the parts became real, i.e. when production was upon us, it turned out that the FLASH read process wouldn't operate at that speed, so the mfg lowered the spec to 33 MHz, which works fine. However, it is, at least in theory, still possible to put some code in that MOVX RAM, which would then enable one to execute it a 50 MHz. I'm not sure there are many applications for this, but, as soon as I declare there are none, someone will surely produce it. I can imagine a digital filter or some such that would benefit, say, from operating under normal conditions at 24 MHz and then, prior to entering the code in the MOVX RAM, change the oscillator multiplier from 2x to 4x and execute that code at 48 MHz. Something like that might come up sometime. Now, there's due to be new silicon out next month. There's no telling, so far, whether that will still support this characteristic. There are other interesting features, involving external memory interface operation, that have me captivated as well. If you're not "up to speed" on these, they fall under the heading of "page" modes, of which there are two. In one case, by setting some internal SFR parameters, rather than multiplexing the low address byte and the current data byte on P0, they mux both bytes of the address on P2 and hold data static on P0. This can help with setup and hold times on data when running at ultra-high speed (remember, their instruction cycle is only one clock tick long, in most cases). In the other page mode, data and the high address byte are muxed on P2, while the low address byte remains static on P0. That can help with decoding tree propagation delays. Because the CPU core is aware of the next and last address, it knows when it can skip the mux cycle, as the upper byte (page address) doesn't change, so it skips that step. The result is that external memory accesses that might take two clock ticks in the "usual" mode, take only one. When this feature set is combined with the single-clock-cycle execution of the MCU, it turns out to be very fast, indeed. You've also mentioned the data-pointer-specific operations such as auto-increment and -decrement which might be highly interesting as performance enhancements. However, if it's easy enough to use inline assembler, those can be implemented as such. regards, RE Denver, CO ----- Original Message ----- From: "Dave McGuire" <mc...@ne...> To: <sdc...@li...> Sent: Monday, June 27, 2005 11:25 AM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > Richard Erlacher wrote: >> This gives rise to yet another question, however, and that's, "How can I >> persuade the software to execute code in the 1 KB MOVX RAM? Is there >> some trick to this? Can it be done with a call or other control transfer >> without discrete "fiddling" with CPU resources?" > > mcs51 is a Harvard architecture, with separate code and data memories. > Unless the Maxim/Dallas parts do something very strange (and > architecturally incompatible with mcs51), this won't be possible. > > -Dave > > -- > Dave McGuire > Cape Coral, FL > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Peter <pl...@ac...> - 2005-06-27 21:44:21
|
I don't know how the MOVX space becomes CODE space but it the how is somewhat similar to paging, as done on plain MCS51 with external SRAM decoded as ROM then all you have to do is write an overlay relay in the area where the paging occurs. This can be as simple as writing functions with identical definitions and linking them (separately) at the same address. one is in the main program and acts as a stub and the other is constants in CODE space which you load into MOVX and then call your page switch stub (the stub exists in both codespaces - you can ensure that the join is where it should be by examining the annotated listing output files from the compiler). Peter |
From: Richard E. <ed...@id...> - 2005-06-27 22:25:04
|
Well, these guys have SFR bits used to adjust the memory map, and one of the options is to mape the internal MOVX RAM, of which there's only 1KB, into either code or data space. It's possible to be able control on the order of 80KB of code space and I'm not sure where the upper limit on data space is, but there's no external paging hardware required. They've provided the hardware necessary to enable you to map the movx space into code space. Since all but one of these guys have a hole in the code space, I doubt it would be a problem, and probably it wouldn't be rocket science anyway. It's just a convenience, I guess, if you want to use it. From what I've gathered, however, it's not necessary to map the MOVX block into data space in order to write it, then into code space to use it, though I could easily be wrong about that. I'm convinced it's an interesting feature, however it works. RE ----- Original Message ----- From: "Peter" <pl...@ac...> To: <sdc...@li...> Sent: Monday, June 27, 2005 3:44 PM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > > I don't know how the MOVX space becomes CODE space but it the how is > somewhat similar to paging, as done on plain MCS51 with external SRAM > decoded as ROM then all you have to do is write an overlay relay in the > area where the paging occurs. This can be as simple as writing functions > with identical definitions and linking them (separately) at the same > address. one is in the main program and acts as a stub and the other is > constants in CODE space which you load into MOVX and then call your page > switch stub (the stub exists in both codespaces - you can ensure that the > join is where it should be by examining the annotated listing output files > from the compiler). > > Peter |
From: panocomp <pan...@gm...> - 2005-06-28 15:32:40
|
For the DS80C400 is a Maxim App.Note using this device with sdcc http://www.maxim-ic.com/appnotes.cfm/appnote_number/3346 Bye Wolfgang |
From: panocomp <pan...@gm...> - 2005-06-28 15:38:25
|
I forgot For the DS89C4xx family the Maxim App.Note using this device with sdcc is http://www.maxim-ic.com/appnotes.cfm/appnote_number/3477 Bye Wolfgang |
From: Richard E. <ed...@id...> - 2005-06-28 15:43:16
|
Yes, that one. My question, however, is, "What experiences have members of this forum had with these devices and SDCC?" regards, Richard Erlacher ----- Original Message ----- From: "panocomp" <pan...@gm...> To: <sdc...@li...> Sent: Tuesday, June 28, 2005 9:34 AM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts >I forgot > For the DS89C4xx family the Maxim App.Note using this device with sdcc > is > > http://www.maxim-ic.com/appnotes.cfm/appnote_number/3477 > > Bye Wolfgang > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Richard E. <ed...@id...> - 2005-06-28 15:41:32
|
The app note that's supposed to be THE app note is http://www.maxim-ic.com/appnotes.cfm/appnote_number/3477, since it deals with the devices in question rather than the 80C400, which is closer to the 80C320. Unfortunately, it doesn't answer as many questions as it creates. RE ----- Original Message ----- From: "panocomp" <pan...@gm...> To: <sdc...@li...> Sent: Tuesday, June 28, 2005 9:29 AM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > For the DS80C400 is a Maxim App.Note using this device with sdcc > > http://www.maxim-ic.com/appnotes.cfm/appnote_number/3346 > Bye Wolfgang > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: andrew barton-s. <an...@sw...> - 2005-06-29 19:41:40
|
Hello, I have installed the latest gputils and sdcc from cvs on a Windows i386 machine with cygwin GPASM : gpasm-0.13.2 beta SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.5.1 #1050 (Jun 28 2005) (CYGWIN) The SDCC fails to compile a simple program for the PIC18F258. (It fails for other pic's too, and the build for the dem program in the Particle Computer Base fails as well). Note the warning about processor mismatch for crt0i.o and the linker fails an assertion. I have included the output from the build of the simple program and the Makefile and source file. Is it always necessary to place a stack pragma in the source file? Can it be guessed by the compiler? Without the pragma, the build fails with: error: missing definition for symbol "_stack_end", required by "/usr/local/bin/../share/sdcc/lib/pic16/crt0i.o" >>>>>>>>>>>>>>>>>>OUTPUT<<<<<<<<<<<<<<<<<<<<<< abs@cherokee ~/Desktop/wave $ make sdcc -mpic16 -p18f258 -V wave.c Processor: 18f258 + "/usr/local/bin/sdcpp" -nostdinc -Wall -std=c99 -DSDCC=1 -Dpic18f258 -D__18f258 -DSTACK_MODEL_SMALL -DSDCC_MODEL_SMALL -DSDCC_pic16 -D__pic16 -I"/usr/local/bin/../share/sdcc/include/pic16" -I"/usr/local/share/sdcc/include/pic16" "wave.c" wave.c:23: warning: setting stack to default size 64 (0x0040) + "/usr/local/bin/gpasm" -DSDCC_MODEL_SMALL -Dpic18f258 -D__18F258 -DSTACK_MODEL_SMALL -c "wave.asm" -o "wave.o" + "/usr/local/bin/gplink" -I"/usr/local/bin/../share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16" -o wave wave.o crt0i.o pic18f258.lib libsdcc.lib warning: processor mismatch in "/usr/local/bin/../share/sdcc/lib/pic16/crt0i.o" message: using default linker script "/usr/local/share/gputils/lkr/18f258.lkr" assertion "sym != NULL" failed: file "gpcofflink.c", line 203 Signal 6 make: *** [wave.hex] Error 1 >>>>>>>>>>>>>>>>>MAKEFILE<<<<<<<<<<<<<<<<<<< ARCH= pic16 TARGET= 18f258 CC=sdcc AS=gpasm CFLAGS= -m$(ARCH) -p$(TARGET) -V HEX_FILES= wave.hex all: $(HEX_FILES) %.hex: %.c $(CC) $(INCLUDE) $(CFLAGS) $< $(AS) $*.asm clean: -find . -name '*.d' -o -name '*.hex' -o -name '*.asm' -o -name '*.o' -o -name '*.lst' -o -name '*.cod' -o -name '*.map' -o -name '*.lib' | xargs rm >>>>>>>>>>>>>>>>>PROGRAM<<<<<<<<<<<<<<<<<<<< #pragma stack 0x300 #include <pic18fregs.h> void main(void) { unsigned char count; TRISA = 0; count = 0; while(1) { PORTA = count; count++; } } |
From: Raphael N. <ne...@te...> - 2005-06-30 08:41:18
|
Hi Andrew, > GPASM : gpasm-0.13.2 beta and here is the problem -- the latest (?) gputils are broken, I propose you go back to "gputils 0.13.1 alpha" (which is what I am using). I already filed a bug report to the gputils team (dated May 24th), but got no response so far... > SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 > 2.5.1 #1050 (Jun 28 2005) (CYGWIN) > > The SDCC fails to compile a simple program for the PIC18F258. (It fails > for other pic's too, and the build for the dem program in the Particle > Computer Base fails as well). > > Note the warning about processor mismatch for crt0i.o and the linker > fails an assertion. The "processor mismatch" warning must be ignored: it is caused by the fact that some library routines (crt0*.o, libsdcc with arithmetics, pointer derefenrencing routines and other needed stuff) are built only once with the target ipc18f452 (I think). These libraries do only use common features present on all PICs and we save time by compiling them only once. (In fact, I have patched gputils locally to suppress the warning (gplink/gplink.c, search for "processor mismatch" and comment line ~61 out).) > Is it always necessary to place a stack pragma in the source file? Can > it be guessed by the compiler? Without the pragma, the build fails with: > > error: missing definition for symbol "_stack_end", required by > "/usr/local/bin/../share/sdcc/lib/pic16/crt0i.o" Yes, the #pragma stack is always needed (exactly once per project, not source file), as crt0i needs to set up the FSR1 register accordingly (so that arguments and local variables can be transferred/stored safely). Guessing could be done (e.g. always use the last bank avaliable), but currently is not. If I implement it, I will still emit a warning stating that the "stack's position and size has been assumed to be START to END (n bytes)" as this cuts down avaliable memory by 256 bytes (on large enough devices at least...). Hope that helps, Raphael Neider |
From: Matthew S. <ma...@kb...> - 2005-06-27 22:36:18
|
Hi Richard > Has anyone successfully used SDCC in combination with the Maxim/Dallas > 89C4x0 types? Does it actually utilize the second data pointer, and/or > other features of that device series, e.g. extended SFR set? You'd > think it would be pretty popular ... What "special" treatment does it > require? I'm looking at working with 89C4xx devices; I'm using SDCC, but treating the devices as "plain vanilla" 8051s. I believe that a very large percentage of the content of the DS80C400 (TINI) header files available as part of that development kit are useable with the DS89C4xx devices. In the course of my investigations, I joined the forum at <http://discuss.dalsemi.com> - I would recommend this to anyone working with the Dallas product; you may be able to get device-specific answers there that you cannot get anywhere else. Hope this helps. Cheers M --=20 Matthew Smith Work: <http://www.kbc.net.au> | Home: <http://www.mss.cx> The time here is 08:00 and the temperature outside is 14.3=B0C; today's maximum is 14.9=B0C with a minimum of 5.4=B0C. We have had 0.7mm of rain today, with a total of 28.7mm in the last week. The wind is currently due NW, light breeze, force 2 (4.0mph), gusting to light breeze, force 2 (4.8mph). |
From: Richard E. <ed...@id...> - 2005-06-28 00:05:15
|
I've been told by the distributors' FAE that there are VERY SIGNIFICANT differences between the DS80Cxxx and DS89C4x0 devices, beginning with the execution rate, and on into quite a few others. The common instruction set members are probably among the few common elements. I suspect it will be a MAJOR task rebuilding the headers to suit the 89C4x0 series from the 80C400. The problem with such a task is not the difficulty, but the likelihood of error. It's just a tedious compare and contrast job, but one error and the whole thing's in the toilet. Right now I'm trying to "get comfortable" with the notion that a single tool set, e.g. SDCC can adequately support a wide range of products, e.g. 805x, PIC, HC11, HC05, etc. I can accept that they're not alike and that there will be more differences than similarities in the way in which they have to be treated, but learning a single tool is a lot safer and easier than learning three tools or five. What I'd really like to find is a compiler that runs under DOS or Windows that actually works as SDCC does, not so much from the MCU's standpoint, but from that of the user. It's all about error management. RE ----- Original Message ----- From: "Matthew Smith" <ma...@kb...> To: <sdc...@li...> Sent: Monday, June 27, 2005 4:35 PM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts Hi Richard > Has anyone successfully used SDCC in combination with the Maxim/Dallas > 89C4x0 types? Does it actually utilize the second data pointer, and/or > other features of that device series, e.g. extended SFR set? You'd > think it would be pretty popular ... What "special" treatment does it > require? I'm looking at working with 89C4xx devices; I'm using SDCC, but treating the devices as "plain vanilla" 8051s. I believe that a very large percentage of the content of the DS80C400 (TINI) header files available as part of that development kit are useable with the DS89C4xx devices. In the course of my investigations, I joined the forum at <http://discuss.dalsemi.com> - I would recommend this to anyone working with the Dallas product; you may be able to get device-specific answers there that you cannot get anywhere else. Hope this helps. Cheers M -- Matthew Smith Work: <http://www.kbc.net.au> | Home: <http://www.mss.cx> The time here is 08:00 and the temperature outside is 14.3°C; today's maximum is 14.9°C with a minimum of 5.4°C. We have had 0.7mm of rain today, with a total of 28.7mm in the last week. The wind is currently due NW, light breeze, force 2 (4.0mph), gusting to light breeze, force 2 (4.8mph). ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=ick _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Richard E. <ri...@id...> - 2010-07-21 17:02:56
|
Yes, I know this has been a long time coming, but ... why is it important to disable interrupts when using the "auto DPTR stuff", autoincrement/autodecrement/autotoggling? It would appear to me that such processes would be entirely and safely interruptible so long as one ensured the DPTR were not disturbed during ISR's. Maybe I've overlooked something? regards, Richard Erlacher ----- Original Message ----- From: "Frieder Ferlemann" <fri...@we...> To: <sdc...@li...> Sent: Monday, June 27, 2005 11:09 AM Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > Hi, > > Richard Erlacher wrote: >> Has anyone successfully used SDCC in combination with the Maxim/Dallas >> 89C4x0 types? > > There are definitions for the DS89C420 in the combined include file > mcs51reg.h > (since Nov 9, 2000). The file is part of the distribution. A direct link: > http://cvs.sourceforge.net/viewcvs.py/sdcc/sdcc/device/include/mcs51/mcs51reg.h?view=markup > > > Does it actually utilize the second data pointer, and/or >> other features of that device series, e.g. extended SFR set? You'd > > It's supported as a plain 8051 with no fancy features. > > If you want to make use of dptr toggle/increment tricks > you could use inline assembly. This is comparatively easy > with SDCC. > Remember to disable interrupts when using any of the > "auto DPTR stuff" autoincrement/autodecrement/autotoggling. > > Greetings, > Frieder > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: <st...@do...> - 2010-07-24 12:14:25
|
Dallas says this part is obsolete and you should move to the pin compatible alternative for new designs... ____________ Steven Donegan SSCC/NORC Car #86 www.sscc.us --- On Wed, 7/21/10, Richard Erlacher <ri...@id...> wrote: > From: Richard Erlacher <ri...@id...> > Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > To: sdc...@li... > Date: Wednesday, July 21, 2010, 4:44 PM > Yes, I know this has been a long time > coming, but ... why is it important to > disable interrupts when using the "auto DPTR stuff", > autoincrement/autodecrement/autotoggling? It would > appear to me that such > processes would be entirely and safely interruptible so > long as one ensured > the DPTR were not disturbed during ISR's. Maybe I've > overlooked something? > > regards, > > Richard Erlacher > > > > ----- Original Message ----- > From: "Frieder Ferlemann" <fri...@we...> > To: <sdc...@li...> > Sent: Monday, June 27, 2005 11:09 AM > Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas > parts > > > > Hi, > > > > Richard Erlacher wrote: > >> Has anyone successfully used SDCC in combination > with the Maxim/Dallas > >> 89C4x0 types? > > > > There are definitions for the DS89C420 in the combined > include file > > mcs51reg.h > > (since Nov 9, 2000). The file is part of the > distribution. A direct link: > > http://cvs.sourceforge.net/viewcvs.py/sdcc/sdcc/device/include/mcs51/mcs51reg.h?view=markup > > > > > > Does it actually utilize the second data pointer, > and/or > >> other features of that device series, e.g. > extended SFR set? You'd > > > > It's supported as a plain 8051 with no fancy > features. > > > > If you want to make use of dptr toggle/increment > tricks > > you could use inline assembly. This is comparatively > easy > > with SDCC. > > Remember to disable interrupts when using any of the > > "auto DPTR stuff" > autoincrement/autodecrement/autotoggling. > > > > Greetings, > > Frieder > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: Discover Easy Linux > Migration Strategies > > from IBM. Find simple to follow Roadmaps, > straightforward articles, > > informative Webcasts and more! Get everything you need > to get up to > > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Maarten B. <sou...@ds...> - 2010-07-24 10:10:41
|
Hello Richard, Yes, so long as you ensure the DPTR is not touched in the DPTR. That means no function calls and no xdata or code access. Not even C-support functions for generic pointer access or integer multiplication. I recommend to carefully inspect the generated assembler for your ISR's. Maarten > Yes, I know this has been a long time coming, but ... why is it important to > disable interrupts when using the "auto DPTR stuff", > autoincrement/autodecrement/autotoggling? It would appear to me that such > processes would be entirely and safely interruptible so long as one ensured > the DPTR were not disturbed during ISR's. Maybe I've overlooked something? > > regards, > > Richard Erlacher > > > > ----- Original Message ----- > From: "Frieder Ferlemann" <fri...@we...> > To: <sdc...@li...> > Sent: Monday, June 27, 2005 11:09 AM > Subject: Re: [Sdcc-user] Ultra-High-speed Maxim/Dallas parts > > > > Hi, > > > > Richard Erlacher wrote: > >> Has anyone successfully used SDCC in combination with the Maxim/Dallas > >> 89C4x0 types? > > > > There are definitions for the DS89C420 in the combined include file > > mcs51reg.h > > (since Nov 9, 2000). The file is part of the distribution. A direct link: > > http://cvs.sourceforge.net/viewcvs.py/sdcc/sdcc/device/include/mcs51/mcs51reg.h?view=markup > > > > > Does it actually utilize the second data pointer, and/or > >> other features of that device series, e.g. extended SFR set? You'd > > > > It's supported as a plain 8051 with no fancy features. > > > > If you want to make use of dptr toggle/increment tricks > > you could use inline assembly. This is comparatively easy > > with SDCC. > > Remember to disable interrupts when using any of the > > "auto DPTR stuff" autoincrement/autodecrement/autotoggling. > > > > Greetings, > > Frieder |