27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

Hello, I am re-designing a board that currently uses a MC68HC11A1FN but apparently this part is obsolete. I am wondering if using the MC68HC11E1CFU3 is going to be as simple as just putting this device in the circuit board with proper footprint layout and it will work just like the other device? I don't see any major gotta's in the datasheet and it looks like it is almost identical with more RAM on chip. Is this an accurate assumption? The software I am using to writing all the firmware is American Arium 68HC11 cross assembler. The code is in C. Basically I am just using what currently exits for them to keep down development costs and get into production sooner. I am also changing the NVSRAM from a Dallas semi DS1643AL to a Semitech STK12C68-S45. There will not be a RTC on the new chip since they want to keep the costs down and they have a need for a clock. I believe it should work the same minus the clock and faster access time. If anybody has any comments on this then let me know. Thanks in advance.

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Hi, Sometimes you could use the MC68HC11E0CFN3 Description: 8-BIT MCU,512RAM,A/D,3MHZ Avnet Marshall www.avnetmarshall.com has stock at $5.46 QTY = 1 Regards, Roberto Guillermo Berner Boolean General ICQ 119529928 54 11 4308 3500 54 11 4308 3700 15 5122 6095 ----- Original Message ----- From: "coolpix404" <> To: <> Sent: Sunday, September 15, 2002 11:06 AM Subject: [m68HC11] MC68HC11E1CFU3 > Hello, > > I am re-designing a board that currently uses a MC68HC11A1FN but > apparently this part is obsolete. I am wondering if using the > MC68HC11E1CFU3 is going to be as simple as just putting this device > in the circuit board with proper footprint layout and it will work > just like the other device? > > I don't see any major gotta's in the datasheet and it looks like it > is almost identical with more RAM on chip. Is this an accurate > assumption? > > The software I am using to writing all the firmware is American Arium > 68HC11 cross assembler. The code is in C. Basically I am just using > what currently exits for them to keep down development costs and get > into production sooner. > > I am also changing the NVSRAM from a Dallas semi DS1643AL to a > Semitech STK12C68-S45. There will not be a RTC on the new chip since > they want to keep the costs down and they have a need for a clock. I > believe it should work the same minus the clock and faster access > time. > > If anybody has any comments on this then let me know. Thanks in > advance. > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

At 21:30 15.09.02 +0300, you wrote: >----- Original Message ----- >From: "coolpix404" <> >To: <> > > > I am re-designing a board that currently uses a MC68HC11A1FN but > > apparently this part is obsolete. I am wondering if using the > > MC68HC11E1CFU3 is going to be as simple as just putting this device > > in the circuit board with proper footprint layout and it will work > > just like the other device? > >Yes. > > > I don't see any major gotta's in the datasheet and it looks like it > > is almost identical with more RAM on chip. Is this an accurate > > assumption? > >I think there is an App Note (sorry, don't have a number) I'm a bit late, was on vacation, but anyway: It's the Engineering Bultein EB193. There's one trap (al least) witch is not covered by this otherwise excellent paper. I used the A1 with 32k SRAM and 32k EEPROM. So the internal RAM replaced the lowest 256 bytes of the external RAM. So far so good. But now, the external RAM is battery buffered, the internal not (saves battery life). That means all ram expect for those 256 bytes are buffered. After replacing the A1 with the E1, 512 bytes are not buffered. Of course, I had some variables in this space which needed buffering... Was a nasty thing to find out. Edi Im Hof > detailing all >differences between the A and E series. There aren't many (from memory, >something like: BPROT register is added, fourth IC added selectable as IC or >OC, etc.) but study them in case they affect your design, especially if the >default startup conditions are different for some pins. > > > I am also changing the NVSRAM from a Dallas semi DS1643AL to a > > Semitech STK12C68-S45. There will not be a RTC on the new chip since > > they want to keep the costs down and they have a need for a clock. I > > believe it should work the same minus the clock and faster access > > time. > >If the MCU isn't overloaded already, you can always implement the RTC in >software, full with calendar and leap year calculations. If implemented >correctly, the overhead is really minimal. > >To unsubscribe from this group, send an email to: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + IH electronic + Phone: ++41 52 320 90 00 + + Edi Im Hof + Fax: ++41 52 320 90 04 + + Doernlerstrasse 1, Sulz + URL: http://www.ihe.ch + + CH-8544 Rickenbach-Attikon + E-Mail: + + Switzerland + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

There is an application note discussing the issues of 'A' family vs. 'E' family parts. Perhaps someone here remembers the AN number or, better, the URL pointing to the note. Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-1065 ----- Original Message ----- From: "Edi Im Hof" <> To: <> Sent: Tuesday, October 08, 2002 5:34 AM Subject: Re: [m68HC11] MC68HC11E1CFU3 > At 21:30 15.09.02 +0300, you wrote: > >----- Original Message ----- > >From: "coolpix404" <> > >To: <> > > > > > I am re-designing a board that currently uses a MC68HC11A1FN but > > > apparently this part is obsolete. I am wondering if using the > > > MC68HC11E1CFU3 is going to be as simple as just putting this device > > > in the circuit board with proper footprint layout and it will work > > > just like the other device? > > > >Yes. > > > > > I don't see any major gotta's in the datasheet and it looks like it > > > is almost identical with more RAM on chip. Is this an accurate > > > assumption? > > > >I think there is an App Note (sorry, don't have a number) > > I'm a bit late, was on vacation, but anyway: > > It's the Engineering Bultein EB193. > > There's one trap (al least) witch is not covered by this otherwise > excellent paper. > I used the A1 with 32k SRAM and 32k EEPROM. So the internal RAM replaced > the lowest 256 bytes of the external RAM. So far so good. But now, the > external RAM is battery buffered, the internal not (saves battery life). > That means all ram expect for those 256 bytes are buffered. After replacing > the A1 with the E1, 512 bytes are not buffered. Of course, I had some > variables in this space which needed buffering... > > Was a nasty thing to find out. > > Edi Im Hof > > detailing all > >differences between the A and E series. There aren't many (from memory, > >something like: BPROT register is added, fourth IC added selectable as IC or > >OC, etc.) but study them in case they affect your design, especially if the > >default startup conditions are different for some pins. > > > > > I am also changing the NVSRAM from a Dallas semi DS1643AL to a > > > Semitech STK12C68-S45. There will not be a RTC on the new chip since > > > they want to keep the costs down and they have a need for a clock. I > > > believe it should work the same minus the clock and faster access > > > time. > > > >If the MCU isn't overloaded already, you can always implement the RTC in > >software, full with calendar and leap year calculations. If implemented > >correctly, the overhead is really minimal. > > > > > > > > > > > > > >To unsubscribe from this group, send an email to: > > > > > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > + IH electronic + Phone: ++41 52 320 90 00 + > + Edi Im Hof + Fax: ++41 52 320 90 04 + > + Doernlerstrasse 1, Sulz + URL: http://www.ihe.ch + > + CH-8544 Rickenbach-Attikon + E-Mail: + > + Switzerland + + > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > To unsubscribe from this group, send an email to:

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

It's Engineering Bulletin# EB193 located @ http://e-www.motorola.com/brdata/PDFDB/docs/EB193.pdf Paul >-----Original Message----- >From: Robert Smith [mailto:] >Sent: Tuesday, October 08, 2002 10:36 AM > >There is an application note discussing the issues of 'A' family vs. 'E' >family parts. Perhaps someone here remembers the AN number or, better, the >URL pointing to the note. > > Bob Smith

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )