Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
Discussion Groups | 68HC12 | Re: Metrowerks
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
About Accessing External RAM - Simon Hunter - Jun 27 23:48:00 2002
|
Hi all, Just starting to look at the HCS12 as a replacement for the HC11F1 we have been using for quite some time now. My question at this time is: Is it possible to access an external memory device (say a RAM or EEPROM chip (28C256 for example)) using a HCS12 processor? From what I have read from the data sheets, external memory access is available from specific devices, but what I am looking at doing is using the internal FLASH as program space and both an external RAM and EEPROM (both only 8bit data bus devices) to store information. Has anyone had any experience with doing this and can point me in some sort of direction of data sheets or app notes for the HCS12 series processors. Thanks guys Simon ----- Simon Hunter Technical Engineer / IT Administration Associated Controls (Aust) Pty. Ltd. Unit A/30-34 Hilly Street, Mortlake, NSW, 2137 Australia Telephone: +61 2 8765 9911 Fax: +61 2 8765 9922 Web: http://www.ascon.com.au Email: |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: About Accessing External RAM - bobi - Jun 28 0:02:00 2002
|
Yeah that is a nice question. I am looking for the same thing but on the HC812A4. Thanks ----- Original Message ----- From: Simon Hunter To: Sent: Friday, June 28, 2002 2:48 PM Subject: [68HC12] About Accessing External RAM Hi all, Just starting to look at the HCS12 as a replacement for the HC11F1 we have been using for quite some time now. My question at this time is: Is it possible to access an external memory device (say a RAM or EEPROM chip (28C256 for example)) using a HCS12 processor? From what I have read from the data sheets, external memory access is available from specific devices, but what I am looking at doing is using the internal FLASH as program space and both an external RAM and EEPROM (both only 8bit data bus devices) to store information. Has anyone had any experience with doing this and can point me in some sort of direction of data sheets or app notes for the HCS12 series processors. Thanks guys Simon ----- Simon Hunter Technical Engineer / IT Administration Associated Controls (Aust) Pty. Ltd. Unit A/30-34 Hilly Street, Mortlake, NSW, 2137 Australia Telephone: +61 2 8765 9911 Fax: +61 2 8765 9922 Web: http://www.ascon.com.au Email: -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed] |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: About Accessing External RAM - Pat Fitzpatrick - Jun 28 4:36:00 2002
|
I spent a while looking into this (along with some considerable help from Jim Williams from Motorola) and the conclusion is that it's kind of tricky. There are two main issues: The HCS12 parts use 5 volt CMOS levels. RAMs don't. It looks like even fairly small value pullups may not get the level up to a valid CMOS high in time without stretching the clock. You may well need a level translator/transceiver (something-or-otherT245, maybe) to meet the voltage level -- but that doesn't do any good for the timing margin. You have to latch all bits of the address. That's extra parts (at least a 16 bit and an 8 bit latch -- or three 8 bit latches 'cause you have to latch the multiplexed 8 bits of address (obviously) but you also have to latch the other half of the address bus and the extended address bits too -- at least in early masks -- see errata). Again, that squeezes the timing margin. It looks like (just barely) a 10ns access time RAM will work if you don't need to decode the extended address bits for chip selects. But it's close. Very close. We decided to hang the RAM on the far side of a PLD and bit-bang PLD registers for RAM access because we don't really need the RAM bandwidth -- it holds config stuff that's only read and updated occasionally. I believe that there's an app note in the works -- but not available yet... Pat bobi wrote: > Yeah that is a nice question. > > I am looking for the same thing but on the HC812A4. > > Thanks > ----- Original Message ----- > From: Simon Hunter > To: > Sent: Friday, June 28, 2002 2:48 PM > Subject: [68HC12] About Accessing External RAM > > Hi all, > > Just starting to look at the HCS12 as a replacement for the HC11F1 we have > been using for quite some time now. > > My question at this time is: Is it possible to access an external memory > device (say a RAM or EEPROM chip (28C256 for example)) using a HCS12 processor? > > From what I have read from the data sheets, external memory access is > available from specific devices, but what I am looking at doing is using > the internal FLASH as program space and both an external RAM and EEPROM > (both only 8bit data bus devices) to store information. > > Has anyone had any experience with doing this and can point me in some sort > of direction of data sheets or app notes for the HCS12 series processors. > > Thanks guys > Simon > > ----- > Simon Hunter > Technical Engineer / IT Administration > > Associated Controls (Aust) Pty. Ltd. > Unit A/30-34 Hilly Street, > Mortlake, NSW, 2137 > Australia > > Telephone: +61 2 8765 9911 > Fax: +61 2 8765 9922 > > Web: http://www.ascon.com.au > > Email: > > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: About Accessing External RAM - Kellogg Dave - Jun 28 8:43:00 2002
|
Lots of app notes, reference manuals, data sheets etc. at: http://e-www.motorola.com/webapp/sps/library/documentationlist.jsp?rootNodeI d=03M0ym4t3ZGM0ynTpnLn&nodeId=03M0ym4t3ZGM0zGQK100&Product=Select+a+Product+ or+Technology&Family=03M0ym4t3ZGM0zGQK100&SubFamily=No+further+options&Devic e=All&DocType=All&Results=25&submit=Go Or try <http://mcu.motsps.com/> and work down the tree. 607-656-2597 -----Original Message----- From: bobi [mailto:] Sent: Friday, June 28, 2002 1:02 AM To: Subject: Re: [68HC12] About Accessing External RAM Yeah that is a nice question. I am looking for the same thing but on the HC812A4. Thanks ----- Original Message ----- From: Simon Hunter To: Sent: Friday, June 28, 2002 2:48 PM Subject: [68HC12] About Accessing External RAM Hi all, Just starting to look at the HCS12 as a replacement for the HC11F1 we have been using for quite some time now. My question at this time is: Is it possible to access an external memory device (say a RAM or EEPROM chip (28C256 for example)) using a HCS12 processor? From what I have read from the data sheets, external memory access is available from specific devices, but what I am looking at doing is using the internal FLASH as program space and both an external RAM and EEPROM (both only 8bit data bus devices) to store information. Has anyone had any experience with doing this and can point me in some sort of direction of data sheets or app notes for the HCS12 series processors. Thanks guys Simon ----- Simon Hunter Technical Engineer / IT Administration Associated Controls (Aust) Pty. Ltd. Unit A/30-34 Hilly Street, Mortlake, NSW, 2137 Australia Telephone: +61 2 8765 9911 Fax: +61 2 8765 9922 Web: http://www.ascon.com.au Email: -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: About Accessing External RAM - s_spears_2000 - Jun 28 9:31:00 2002
|
The HC12A4 EVB user manual has external ram info as well. It's a matter of setting the chip selects and ram/rom mapping. http://e-www.motorola.com/brdata/PDFDB/docs/M68HC12A4EVBUM.pdf Stephen --- In 68HC12@y..., Simon Hunter <simon@a...> wrote: > Hi all, > > Just starting to look at the HCS12 as a replacement for the HC11F1 we have > been using for quite some time now. > > My question at this time is: Is it possible to access an external memory > device (say a RAM or EEPROM chip (28C256 for example)) using a HCS12 processor? > > From what I have read from the data sheets, external memory access is > available from specific devices, but what I am looking at doing is using > the internal FLASH as program space and both an external RAM and EEPROM > (both only 8bit data bus devices) to store information. > > Has anyone had any experience with doing this and can point me in some sort > of direction of data sheets or app notes for the HCS12 series processors. > > Thanks guys > Simon > ----- > Simon Hunter > Technical Engineer / IT Administration > > Associated Controls (Aust) Pty. Ltd. > Unit A/30-34 Hilly Street, > Mortlake, NSW, 2137 > Australia > > Telephone: +61 2 8765 9911 > Fax: +61 2 8765 9922 > > Web: http://www.ascon.com.au > > Email: simon@a... |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: About Accessing External RAM - s_spears_2000 - Jun 28 11:06:00 2002
|
These are good points. I have 32K ram that is 70nS access time. I use eclk stretching and everything works fine but the performance is not optimized as you say. The upside for me is that no extra parts are needed and the speed loss does not hurt me. --- In 68HC12@y..., Pat Fitzpatrick <pat.fitzpatrick@a...> wrote: > I spent a while looking into this (along with some considerable help from Jim > Williams from Motorola) and the conclusion is that it's kind of tricky. > > There are two main issues: > > The HCS12 parts use 5 volt CMOS levels. RAMs don't. It looks like even fairly small > value pullups may not get the level up to a valid CMOS high in time without > stretching the clock. You may well need a level translator/transceiver > (something-or-otherT245, maybe) to meet the voltage level -- but that doesn't do any > good for the timing margin. > > You have to latch all bits of the address. That's extra parts (at least a 16 bit and > an 8 bit latch -- or three 8 bit latches 'cause you have to latch the multiplexed 8 > bits of address (obviously) but you also have to latch the other half of the address > bus and the extended address bits too -- at least in early masks -- see errata). > Again, that squeezes the timing margin. > > It looks like (just barely) a 10ns access time RAM will work if you don't need to > decode the extended address bits for chip selects. But it's close. Very close. > > We decided to hang the RAM on the far side of a PLD and bit-bang PLD registers for > RAM access because we don't really need the RAM bandwidth -- it holds config stuff > that's only read and updated occasionally. > > I believe that there's an app note in the works -- but not available yet... > > Pat > > bobi wrote: > > > Yeah that is a nice question. > > > > I am looking for the same thing but on the HC812A4. > > > > Thanks > > ----- Original Message ----- > > From: Simon Hunter > > To: 68HC12@y... > > Sent: Friday, June 28, 2002 2:48 PM > > Subject: [68HC12] About Accessing External RAM > > > > Hi all, > > > > Just starting to look at the HCS12 as a replacement for the HC11F1 we have > > been using for quite some time now. > > > > My question at this time is: Is it possible to access an external memory > > device (say a RAM or EEPROM chip (28C256 for example)) using a HCS12 processor? > > > > From what I have read from the data sheets, external memory access is > > available from specific devices, but what I am looking at doing is using > > the internal FLASH as program space and both an external RAM and EEPROM > > (both only 8bit data bus devices) to store information. > > > > Has anyone had any experience with doing this and can point me in some sort > > of direction of data sheets or app notes for the HCS12 series processors. > > > > Thanks guys > > Simon > > > > ----- > > Simon Hunter > > Technical Engineer / IT Administration > > > > Associated Controls (Aust) Pty. Ltd. > > Unit A/30-34 Hilly Street, > > Mortlake, NSW, 2137 > > Australia > > > > Telephone: +61 2 8765 9911 > > Fax: +61 2 8765 9922 > > > > Web: http://www.ascon.com.au > > > > Email: simon@a... > > > > -------------------------------------------------------- > > To unsubscribe from this group, send an email to: > > 68HC12-unsubscribe@y... > > > > To learn more about Motorola Microcontrollers, please visit > > http://www.motorola.com/mcu > > > |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Metrowerks Gotcha - Paul Johnson - Jun 28 12:56:00 2002
|
I just found a "gotcha" that will affect anyone converting from ICC12 to
the Metrowerks (i.e. HIWARE) compiler. This is not a bug or a problem with either compiler, just a difference in compiler design that is sure to cause major problems if not noted and accounted for. When I have to turn off interrupts in time-critical code sections, I use the following matching defines: #define INTR_PUSH() { asm pshc; asm sei; } // Metrowerks syntax #define INTR_PULL() asm pulc Using these macros, I don't accidentally turn interrupts back on if they were turned off by another routine. This is especially important inside interrupt routines. The ICC12 compiler creates local variables on the stack and saves the SP in X (if memory serves) so that pushed and local variables can be accessed using n,x. The Metrowerks compiler creates local variables on the stack, but then uses n,sp to access them. This has the obvious advantage of freeing up the X register for other uses within the routine, but if you do anything with inline assembly that affects the stack pointer, the whole program goes south. It took me several hours of debugging to find this one, because routines that I have been using for years, and know to be solid, were failing in very weird ways. The only solution I can find for this particular problem is to create a global heap that I can push and pop, but I'm afraid that the overhead will not justify the benefit. Or perhaps a global flag that is set and cleared in the INTR_ON() and INTR_OFF() defines, and then checked by the INTR_PULL(). Perhaps like this: #define INTR_ON() { asm cli; clr int_state; } #define INTR_OFF() { asm sei; bset int_state, 0x10 } #define INTR_PUSH() asm sei #define INTR_PULL() { asm pshb; asm pshc; asm pulb; asm orab int_state; asm pshb; asm pulc; asm pulb } This last takes 18 clock cycles, which is still faster than a call to a heap manager. Any thoughts? Am I missing an easier way? Anyway, I thought I'd share this "gotcha" with the list. Regards, Paul |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks - bruce_at_pocket_neurobics - Jun 30 23:40:00 2002
|
Just purchased the Metrowerks Code Warrior for HC12 & having a hard time getting to first base. I have an existing 'D60 application, absolute assembler (all ORGs, no SECTIONs) that fully exercises the 'D60's RAM, EEPROM & FLASH. There doesn't seem to a template with the CodeWarrior for non-relocatable assembler code. When I set the assembler parameters for "ELF/DWARF 2.0 Absolute File" output, it still seems to generate .o object files (of about the right size), but I cannot then get these files to link. Any thoughts? If someone has a template they can provide backchannel.. [P.S. why have I changed development systems? - the code is expanding and I need to go to a memory-banked processor.] Thanks |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Metrowerks Gotcha - Daniel Friederich - Jul 1 8:22:00 2002
|
Hi Paul, I think you have a little race condition in your workaround when in the INTR_ON macro, in interrupt happens after the cli but before the clr. And the same for the INTR_OFF macro as well. In your workaround, you have to exchange the cli and the clr. As alternate workaround, (which is not really nicer than yours), you could also keep the CC in a local variable instead of using your approach of a second state. Note that this one does still need 10 additional cycles :-( Also note that this only works when you have few local variables in the interrupt handler due to limitations of the movb instruction. use globals if reentrancy is not the problem. #define INTR_DECLARE volatile unsigned char storeCC #define INTR_PUSH() { __asm pshc; __asm movb 1,SP+,storeCC; __asm sei; } #define INTR_PULL() { __asm movb storeCC, 1,-SP; __asm pulc;} __interrupt void TEST2_InterruptExample(void) { volatile int a,b,c,d; INTR_DECLARE; a=b=c=d=0; c+=a; INTR_PUSH(); a= b+c; INTR_PULL(); d=c; } -----Original Message----- From: Paul Johnson [mailto:] Sent: Friday, June 28, 2002 7:57 PM To: Subject: [68HC12] Metrowerks Gotcha I just found a "gotcha" that will affect anyone converting from ICC12 to the Metrowerks (i.e. HIWARE) compiler. This is not a bug or a problem with either compiler, just a difference in compiler design that is sure to cause major problems if not noted and accounted for. When I have to turn off interrupts in time-critical code sections, I use the following matching defines: #define INTR_PUSH() { asm pshc; asm sei; } // Metrowerks syntax #define INTR_PULL() asm pulc Using these macros, I don't accidentally turn interrupts back on if they were turned off by another routine. This is especially important inside interrupt routines. The ICC12 compiler creates local variables on the stack and saves the SP in X (if memory serves) so that pushed and local variables can be accessed using n,x. The Metrowerks compiler creates local variables on the stack, but then uses n,sp to access them. This has the obvious advantage of freeing up the X register for other uses within the routine, but if you do anything with inline assembly that affects the stack pointer, the whole program goes south. It took me several hours of debugging to find this one, because routines that I have been using for years, and know to be solid, were failing in very weird ways. The only solution I can find for this particular problem is to create a global heap that I can push and pop, but I'm afraid that the overhead will not justify the benefit. Or perhaps a global flag that is set and cleared in the INTR_ON() and INTR_OFF() defines, and then checked by the INTR_PULL(). Perhaps like this: #define INTR_ON() { asm cli; clr int_state; } #define INTR_OFF() { asm sei; bset int_state, 0x10 } #define INTR_PUSH() asm sei #define INTR_PULL() { asm pshb; asm pshc; asm pulb; asm orab int_state; asm pshb; asm pulc; asm pulb } This last takes 18 clock cycles, which is still faster than a call to a heap manager. Any thoughts? Am I missing an easier way? Anyway, I thought I'd share this "gotcha" with the list. Regards, Paul -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Metrowerks Gotcha - Paul Johnson - Jul 1 19:40:00 2002
|
Hi Daniel > I think you have a little race condition in your workaround when in the > INTR_ON macro, in interrupt happens after the cli but before the clr. And > the same for the INTR_OFF macro as well. In your workaround, you have to > exchange the cli and the clr. Good catch, thanks. However, I believe that INTR_OFF should be as written, since the sei disables interrupts, so no race condition can exist before the bset instruction. Or am I missing something? > As alternate workaround, (which is not really nicer than yours), you could > also keep the CC in a local variable instead of using your approach of a > second state. > Note that this one does still need 10 additional cycles :-( > Also note that this only works when you have few local variables in the > interrupt handler due to limitations of the movb instruction. use > globals if > reentrancy is not the problem. > #define INTR_DECLARE volatile unsigned char storeCC > #define INTR_PUSH() { __asm pshc; __asm movb 1,SP+,storeCC; __asm sei; } > #define INTR_PULL() { __asm movb storeCC, 1,-SP; __asm pulc;} I was going to ask about the SP+ and the -SP, but I just got it. Very nice. :) > __interrupt void TEST2_InterruptExample(void) { > volatile int a,b,c,d; > INTR_DECLARE; > a=b=c=d=0; > c+=a; > INTR_PUSH(); > a= b+c; > INTR_PULL(); > d=c; > } Thanks for the ideas. It's always fun to see how someone else attacks a problem. Best regards, Paul |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Metrowerks - Erich Styger - Jul 2 12:02:00 2002
|
I assume you have Mot V1.2: - open the project project preference panel/settings - go to Target > Target Settings - make sure the Linker is set to Libmaker - go to Target > Libmaker panel - select 'build a single object file' - set your assembler options to -F2a (absolute oject file format, ELF/Dwarf) - build your application. This will inhibit usage of the linker and prm file (you do not need for a absolute application. Future linker prefence panel will directly allow using a absolute assembly application. Hope this helps, Erich > -----Original Message----- > From: bruce_at_pocket_neurobics > [mailto:] > Sent: Monday, July 01, 2002 6:41 AM > To: > Subject: [68HC12] Re: Metrowerks > Just purchased the Metrowerks Code Warrior for HC12 & having a hard > time getting to first base. > > I have an existing 'D60 application, absolute assembler (all ORGs, no > SECTIONs) that fully exercises the 'D60's RAM, EEPROM & FLASH. > > There doesn't seem to a template with the CodeWarrior for > non-relocatable assembler code. When I set the assembler parameters > for "ELF/DWARF 2.0 Absolute File" output, it still seems to generate > .o object files (of about the right size), but I cannot then get these > files to link. > > Any thoughts? If someone has a template they can provide backchannel.. > > [P.S. why have I changed development systems? - the code is expanding > and I need to go to a memory-banked processor.] > > Thanks > > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks - bruce_at_pocket_neurobics - Jul 3 7:29:00 2002
|
Erich, thanks very much for the quick response. This has moved me forward, but I think the core of the problem is that the M68KIT912DP256: CodeWarrior Promotion Package for HC12 (which uses the P&E BDM MultiLink cable) is limited to assembler level working (ie excludes C compiler) & excludes the simulator (please correct if this is not correct). That's fine, but the only Assembler example provided (there are a myriad of fibo.c examples) is for the simulator. Could I please request that Metrowerks make available at least an example: fibo.asm->multilink->dp256 ram & flash I personally would appreciate the same example for the 'D60 also. I'm sure it's just 5 minutes work experienced users, but I think it's 5 days work (and counting) for new users. Thanks in advance Bruce ________________________________________________ --- In 68HC12@y..., "Erich Styger" <erich.styger@m...> wrote: > I assume you have Mot V1.2: > - open the project project preference panel/settings > - go to Target > Target Settings > - make sure the Linker is set to Libmaker > - go to Target > Libmaker panel > - select 'build a single object file' > - set your assembler options to -F2a (absolute oject file format, ELF/Dwarf) > - build your application. > > This will inhibit usage of the linker and prm file (you do not need for a absolute application. > Future linker prefence panel will directly allow using a absolute assembly application. > > Hope this helps, > Erich |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks - bruce_at_pocket_neurobics - Jul 3 7:31:00 2002
|
Erich, thanks very much for the quick response. This has moved me forward, but I think the core of the problem is that the M68KIT912DP256: CodeWarrior Promotion Package for HC12 (which uses the P&E BDM MultiLink cable) is limited to assembler level working (ie excludes C compiler) & excludes the simulator (please correct if this is not correct). That's fine, but the only Assembler example provided (there are a myriad of fibo.c examples) is for the simulator. Could I please request that Metrowerks make available at least an example: fibo.asm->multilink->dp256 ram & flash I personally would appreciate the same example for the 'D60 also. I'm sure it's just 5 minutes work experienced users, but I think it's 5 days work (and counting) for new users. Thanks in advance Bruce ________________________________________________ --- In 68HC12@y..., "Erich Styger" <erich.styger@m...> wrote: > I assume you have Mot V1.2: > - open the project project preference panel/settings > - go to Target > Target Settings > - make sure the Linker is set to Libmaker > - go to Target > Libmaker panel > - select 'build a single object file' > - set your assembler options to -F2a (absolute oject file format, ELF/Dwarf) > - build your application. > > This will inhibit usage of the linker and prm file (you do not need for a absolute application. > Future linker prefence panel will directly allow using a absolute assembly application. > > Hope this helps, > Erich |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Metrowerks - Erich Styger - Jul 3 8:41:00 2002
|
Bruce, I will send you an example off-list (to avoid the 'attachment problem' in the list). Basic thing is that you even can use the 'C' example. just replace/remove the C files and put your assembly files into it instead. PS: even with the assembly stuff in the license configuration only, you can use C up to 1K (which is pretty useful for quick prototyping as well). Erich > -----Original Message----- > From: bruce_at_pocket_neurobics > [mailto:] > Sent: Wednesday, July 03, 2002 2:32 PM > To: > Subject: [68HC12] Re: Metrowerks > Erich, > thanks very much for the quick response. This has moved me forward, > but I think the core of the problem is that the M68KIT912DP256: > CodeWarrior Promotion Package for HC12 (which uses the P&E BDM > MultiLink cable) is limited to assembler level working (ie excludes C > compiler) & excludes the simulator (please correct if this is not > correct). That's fine, but the only Assembler example provided (there > are a myriad of fibo.c examples) is for the simulator. > > Could I please request that Metrowerks make available at least an > example: fibo.asm->multilink->dp256 ram & flash > > I personally would appreciate the same example for the 'D60 also. > > I'm sure it's just 5 minutes work experienced users, but I think it's > 5 days work (and counting) for new users. > > Thanks in advance > Bruce > ________________________________________________ > --- In 68HC12@y..., "Erich Styger" <erich.styger@m...> wrote: > > I assume you have Mot V1.2: > > - open the project project preference panel/settings > > - go to Target > Target Settings > > - make sure the Linker is set to Libmaker > > - go to Target > Libmaker panel > > - select 'build a single object file' > > - set your assembler options to -F2a (absolute oject file format, > ELF/Dwarf) > > - build your application. > > > > This will inhibit usage of the linker and prm file (you do not need > for a absolute application. > > Future linker prefence panel will directly allow using a absolute > assembly application. > > > > Hope this helps, > > Erich > > > > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks - bruce_at_pocket_neurobics - Jul 3 9:02:00 2002
|
Eric, thanks for your responsiveness, I'll await your email. just one more.. Flash programming via DBUG_12 monitor - do you have an example on this? There's an issue with the IDE having to wait for the '*' generated by DBUG_12 at the end of an .sx line, isn't there? I haven't been able to see anywhere how to handle this. Thanks. Bruce ______________________________ --- In 68HC12@y..., "Erich Styger" <erich.styger@m...> wrote: > Bruce, > I will send you an example off-list (to avoid the 'attachment problem' in the list). > > Basic thing is that you even can use the 'C' example. just replace/remove the C files > and put your assembly files into it instead. > > PS: even with the assembly stuff in the license configuration only, you can use > C up to 1K (which is pretty useful for quick prototyping as well). > > Erich > > > -----Original Message----- > > From: bruce_at_pocket_neurobics > > [mailto:bruce.mcmillan@P...] > > Sent: Wednesday, July 03, 2002 2:32 PM > > To: 68HC12@y... > > Subject: [68HC12] Re: Metrowerks > > > > > > Erich, > > thanks very much for the quick response. This has moved me forward, > > but I think the core of the problem is that the M68KIT912DP256: > > CodeWarrior Promotion Package for HC12 (which uses the P&E BDM > > MultiLink cable) is limited to assembler level working (ie excludes C > > compiler) & excludes the simulator (please correct if this is not > > correct). That's fine, but the only Assembler example provided (there > > are a myriad of fibo.c examples) is for the simulator. > > > > Could I please request that Metrowerks make available at least an > > example: fibo.asm->multilink->dp256 ram & flash > > > > I personally would appreciate the same example for the 'D60 also. > > > > I'm sure it's just 5 minutes work experienced users, but I think it's > > 5 days work (and counting) for new users. > > > > Thanks in advance > > Bruce > > ________________________________________________ > > --- In 68HC12@y..., "Erich Styger" <erich.styger@m...> wrote: > > > I assume you have Mot V1.2: > > > - open the project project preference panel/settings > > > - go to Target > Target Settings > > > - make sure the Linker is set to Libmaker > > > - go to Target > Libmaker panel > > > - select 'build a single object file' > > > - set your assembler options to -F2a (absolute oject file format, > > ELF/Dwarf) > > > - build your application. > > > > > > This will inhibit usage of the linker and prm file (you do not need > > for a absolute application. > > > Future linker prefence panel will directly allow using a absolute > > assembly application. > > > > > > Hope this helps, > > > Erich > > > > > > > > > > > > -------------------------------------------------------- > > To unsubscribe from this group, send an email to: > > 68HC12-unsubscribe@y... > > > > To learn more about Motorola Microcontrollers, please visit > > http://www.motorola.com/mcu > > > > > > > > > |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )