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
See Also
Discussion Groups | 68HC12 | Hand soldering
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Hand soldering - kqzca - Jun 24 11:28:00 2002
|
Hello All, I am considering to upgrade from HC11 to HC12, but I don't know how to solder a 112PIN QFP device, do you just hand solder it or is there any socket for that like PLCC44 for HC11? |
|
|
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Hand soldering - Gerhard Maier - Jun 24 11:38:00 2002
|
Hand solder works. If you have a thick tin plating on your pcboard, you might not even need solder paste. Run the iron over each row of 28pins in an even, slow motion, giving each pin 2 sec max. of heat. Use enough flux ! Of course, a paste printer and smd-oven makes this a lot easier ... Gerhard kqzca wrote: > Hello All, > > I am considering to upgrade from HC11 to HC12, but I don't know how > to solder a 112PIN QFP device, do you just hand solder it or is there > any socket for that like PLCC44 for HC11? > -------------------------------------------------------- > 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: Hand soldering - Sam Saprunoff - Jun 24 13:01:00 2002
|
Good day,
This is what I posted some time ago:
[Original Post}
I too have had to deal with small pitch SMT parts, and
was left to contracting out this service... Frustrated, I searched for a technique and/or
equipment (not too expensive) which would allow me to do this in-house. Finally, I came
across some equipment from Metcal which works excellent and is reasonably priced (approx.
$1100 CAN / $ 750 US). With this soldering station, a "mini-hoof" tip, and a little
practice using "drag soldering", I am able to hand solder fine pitch parts as low as 7
mils. I have just finished soldering nine HC12 (912B32) and they work excellent. In fact,
my clients do not believe that I hand soldered the components... The soldering looks that
good. The technique is quite simple and It took me about 10 minutes to learn. The
technique is described on the Metcal site at: http://www.metcal.com/technotes/minhoof2.html#fine
The only comment I can make is that one must use a lot of flux. The technique and the equipment work excellent! By the way, I was at first skeptical, but my distributor (FAI) was able to loan me a test unit. After I used it, I purchased one immediately: Station: MX-500S-11 Hoof Tip: SMTC-0167 ( Fine pitch parts) Chisel Tip: STTC-037 (for 1206 resistors, etc) Further, I do not work for or with Metcal. I am just a extremely satisfied customer that is now able to hand-solder in-house SMT prototypes! [End Post}
You may be able to use a fine-tip soldering iron in place of the Metcal, but I have
never tried this.
Best of luck!
Cheers, Sam Saprunoff
s...@telusplanet.net ----- Original Message -----
From: "kqzca" <q...@netzero.net>
To: <6...@yahoogroups.com>
Sent: Monday, June 24, 2002 10:28 AM
Subject: [68HC12] Hand soldering > > I am considering to upgrade from HC11 to HC12, but I don't know how > to solder a 112PIN QFP device, do you just hand solder it or is there > any socket for that like PLCC44 for HC11?> ------------------------ Yahoo! Groups Sponsor ---------------------~--> > Free $5 Love Reading > Risk Free! > http://us.click.yahoo.com/3PCXaC/PfREAA/Ey.GAA/dN_tlB/TM > ---------------------------------------------------------------------~-> > > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > 6...@yahoogroups.com > > 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 )
Hand soldering - kqzca - Jun 25 11:55:00 2002
|
Thank you Gerhard, Sam and Benny. Benny, I do interest in your solution and plaese send me the full explanation to my email: . Thanks. Kevin |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Hand soldering - Carl Ungvarsky - Jun 25 15:49:00 2002
|
I'm also using the Metcal iron. This is the best hand-operated iron I've used. There are some very fine tips available and they heat up nearly instantly. The "rework" station MX-500P has two ports - one for a conventional iron, and the second a "rework" iron especially good for SOICs or other parts with opposing leads. That link may not work. Try this one. http://www.metcal.com/tips/minhoof2.html#standard I don't work for Metcal. Someone here decided to replace all our $30 irons with $750 irons. We laughed until we used them. As far as desoldering a HC12, unless the boards are cheap to you and MCUs expensive, I would just dyke the leads from the HC12 and then use solderwick to remove the stubs. That's probably your best chance to save the pads on the board. Carl >From: "Sam Saprunoff" <> ... is quite simple and It took me about 10 minutes to learn. The technique is described on the Metcal site at: http://www.metcal.com/technotes/minhoof2.html#fine _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com |
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
HIWARE assembler question - Paul Johnson - Jul 16 14:27:00 2002
|
Is there a way to create initialized variables in a Metrowerks/HIWARE assembler file so that it will be initialized in START12.C along with everything else? Or do I have to create the variables in a C file or header, as in: // common.h #ifdef __MAIN__ #define EXTERN #else // __MAIN__ #define EXTERN extern #endif // __MAIN__ EXTERN int someint = 5; The problem with this method, of course, is that variables that should have only module visibility will become globals. Does anyone know of a better (or the proper) way to do this with the HIWARE toolset? Thanks, Paul |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: HIWARE assembler question - Erich Styger - Jul 17 4:08:00 2002
|
Paul, I would go with the 'C' solution. In assembler you do not have a kind of automatic variable intialisation. The only thing I could think about is using a dc directive, but then placing it into RAM area (but this is a kind of hack). But I did not try it (if it really works). Another solution: you could create a kind of 'initalisation' routine in your assembly module. And then call it from the startup code. Erich > -----Original Message----- > From: Paul Johnson [mailto:] > Sent: Tuesday, July 16, 2002 9:28 PM > To: > Subject: [68HC12] HIWARE assembler question > Is there a way to create initialized variables in a Metrowerks/HIWARE > assembler file so that it will be initialized in START12.C along with > everything else? Or do I have to create the variables in a C file or > header, as in: > > // common.h > #ifdef __MAIN__ > #define EXTERN > #else // __MAIN__ > #define EXTERN extern > #endif // __MAIN__ > > EXTERN int someint = 5; > > The problem with this method, of course, is that variables that should have > only module visibility will become globals. > > Does anyone know of a better (or the proper) way to do this with the HIWARE > toolset? > > Thanks, > > 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: HIWARE assembler question - Daniel Friederich - Jul 17 4:49:00 2002
|
Go with the 'C' solution. Using DC's does not work :-(. Bye Daniel -----Original Message----- From: Erich Styger [mailto:] Sent: Wednesday, July 17, 2002 11:09 AM To: Subject: RE: [68HC12] HIWARE assembler question Paul, I would go with the 'C' solution. In assembler you do not have a kind of automatic variable intialisation. The only thing I could think about is using a dc directive, but then placing it into RAM area (but this is a kind of hack). But I did not try it (if it really works). Another solution: you could create a kind of 'initalisation' routine in your assembly module. And then call it from the startup code. Erich > -----Original Message----- > From: Paul Johnson [mailto:] > Sent: Tuesday, July 16, 2002 9:28 PM > To: > Subject: [68HC12] HIWARE assembler question > Is there a way to create initialized variables in a Metrowerks/HIWARE > assembler file so that it will be initialized in START12.C along with > everything else? Or do I have to create the variables in a C file or > header, as in: > > // common.h > #ifdef __MAIN__ > #define EXTERN > #else // __MAIN__ > #define EXTERN extern > #endif // __MAIN__ > > EXTERN int someint = 5; > > The problem with this method, of course, is that variables that should have > only module visibility will become globals. > > Does anyone know of a better (or the proper) way to do this with the HIWARE > toolset? > > Thanks, > > Paul > > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu |
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
msCAN question - Paul Johnson - Aug 19 15:57:00 2002
|
When using an extended identifier with 16 bit filters, are IDR2 and IDR3 still transmitted? In other words, can I use them for data (other than the RTR bit, of course)? It seems obvious that this is the case, but it is not explicitly stated. Does anyone know for sure? Thanks, Paul |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: msCAN question - Kelley, Dale - Aug 19 16:11:00 2002
|
Paul I have not done it ( I have only used 11 bit mode) but it sure seems that if you set the mask to don't care you could put what ever you like there. Dale Kelley -----Original Message----- From: Paul Johnson [mailto:] Sent: Monday, August 19, 2002 4:58 PM To: Subject: [68HC12] msCAN question When using an extended identifier with 16 bit filters, are IDR2 and IDR3 still transmitted? In other words, can I use them for data (other than the RTR bit, of course)? It seems obvious that this is the case, but it is not explicitly stated. Does anyone know for sure? Thanks, 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: msCAN question - Paul Johnson - Aug 19 16:38:00 2002
|
> I have not done it ( I have only used 11 bit mode) but it > sure seems that if you set the mask to don't care you could put > what ever you like there. According to the diagram for 16 bit mode, it does not even test these bits, so setting the mask to "don't care" should not even be necessary, although I would tend to do it prophylactically anyway. Regards, Paul |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Metrowerks programming A4? - Paul Johnson - Nov 6 18:19:00 2002
|
Has anyone used Codewarrior to program and 812A4? When you create a new project using stationary, in only builds a RAM version, but I want my code to run out of the ROM space. I know the BDM can program the ROM space, but how do you create a project to default to the ROM space? Thanks, Paul |
|
|
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks programming A4? - Gilles Blanquin - Nov 7 3:24:00 2002
|
Hi Paul. The 812A4 does not have any internal flash. It has an internal EEPROM of 4 kB that you can program with our tools, with D-Bug12 interface or BDM interfaces (SDI, P&E ICD12/Cable12HS/Multilink,etc.). To program external ROM (I bet you mean flash or eeproms), you might have to get another tool specialized to program external flash devices. Of course, you can generate the application for ROM, setting your .PRM file according to your future code/data "banks/pages". See the following .PRM file (linker parameter file) example used for an "Axiom CMD12A4" board: /////////////////// PRM BEGIN //////////////////////////////////// SECTIONS ONCHIP_RAM = READ_WRITE 0x0800 TO 0x0BFF; /* ONCHIP RAM */ ONCHIP_EEPROM = READ_ONLY 0xF000 TO 0xFFEF; /* EXTERNAL PSEUDO-ROM or EEPROM */ PPAGE_0 = READ_ONLY 0x008000 TO 0x00BFFF; /* EXTERNAL PSEUDO-ROM */ PPAGE_1 = READ_ONLY 0x018000 TO 0x01BFFF; PPAGE_2 = READ_ONLY 0x028000 TO 0x02BFFF; PPAGE_3 = READ_ONLY 0x038000 TO 0x03AFFF; DPAGE_0 = READ_WRITE 0x007000 TO 0x007FFF; /* EXTERNAL RAM - DPAGE */ DPAGE_1 = READ_WRITE 0x017000 TO 0x017FFF; DPAGE_2 = READ_WRITE 0x027000 TO 0x027FFF; /* DPAGE_3 to DPAGE_D not used here */ DPAGE_E = READ_WRITE 0x0E7000 TO 0x0E7FFF; DPAGE_F = READ_WRITE 0x0F7000 TO 0x0F7FFF; EPAGE_1F = READ_WRITE 0x1F0400 TO 0x1F07FF; /* EXTERNAL RAM - EPAGE */ PLACEMENT _PRESTART, STARTUP, ROM_VAR, STRINGS, NON_BANKED, COPY INTO ONCHIP_EEPROM; DEFAULT_RAM INTO ONCHIP_RAM; DEFAULT_ROM INTO PPAGE_0,PPAGE_1,PPAGE_2,PPAGE_3; Banked_Data INTO DPAGE_0,DPAGE_1,DPAGE_2,DPAGE_E,DPAGE_F; extrapage1F INTO EPAGE_1F; END STACKSIZE 0x50 /* Vectors definition */ VECTOR 0 _Startup /* set reset vector to function _Startup defined in startup code */ /////////////////// PRM END //////////////////////////////////// Note that you will have to use the "ansib.lib" library and compile in banked memory model (-Mb option). To get more support, you can contact <>. Regards, Gilles At 12:19 AM 11/7/2002, you wrote: >Has anyone used Codewarrior to program and 812A4? When you create a new >project using stationary, in only builds a RAM version, but I want my code >to run out of the ROM space. I know the BDM can program the ROM space, but >how do you create a project to default to the ROM space? > >Thanks, > >Paul > >-------------------------------------------------------- >To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu [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 )
Extra time needed between SPI bytes? - Stephen Trier - Nov 7 12:51:00 2002
|
Hi, gang. I'm working on transmitting data between two HC12s using SPI. The master is an 8 MHz 912B32, and the slave is a 5 MHz 812A4. The line rate is 2 Mbps. Traffic is bursty. I would like the master to send the bursts as fast as possible. I'm seeing bytes dropped, though both sides are polling their SPI ports as fast as they can manage, with interrupts masked. I can fix the dropped packets by adding a few nops to the master's transmit loop. I'd like to make the data transfer as fast as possible, and I certainly don't like "magic" nops. I'd sure appreciate some help figuring out what is going on. Here's my transmit loop, which runs on the 8 MHz 912B32. At this point, SPE = SWOM = MSTR = CPOL = SSOE = 1, and CPHA = LSBF = SPC0 = 0. SP0BR = $01. Interrupts are masked (X = I = 1). ----------- ; Send the first byte ldab 1,y+ stab _SP0DR ; [Some housekeeping code elided.] ; Send the remaining bytes txloop: brclr _SP0SR,SPIF,txloop ; (4~) Wait for the last byte to complete ; Delay to let the remote keep up. ; This 5-cycle delay was determined experimentally. nop nop nop nop nop ldab 1,y+ ; (3~) Write the next byte stab _SP0DR ; (2~) dbne x, txloop ; (3~) Go around for the next byte ; Wait for the last byte to finish transmitting. txdone: brclr _SP0SR,SPIF,txdone ldab _SP0DR ---------- Here is the receive routine from the 5 MHz 812A4. SER_BUSY rises as a signal that the packet is done. During this loop, SPE = SWOM = CPOL = 1. MSTR = CPHA = SSOE = LSBF = SPC0 = 0. SP0BR = $00. Interrupts are masked. ---------- loop: brclr _SP0SR,SPIF,chkbusy ; (4~) ldab _SP0DR ; (3~) stab 1,y+ ; (2~) chkbusy: brclr _PORTH,SER_BUSY,loop ; (4~) ---------- That receive loop executes in 4+3+2+4 = 13 cycles per iteration. Without the nops, bytes should be arriving every 8 bit times plus five 8 MHz cycles, which is 37 B32 cycles = 4.625 us, which is 23.1 cycles on the A4. On the surface, the loop is not too slow for the data. With the nops, things slow down to 8 bit times plus ten 8 MHz cycles, which is 42 B32 cycles = 5.25 us = 26.25 A4 cycles. When I look at the SPI activity with a 'scope, I see all of the bytes of a packet being transmitted whether or not the nops are present, so it must be the receiver that is dropping the bytes. What's happening at the receiver that is slowing things down? The A4 book says that SPIF is set "on the eighth serial clock cycle". There is no mention of a delay before SPIF being set, but perhaps there is actually a delay for clock synchronization or something? I'd sure appreciate any insight or ideas. At a minimum, I'd like to get enough of an understanding that those nops stop being magic. At best, I'd like to know how to get rid of them and move the bytes as fast as possible. Stephen -- Stephen Trier Technical Development Lab Cleveland FES Center / CWRU / KG8IH |
|
|
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Extra time needed between SPI bytes? - Author Unknown - Nov 7 14:53:00 2002
|
In a message dated 11/7/02 12:54:53 PM Eastern Standard Time, writes: > What's happening at the receiver that is slowing things down? E stretch maybe? [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: Extra time needed between SPI bytes? - Gordon Doughman - Nov 7 15:35:00 2002
|
Stephen, Are you operating out of internal memory on the A4? If executing out of external memory, is it being accessed without E-clock stretch cycles? Also, the timing analysis of your receive routine is off. Note that with the brclr instruction, the read of SP0SR occurs during the first cycle of the instruction. If the SPIF bit gets set just after the read occurs, execution will branch to the second brclr instruction, adding 8 cycles to the loop time (7 after the read occurs). Also, data is sent out the SPI at 9 SPI clocks per byte (there is a .5 clock delay before the first clock edge, and a .5 clock sequential transfer delay. This should actually help your case). Regards, Gordon Stephen Trier wrote: > Hi, gang. > > I'm working on transmitting data between two HC12s using SPI. The master > is an 8 MHz 912B32, and the slave is a 5 MHz 812A4. The line rate is 2 Mbps. > Traffic is bursty. I would like the master to send the bursts as fast as > possible. > > I'm seeing bytes dropped, though both sides are polling their SPI ports as > fast as they can manage, with interrupts masked. I can fix the dropped > packets by adding a few nops to the master's transmit loop. > > I'd like to make the data transfer as fast as possible, and I certainly > don't like "magic" nops. I'd sure appreciate some help figuring out what > is going on. > > Here's my transmit loop, which runs on the 8 MHz 912B32. At this point, > SPE = SWOM = MSTR = CPOL = SSOE = 1, and CPHA = LSBF = SPC0 = 0. > SP0BR = $01. Interrupts are masked (X = I = 1). > > ----------- > > ; Send the first byte > ldab 1,y+ > stab _SP0DR > > ; [Some housekeeping code elided.] > > ; Send the remaining bytes > txloop: > brclr _SP0SR,SPIF,txloop ; (4~) Wait for the last byte to complete > > ; Delay to let the remote keep up. > ; This 5-cycle delay was determined experimentally. > nop > nop > nop > nop > nop > > ldab 1,y+ ; (3~) Write the next byte > stab _SP0DR ; (2~) > > dbne x, txloop ; (3~) Go around for the next byte > > ; Wait for the last byte to finish transmitting. > txdone: > brclr _SP0SR,SPIF,txdone > ldab _SP0DR > ---------- > > Here is the receive routine from the 5 MHz 812A4. SER_BUSY rises as a > signal that the packet is done. During this loop, SPE = SWOM = CPOL = 1. > MSTR = CPHA = SSOE = LSBF = SPC0 = 0. SP0BR = $00. Interrupts are > masked. > > ---------- > loop: > brclr _SP0SR,SPIF,chkbusy ; (4~) > ldab _SP0DR ; (3~) > stab 1,y+ ; (2~) > chkbusy: > brclr _PORTH,SER_BUSY,loop ; (4~) > ---------- > > That receive loop executes in 4+3+2+4 = 13 cycles per iteration. Without > the nops, bytes should be arriving every 8 bit times plus five 8 MHz cycles, > which is 37 B32 cycles = 4.625 us, which is 23.1 cycles on the A4. On the > surface, the loop is not too slow for the data. > > With the nops, things slow down to 8 bit times plus ten 8 MHz cycles, > which is 42 B32 cycles = 5.25 us = 26.25 A4 cycles. > > When I look at the SPI activity with a 'scope, I see all of the bytes of > a packet being transmitted whether or not the nops are present, so it must > be the receiver that is dropping the bytes. > > What's happening at the receiver that is slowing things down? The A4 book > says that SPIF is set "on the eighth serial clock cycle". There is no > mention of a delay before SPIF being set, but perhaps there is actually a > delay for clock synchronization or something? > > I'd sure appreciate any insight or ideas. At a minimum, I'd like to get > enough of an understanding that those nops stop being magic. At best, I'd > like to know how to get rid of them and move the bytes as fast as > possible. > > Stephen > > -- > Stephen Trier > Technical Development Lab > Cleveland FES Center / CWRU > / KG8IH > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > -- =============================================================== Gordon Doughman Ph: 937-438-6811 Motorola Semiconductor Fax: 937-434-7457 Field Applications Engineer Pager: 800-759-8352 Pin: 1304089 Suite 175 3131 Newmark Drive Miamisburg, OH 45342 Check out my HC12 book at: http://www.rtcgroup.com/books/ |
|
|
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Extra time needed between SPI bytes? - Stephen Trier - Nov 8 15:14:00 2002
|
Thanks, Bob, Gordon, and Alan. The code is running from 16-bit external flash and the data is being written to 16-bit external RAM. ECLK stretch is turned off on all chip selects. (Verified with a 'scope.) Am I correct in my understanding that the SPI receiver is double-buffered? That is, can I retrieve a previous byte from the data register while another byte is being shifted into the shift register? The Advance Information confuses me a little on this point. If it isn't OK to do this, it would explain the need for the nops. Alan, the handshake line is a good idea. The first version of these routines did use a port pin for stop-and-wait handshaking. However, that doesn't let me overlap data transmission and manipulation on the receiver, which in turn lets the transmitter put the bytes closer together on the line. If this overlap is impossible, I'll reconsider handshaking. Stephen -- Stephen Trier Technical Development Lab Cleveland FES Center / CWRU / KG8IH |
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Extra time needed between SPI bytes? - Gordon Doughman - Nov 8 15:30:00 2002
|
Stephen, >Am I correct in my understanding that the SPI receiver is double-buffered? Yes. the receiver is double buffered on the HC12 devices, for transmitted data writes are directly to the shift register. Note that on the HCS12 devices both the transmit & receive are double buffered. Is the problem only occurring while a BDM tool is attached? Be careful not to monitor any of the SPI registers (either in a memory window or in a variable watch window), BDM reads of these registers will have the same effect as when the application reads them. This could explain the lost bytes. Regards, Gordon Stephen Trier wrote: > Thanks, Bob, Gordon, and Alan. > > The code is running from 16-bit external flash and the data is being written > to 16-bit external RAM. ECLK stretch is turned off on all chip selects. > (Verified with a 'scope.) > > Am I correct in my understanding that the SPI receiver is double-buffered? > That is, can I retrieve a previous byte from the data register while another > byte is being shifted into the shift register? The Advance Information > confuses me a little on this point. If it isn't OK to do this, it would > explain the need for the nops. > > Alan, the handshake line is a good idea. The first version of these routines > did use a port pin for stop-and-wait handshaking. However, that doesn't > let me overlap data transmission and manipulation on the receiver, which in > turn lets the transmitter put the bytes closer together on the line. If > this overlap is impossible, I'll reconsider handshaking. > > Stephen > > -- > Stephen Trier > Technical Development Lab > Cleveland FES Center / CWRU > / KG8IH > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > -- =============================================================== Gordon Doughman Ph: 937-438-6811 Motorola Semiconductor Fax: 937-434-7457 Field Applications Engineer Pager: 800-759-8352 Pin: 1304089 Suite 175 3131 Newmark Drive Miamisburg, OH 45342 Check out my HC12 book at: http://www.rtcgroup.com/books/ |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )