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

Hi all I'm using a HC11E1 with a PSD834F2, and I use a JTAG to load the software when I make my updates (written in C and compiled using IAR-C). I'm about to write the software to allow for a serial upgrade of the software, i.e. using a PC comms link at 38K (will allow me to upgrade customers units via modem instead of having them returned). I just thought I would ask the group if they had any advice or thoughts on this before I delve in. I guess I first need to fully understand how S Records work, and then decide on whether to do any sorting on the PC side to try and minimise the instructions needed on the MCU side. My code is approx 1.5Mbits, so any sorting would be reasonably time consuming I guess. Any thoughts? Pete

______________________________
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 )

In a message dated 10/23/02 6:51:12 AM Eastern Daylight Time, writes: > I just thought > I would ask the group if they had any advice or thoughts on this before I > delve in. I guess I first need to fully understand how S Records work, and > then decide on whether to do any sorting on the PC side to try and minimise > the instructions needed on the MCU side. > My code is approx 1.5Mbits, so any sorting would be reasonably time > consuming I guess. > Any thoughts? Yep. The s-records are of course, an ascii representation of the binary rom image, so the file is twice as big as is has to be. I'd distribute a burner program with the update that can read in the s-record file to a ram array on the pc, then blow the ram array down the wire in binary 64 bytes at a time with a pacer byte from the micro like an *... the atmel roms I use have a 64 byte flash mode burn that takes 10ms per 64 byte page... so downloading 64 bytes at 38400 takes about 16ms, then the burn takes about 10ms, so thats a couple of K per sec to dl and burn. [Non-text portions of this message have been removed]

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

There is an explanation of the S-record format on: http://extensor.boom.ru/intelhex.htm If you can cope with Delphi, the source of JBug11 has code to parse and check S records, and to sort files for writing into ascending address order. Find it at: http://freespace.virgin.net/john.beatty/Jbug11_source.html Kind regards, John Beatty Peter Mackel wrote: > Hi all > > I'm using a HC11E1 with a PSD834F2, and I use a JTAG to load the software > when I make my updates (written in C and compiled using IAR-C). > > I'm about to write the software to allow for a serial upgrade of the > software, i.e. using a PC comms link at 38K (will allow me to upgrade > customers units via modem instead of having them returned). I just thought > I would ask the group if they had any advice or thoughts on this before I > delve in. I guess I first need to fully understand how S Records work, and > then decide on whether to do any sorting on the PC side to try and minimise > the instructions needed on the MCU side. > > My code is approx 1.5Mbits, so any sorting would be reasonably time > consuming I guess. > > Any thoughts? > > Pete > > 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 )

Hi Sorry, I've made a mistake with the S-record link - it describes the IntelHex format, not the Motorola S-record one! John Beatty John Beatty wrote: (snip) > There is an explanation of the S-record format on: > > http://extensor.boom.ru/intelhex.htm

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

Thoughts: 1. Convert your S19 to binary on the PC. This will most likely save you MCU code and improve speed during the update. Also, doing this on the PC simplifies the whole process because you have the chance to sort the bytes by (page/)address. Flash is programmed faster if done in rows than arbitrary locations one at a time. For simple non-paged programs, this means running any utility (like my own EXBIN) that converts S19 to BIN. If, however, the S19 employs any kind of paging, this most likely means the S19 is a 'proprietary' format so you'll need to find out exactly how the format works (consult compiler vendor/manual), Mot's S19 standard doesn't allow for pages. The binary image can then be split into different files such as PAGE1.BIN, PAGE2.BIN, etc. to make it easier to load one page at a time, or you can combine these binary files into a single file and even incorporate them into the distributed loader application, so the user only gets a single program file to execute on the PC. 2. If your board is designed so it can be set to boot mode by the user, use this mode to load the various pages of the external Flash (on the PSD). This method has the significant advantage that all code inside the board can be erased or allowed to be damaged during the update process without special treatment from the loader. So, even if the update process fails midway (power failure, user error, etc.), you have practically limitless attempts to complete the update successfully. 3. If the board cannot be set to boot mode by the user, then the loader software should most likely reside inside the board at ALL times. This requires quite a bit of effort to get it working correctly, as the page size in the PSD is quite large (16K or 32K) so if you need the remaining space (outside the few hundred bytes of the loader) for normal application code or data, it's a bit tricky how to update that. Even if adequate external RAM is available, you still need to consider how to handle incomplete updates (the board must be able to at least get back to LOADING mode even after a power failure - battery considered also, the user may forget to load new batteries before the update). If, on the other hand, you can dedicate a whole boot page for the loader, it's quite simple and similar to boot mode (plus you have enough room to create a very sophisticated fail-safe loader that can even protect user data from being erased or automatically update them to the new program's expectations). A disadvantage is that you can never update the loader page itself, and you can make sure of that by setting the read-only attribute for that page when doing the initial programming with the JTAG to protect against random attempts to erase that page, so if you have a better/faster loading method in the future, you'll be stuck with the old one for the life of your product. Your MCU program always starts by checking if the code in the remaining pages is intact (eg., using CRCs, etc.), and if it finds any problem it enters programming mode. It also enters programming mode on command by the user to perform scheduled updates. ----- Original Message ----- From: Peter Mackel <> To: <> Sent: Wednesday, October 23, 2002 12:48 PM Subject: [m68HC11] Serial update of software > Hi all > > I'm using a HC11E1 with a PSD834F2, and I use a JTAG to load the software > when I make my updates (written in C and compiled using IAR-C). > > I'm about to write the software to allow for a serial upgrade of the > software, i.e. using a PC comms link at 38K (will allow me to upgrade > customers units via modem instead of having them returned). I just thought > I would ask the group if they had any advice or thoughts on this before I > delve in. I guess I first need to fully understand how S Records work, and > then decide on whether to do any sorting on the PC side to try and minimise > the instructions needed on the MCU side. > > My code is approx 1.5Mbits, so any sorting would be reasonably time > consuming I guess. > > Any thoughts? > > Pete

______________________________
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 )

Thanks for the input. I do have a boot space as well as flash, and it is from this that I can totally reprogram the whole of the flash code, and as you said, allow for a good degree of recovery in the event of a failure! As for including the files into the loader program, this certainly has it's appeal. Seems the fewer things the customer can click on the better! ;-> For the less problem prone customer however, it would be great to be able to send them the sorted file zipped up and tell them to run their software. All good in theory....here goes! Pete -----Original Message----- From: Tony Papadimitriou [mailto:] Sent: 23 October 2002 20:36 To: Subject: Re: [m68HC11] Serial update of software Thoughts: 1. Convert your S19 to binary on the PC. This will most likely save you MCU code and improve speed during the update. Also, doing this on the PC simplifies the whole process because you have the chance to sort the bytes by (page/)address. Flash is programmed faster if done in rows than arbitrary locations one at a time. For simple non-paged programs, this means running any utility (like my own EXBIN) that converts S19 to BIN. If, however, the S19 employs any kind of paging, this most likely means the S19 is a 'proprietary' format so you'll need to find out exactly how the format works (consult compiler vendor/manual), Mot's S19 standard doesn't allow for pages. The binary image can then be split into different files such as PAGE1.BIN, PAGE2.BIN, etc. to make it easier to load one page at a time, or you can combine these binary files into a single file and even incorporate them into the distributed loader application, so the user only gets a single program file to execute on the PC. 2. If your board is designed so it can be set to boot mode by the user, use this mode to load the various pages of the external Flash (on the PSD). This method has the significant advantage that all code inside the board can be erased or allowed to be damaged during the update process without special treatment from the loader. So, even if the update process fails midway (power failure, user error, etc.), you have practically limitless attempts to complete the update successfully. 3. If the board cannot be set to boot mode by the user, then the loader software should most likely reside inside the board at ALL times. This requires quite a bit of effort to get it working correctly, as the page size in the PSD is quite large (16K or 32K) so if you need the remaining space (outside the few hundred bytes of the loader) for normal application code or data, it's a bit tricky how to update that. Even if adequate external RAM is available, you still need to consider how to handle incomplete updates (the board must be able to at least get back to LOADING mode even after a power failure - battery considered also, the user may forget to load new batteries before the update). If, on the other hand, you can dedicate a whole boot page for the loader, it's quite simple and similar to boot mode (plus you have enough room to create a very sophisticated fail-safe loader that can even protect user data from being erased or automatically update them to the new program's expectations). A disadvantage is that you can never update the loader page itself, and you can make sure of that by setting the read-only attribute for that page when doing the initial programming with the JTAG to protect against random attempts to erase that page, so if you have a better/faster loading method in the future, you'll be stuck with the old one for the life of your product. Your MCU program always starts by checking if the code in the remaining pages is intact (eg., using CRCs, etc.), and if it finds any problem it enters programming mode. It also enters programming mode on command by the user to perform scheduled updates. ----- Original Message ----- From: Peter Mackel <> To: <> Sent: Wednesday, October 23, 2002 12:48 PM Subject: [m68HC11] Serial update of software > Hi all > > I'm using a HC11E1 with a PSD834F2, and I use a JTAG to load the software > when I make my updates (written in C and compiled using IAR-C). > > I'm about to write the software to allow for a serial upgrade of the > software, i.e. using a PC comms link at 38K (will allow me to upgrade > customers units via modem instead of having them returned). I just thought > I would ask the group if they had any advice or thoughts on this before I > delve in. I guess I first need to fully understand how S Records work, and > then decide on whether to do any sorting on the PC side to try and minimise > the instructions needed on the MCU side. > > My code is approx 1.5Mbits, so any sorting would be reasonably time > consuming I guess. > > Any thoughts? > > Pete 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 )

If this is not posted to the wrong list, I would like to know more about MC68HC11's that have Flash memory. What is the part number?? Perhaps you are talking about a WaferScale PSD chip? 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: "Peter Mackel" <> To: <> Sent: Thursday, October 24, 2002 9:41 AM Subject: RE: [m68HC11] Serial update of software > Thanks for the input. > > I do have a boot space as well as flash, and it is from this that I can > totally reprogram the whole of the flash code, and as you said, allow for a > good degree of recovery in the event of a failure! > > As for including the files into the loader program, this certainly has it's > appeal. Seems the fewer things the customer can click on the better! ;-> > For the less problem prone customer however, it would be great to be able to > send them the sorted file zipped up and tell them to run their software. > > All good in theory....here goes! > > Pete > > -----Original Message----- > From: Tony Papadimitriou [mailto:] > Sent: 23 October 2002 20:36 > To: > Subject: Re: [m68HC11] Serial update of software > Thoughts: > > 1. Convert your S19 to binary on the PC. This will most likely save > you MCU code and improve speed during the update. Also, doing this on > the PC simplifies the whole process because you have the chance to > sort the bytes by (page/)address. Flash is programmed faster if done > in rows than arbitrary locations one at a time. For simple non-paged > programs, this means running any utility (like my own EXBIN) that > converts S19 to BIN. If, however, the S19 employs any kind of paging, > this most likely means the S19 is a 'proprietary' format so you'll > need to find out exactly how the format works (consult compiler > vendor/manual), Mot's S19 standard doesn't allow for pages. The > binary image can then be split into different files such as PAGE1.BIN, > PAGE2.BIN, etc. to make it easier to load one page at a time, or you > can combine these binary files into a single file and even incorporate > them into the distributed loader application, so the user only gets a > single program file to execute on the PC. > > 2. If your board is designed so it can be set to boot mode by the > user, use this mode to load the various pages of the external Flash > (on the PSD). This method has the significant advantage that all code > inside the board can be erased or allowed to be damaged during the > update process without special treatment from the loader. So, even if > the update process fails midway (power failure, user error, etc.), you > have practically limitless attempts to complete the update > successfully. > > 3. If the board cannot be set to boot mode by the user, then the > loader software should most likely reside inside the board at ALL > times. This requires quite a bit of effort to get it working > correctly, as the page size in the PSD is quite large (16K or 32K) so > if you need the remaining space (outside the few hundred bytes of the > loader) for normal application code or data, it's a bit tricky how to > update that. Even if adequate external RAM is available, you still > need to consider how to handle incomplete updates (the board must be > able to at least get back to LOADING mode even after a power failure - > battery considered also, the user may forget to load new batteries > before the update). If, on the other hand, you can dedicate a whole > boot page for the loader, it's quite simple and similar to boot mode > (plus you have enough room to create a very sophisticated fail-safe > loader that can even protect user data from being erased or > automatically update them to the new program's expectations). A > disadvantage is that you can never update the loader page itself, and > you can make sure of that by setting the read-only attribute for that > page when doing the initial programming with the JTAG to protect > against random attempts to erase that page, so if you have a > better/faster loading method in the future, you'll be stuck with the > old one for the life of your product. Your MCU program always starts > by checking if the code in the remaining pages is intact (eg., using > CRCs, etc.), and if it finds any problem it enters programming mode. > It also enters programming mode on command by the user to perform > scheduled updates. > > > ----- Original Message ----- > From: Peter Mackel <> > To: <> > Sent: Wednesday, October 23, 2002 12:48 PM > Subject: [m68HC11] Serial update of software > > Hi all > > > > I'm using a HC11E1 with a PSD834F2, and I use a JTAG to load the > software > > when I make my updates (written in C and compiled using IAR-C). > > > > I'm about to write the software to allow for a serial upgrade of the > > software, i.e. using a PC comms link at 38K (will allow me to > upgrade > > customers units via modem instead of having them returned). I just > thought > > I would ask the group if they had any advice or thoughts on this > before I > > delve in. I guess I first need to fully understand how S Records > work, and > > then decide on whether to do any sorting on the PC side to try and > minimise > > the instructions needed on the MCU side. > > > > My code is approx 1.5Mbits, so any sorting would be reasonably time > > consuming I guess. > > > > Any thoughts? > > > > Pete > To unsubscribe from this group, send an email to: > > 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 01:48 PM 24/10/02 -0400, you wrote: >If this is not posted to the wrong list, I would like to know more about >MC68HC11's that have Flash memory. What is the part number?? Perhaps you >are talking about a WaferScale PSD chip? We would really love to have our 68HC911 wouldn't we :-) Oh did I mention that before???? Regards John Samperi ****************************************************** Ampertronics Pty. Ltd. 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA Tel. (02) 9674-6495 Fax (02) 9674-8745 Email: Website http://ampertronics.com.au * Electronic Design * Technical Services * Contract Assembly ******************************************************

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

Yes Bob I am talking about the PSD834F2 chip. I use this list though as it's so commonly used with the HC11 MCU that I often find it a great way to get information. Often when I go down the route of PSD I find their apps notes are not relevant to my application, and the same with when I go down the HC11 route. As a user, I often find that other users experience surpasses any Mot apps notes. ;-> Pete -----Original Message----- From: Robert Smith [mailto:] Sent: 24 October 2002 18:49 To: Subject: Re: [m68HC11] Serial update of software If this is not posted to the wrong list, I would like to know more about MC68HC11's that have Flash memory. What is the part number?? Perhaps you are talking about a WaferScale PSD chip? 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: "Peter Mackel" <> To: <> Sent: Thursday, October 24, 2002 9:41 AM Subject: RE: [m68HC11] Serial update of software > Thanks for the input. > > I do have a boot space as well as flash, and it is from this that I can > totally reprogram the whole of the flash code, and as you said, allow for a > good degree of recovery in the event of a failure! > > As for including the files into the loader program, this certainly has it's > appeal. Seems the fewer things the customer can click on the better! ;-> > For the less problem prone customer however, it would be great to be able to > send them the sorted file zipped up and tell them to run their software. > > All good in theory....here goes! > > Pete > > -----Original Message----- > From: Tony Papadimitriou [mailto:] > Sent: 23 October 2002 20:36 > To: > Subject: Re: [m68HC11] Serial update of software > Thoughts: > > 1. Convert your S19 to binary on the PC. This will most likely save > you MCU code and improve speed during the update. Also, doing this on > the PC simplifies the whole process because you have the chance to > sort the bytes by (page/)address. Flash is programmed faster if done > in rows than arbitrary locations one at a time. For simple non-paged > programs, this means running any utility (like my own EXBIN) that > converts S19 to BIN. If, however, the S19 employs any kind of paging, > this most likely means the S19 is a 'proprietary' format so you'll > need to find out exactly how the format works (consult compiler > vendor/manual), Mot's S19 standard doesn't allow for pages. The > binary image can then be split into different files such as PAGE1.BIN, > PAGE2.BIN, etc. to make it easier to load one page at a time, or you > can combine these binary files into a single file and even incorporate > them into the distributed loader application, so the user only gets a > single program file to execute on the PC. > > 2. If your board is designed so it can be set to boot mode by the > user, use this mode to load the various pages of the external Flash > (on the PSD). This method has the significant advantage that all code > inside the board can be erased or allowed to be damaged during the > update process without special treatment from the loader. So, even if > the update process fails midway (power failure, user error, etc.), you > have practically limitless attempts to complete the update > successfully. > > 3. If the board cannot be set to boot mode by the user, then the > loader software should most likely reside inside the board at ALL > times. This requires quite a bit of effort to get it working > correctly, as the page size in the PSD is quite large (16K or 32K) so > if you need the remaining space (outside the few hundred bytes of the > loader) for normal application code or data, it's a bit tricky how to > update that. Even if adequate external RAM is available, you still > need to consider how to handle incomplete updates (the board must be > able to at least get back to LOADING mode even after a power failure - > battery considered also, the user may forget to load new batteries > before the update). If, on the other hand, you can dedicate a whole > boot page for the loader, it's quite simple and similar to boot mode > (plus you have enough room to create a very sophisticated fail-safe > loader that can even protect user data from being erased or > automatically update them to the new program's expectations). A > disadvantage is that you can never update the loader page itself, and > you can make sure of that by setting the read-only attribute for that > page when doing the initial programming with the JTAG to protect > against random attempts to erase that page, so if you have a > better/faster loading method in the future, you'll be stuck with the > old one for the life of your product. Your MCU program always starts > by checking if the code in the remaining pages is intact (eg., using > CRCs, etc.), and if it finds any problem it enters programming mode. > It also enters programming mode on command by the user to perform > scheduled updates. > > > ----- Original Message ----- > From: Peter Mackel <> > To: <> > Sent: Wednesday, October 23, 2002 12:48 PM > Subject: [m68HC11] Serial update of software > > Hi all > > > > I'm using a HC11E1 with a PSD834F2, and I use a JTAG to load the > software > > when I make my updates (written in C and compiled using IAR-C). > > > > I'm about to write the software to allow for a serial upgrade of the > > software, i.e. using a PC comms link at 38K (will allow me to > upgrade > > customers units via modem instead of having them returned). I just > thought > > I would ask the group if they had any advice or thoughts on this > before I > > delve in. I guess I first need to fully understand how S Records > work, and > > then decide on whether to do any sorting on the PC side to try and > minimise > > the instructions needed on the MCU side. > > > > My code is approx 1.5Mbits, so any sorting would be reasonably time > > consuming I guess. > > > > Any thoughts? > > > > Pete > To unsubscribe from this group, send an email to: > > To unsubscribe from this group, send an email to: 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 )

In a message dated 10/25/02 1:20:09 AM Pacific Daylight Time, writes: > Apparently, Mot > thinks not updating the HC11 will help its HC12 line, my opinion is > they are somewhat misled for various reasons, one being that when you > must switch to another toolset/language, you can go several different > directions than the intended one, so you'd better not get them to > switch at all in the first place -- see Intel history with the 808x, > if they had traveled along the path of incompatible updates, the > setting would be very different today for the PC market AMEN [Non-text portions of this message have been removed]

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

The discussion was for ST's (formerly Waferscale's) PSD chips used along with HC11s. Sadly, HC11 with Flash memory is a dream not likely to realize. Nevertheless, PSDs would be used even if there were Flash-based HC11 parts because they offer more than just Flash, e.g., extra pins, extra RAM, CPLD (some parts), pin-compatible upgrades, etc. Side note (not meant to stir up this peaceful list): Apparently, Mot thinks not updating the HC11 will help its HC12 line, my opinion is they are somewhat misled for various reasons, one being that when you must switch to another toolset/language, you can go several different directions than the intended one, so you'd better not get them to switch at all in the first place -- see Intel history with the 808x, if they had traveled along the path of incompatible updates, the setting would be very different today for the PC market (arguably for the better, in some respects). Price is also a very significant ingredient of a newer product meant to replace another. For example, it seems to me the HC08 is likely to become a quick success because it managed to draw attention both from HC05 (with 100% upward compatibility) and HC11 users (for its flash, acceptable language power, and lower price), not to mention other manufacturers' fans. ----- Original Message ----- From: Robert Smith <> To: <> Sent: Thursday, October 24, 2002 7:48 PM Subject: Re: [m68HC11] Serial update of software > If this is not posted to the wrong list, I would like to know more about > MC68HC11's that have Flash memory. What is the part number?? Perhaps you > are talking about a WaferScale PSD chip? > > Bob Smith

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

At 11:19 AM 25/10/02 +0200, you wrote: >Side note (not meant to stir up this peaceful list): Stir away. Who knows! Remember "the ant that could not move a rubber tree plant"? May be Motorola is a little rubbery and a few "ants" may help in changing their mind....or may make them more stubborn. Who are we to demand what we want anyway? :-) >Apparently, Mot >thinks not updating the HC11 will help its HC12 line, my opinion is >they are somewhat misled Fully agree. It has turned me completely away from the HC12. >for various reasons, one being that when you >must switch to another toolset/language, you can go several different >directions than the intended one, That's what happened to me and to many others on the list that I know of. >it seems to me the HC08 is likely to become a quick success because it >managed to draw attention both from HC05 (with 100% upward >compatibility) and HC11 users (for its flash, acceptable language >power, and lower price), not to mention other manufacturers' fans. I was very much interested in the HC08 when it was first announced but only as a replacement for the HC05. The more I was pushed the HC08 way as a replacement for the HC11 the more I started looking (succesfully) for non Motorola products. But then again I'm a hard headed, Sicilian born mug! Obviously not everyone thinks like me (thank goodness). If I get pushed hard enough I may start using 12AX7 as a basis for new products! Regards John Samperi ****************************************************** Ampertronics Pty. Ltd. 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA Tel. (02) 9674-6495 Fax (02) 9674-8745 Email: Website http://ampertronics.com.au * Electronic Design * Technical Services * Contract Assembly ******************************************************

______________________________
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 )

In a message dated 10/25/02 4:53:39 PM Pacific Daylight Time, writes: > I may start using 12AX7 as a basis for new products! > I still have a couple if needed! Dan [Non-text portions of this message have been removed]

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

But then again I'm a hard headed, Sicilian born > mug! Obviously not everyone thinks like me (thank goodness). If I get > pushed hard enough I may start using 12AX7 as a basis for new products! Sorry John, Sicilians don't have a corner on Titanium brain cases. Try a hard headed German like me for stubborn. I've got a whole grocery sack full of (slightly used) 12AX7s. They came out of the glow-in-the-dark" computer in the Nashua Air Route Traffic Control Center from back in the 60s. They replaced about a hundred of them every night during scheduled P.M. Shall I send you a dozen or so for your first digital toaster? Do you remember the ruggedized 12AX7, the 8894 or some such. I used to build flip-flops out of them in the early 60s. The ultimate FET. Good luck, 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: "John Samperi" <> To: <> Sent: Friday, October 25, 2002 7:13 PM Subject: Re: [m68HC11] Serial update of software > At 11:19 AM 25/10/02 +0200, you wrote: > >Side note (not meant to stir up this peaceful list): > > Stir away. Who knows! Remember "the ant that could not move > a rubber tree plant"? May be Motorola is a little rubbery and a few > "ants" may help in changing their mind....or may make them more > stubborn. Who are we to demand what we want anyway? :-) > > >Apparently, Mot > >thinks not updating the HC11 will help its HC12 line, my opinion is > >they are somewhat misled > > Fully agree. It has turned me completely away from the HC12. > > >for various reasons, one being that when you > >must switch to another toolset/language, you can go several different > >directions than the intended one, > > That's what happened to me and to many others on the list that I know > of. > > >it seems to me the HC08 is likely to become a quick success because it > >managed to draw attention both from HC05 (with 100% upward > >compatibility) and HC11 users (for its flash, acceptable language > >power, and lower price), not to mention other manufacturers' fans. > > I was very much interested in the HC08 when it was first announced > but only as a replacement for the HC05. The more I was pushed the HC08 > way as a replacement for the HC11 the more I started looking (succesfully) > for non Motorola products. But then again I'm a hard headed, Sicilian born > mug! Obviously not everyone thinks like me (thank goodness). If I get > pushed hard enough I may start using 12AX7 as a basis for new products! > Regards > > John Samperi > > ****************************************************** > Ampertronics Pty. Ltd. > 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA > Tel. (02) 9674-6495 Fax (02) 9674-8745 > Email: > Website http://ampertronics.com.au > * Electronic Design * Technical Services * Contract Assembly > ****************************************************** > To unsubscribe from this group, send an email to:

______________________________
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 )

In a message dated 10/26/02 9:12:23 AM Eastern Daylight Time, writes: > I've got a whole grocery sack full of (slightly used) 12AX7s. Yo Bob... this is still the standard dual triode in guitar preamps, and highly coveted by amp repair mavens... they are very pricy due to scarcity... russian and chinese copies are used.... check the price on ebay..... you might be pleasantly surprised.... [Non-text portions of this message have been removed]

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

Bob, just as a comment: Jameco has a tube tester, microprocessor controlled with a LCD. 30 years ago, when I used 12AX7 for audio preamps, I could never think about a microprocessor testing a tube !!! :0) Regards, Roberto Guillermo Berner Boolean General ICQ 119529928 54 11 4308 3500 54 11 4308 3700 15 5122 6095 ----- Original Message ----- From: To: Sent: Saturday, October 26, 2002 12:47 PM Subject: Re: [m68HC11] Serial update of software In a message dated 10/26/02 9:12:23 AM Eastern Daylight Time, writes: > I've got a whole grocery sack full of (slightly used) 12AX7s. Yo Bob... this is still the standard dual triode in guitar preamps, and highly coveted by amp repair mavens... they are very pricy due to scarcity... russian and chinese copies are used.... check the price on ebay..... you might be pleasantly surprised.... [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT To unsubscribe from this group, send an email to: 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 m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )