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

I thought it might be of some interest to the members of this group to hear about the latest HC11 project I am working on, which may be of some use to those here: A HC11 "slave I/O controller". I have a few comments and questions to offer with regard to this project that I would appreciate commentary on. I have a fairly large quantity of already-programmed 711E9 and 711E20 devices that are leftovers from a project I worked on a few years ago. I have been thinking of ideas as to how I could make use of these devices, short of using them in a expanded-mode application. One idea I came up with is to make use of these devices as general-purpose I/O controllers, using the internal EEPROM to store the small control program that would implement this capability. The goal of this project is to create a small program that will fit in the 512-byte EEPROM space that will allow one to use a HC11 as a general-purpose I/O device. Some of the features it will incorporate are: - Connects to host (master) via SCI or SPI (assembly option) - When SCI is used as comm channel, an optional "addressable" mode will be available, allowing multiple slave devices to share the same SCI channel (assembly option). - When SPI is used as comm channel, an optional "handshake" mode will be avalable, that will use the STRB output as a interrupt or busy-state signal to the host, so the host can properly 'pace' transmissions to the slave controller (assembly option). - Code will be written to use the absolute minimum amount of RAM necessary to perform its functions, leaving the bulk of the internal RAM free for the host to use as it sees fit. Code will be written such that various types of RAM used by the controller (direct, extended, stack) can be easily re-located. - Numerous assembly-time options will be provided to tailor the code generation for a given application (some of these options have been cited above). - Commands understood by the interpreter will include: = Read/write byte/word from/to zero-page, IO-page, extended (16-bit address) or "last address referenced", with optional address post-increment or decrement. = Read-modify-write (bit manipulation) byte/word write operations with similar features as above. Operations to include AND (bit mask), OR (bit set), XOR (bit toggle) and NAND (bit clear). = Execute subroutine at specified address (typically, a small program in RAM that you upload using the memory-write operations) = NOP and soft-reset opcodes. = Commands will consist of an optional device address byte (when SCI addressed mode is enabled), a single bitmapped opcode byte, and 0-3 data bytes, depending on the addressing mode selected by the opcode. The above command set will allow one to utilize almost all of the HC11's I/O lines and internal subsystems. I have pretty much finished writing the code for this application, but I have not tested it yet. The worst-case size for the code (SCI addressed mode, most variables located in page 1, all optional features turned on) is $1ED bytes. This is small enough to fit within the internal EEPROM of any HC11 device that provides it. I do have one question that I am hoping someone can offer me some advice on. As many of you know, if one wants to auto-execute a program in EEPROM after reset (on a non-E2 device with EEPROM at $B600), the bootloader can be configured to do this if PD0 (RXD) and PD1 (TXD) are connected together while the bootloader is in its initialization stage. Unfortunately, this condition is not very desirable for my application, which can (potentially) make use of the SCI - either as a control port, or as a user peripheral when the SPI is used as the host interface. I have given some thought to ways that I could *temporarily* achieve an electrical connection between PD0 and PD1 after reset that would satisfy the bootloader's jump-to-EEPROM condition, while releasing this connection sometime after the EEPROM code gains control (thus allowing the SCI to function normally). While I have thought of several solutions that would do the job, nothing that I have come up with so far is very satisfactory. The ideal solution would be one that used a minimum of components (e.g. a single transistor and a few passives) that would release the PD0-PD1 connection sometime after the bootloader passes control to EEPROM, either automatically (timed interval) or via use of a HC11 port pin. Does anybody have any ideas on how I might go about doing this simply, cheaply and elegantly ? Also, once I have finished debugging this application, I'd like to find a HC11/microcontroller-oriented website that would be willing to serve as a host for the final results (source code, documentation, etc.) I might have other future projects for the HC11 (and other) controllers that I would like to find a home for. I would welcome your comments, suggestions, ideas, etc. regarding this project.

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

An NE7555 cmos timer (8-bit DIP) set up as a one-shot is my immediate thought. Am I right in assuming that you cannot accommodate a DIP device? Have you considered (or can you accept) "dead bug" style construction? That solves any PCB wiring problems - at some expense to aesthetics! Regards,jem

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

Mark, Just a another (more elegant) thought to work on- Can you make the Tx/Rx booting loop with the highest value resister that will work, leave it in place during normal operation, but simply overwhelm it with REAL incoming traffic Rx signals? Regards,jem

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

--- In , "John" <jmacey_au@y...> wrote: > An NE7555 cmos timer (8-bit DIP) set up as a one-shot is my > immediate thought. Yea, I thought of that one too - or an equivalent approach using a 4538 one-shot. My deisgn does not have any problem accomodating DIPs (it is being built on a breadboard), but just the same, I was hoping to minimize part count and keep things as simple as possible. > Am I right in assuming that you cannot accommodate a DIP device? No problem using a DIP device - but I do have a space-constraint problem, and was hoping for a more elegant, simple solution. > Have you considered (or can you accept) "dead bug" style > construction? Not sure what you mean by this. Are you suggesting a manual approach, where one would reset the part with a PD0-to-PD1 jumper in place, then remove the jumper post-reset? Not really practical for my purposes. Or, are you suggesting (under the assumption that I could not use DIP parts) that I flatten the leads out and build the circuit 'boardless' ? I've done that too in a pinch, but it's not applicable to my build (see above). > That solves any PCB wiring problems - at some expense to > aesthetics! Thanks for your suggestions.

______________________________
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 , "John" <jmacey_au@y...> wrote: > Mark, > > Just a another (more elegant) thought to work on- > > Can you make the Tx/Rx booting loop with the highest value > resister that will work, leave it in place during normal > operation, but simply overwhelm it with REAL incoming traffic > Rx signals? Yea, that's a thought, and it would work in a single-master / single- slave (SCI) configuration. It would probably not work if one were using the SCI in a "multidrop" configuration with multiple slave controllers tied to the same host Tx/Rx. It *might* work if one were to ensure that all the slave devices shared a common -RESET signal, and were all driven by the same clock source. If one could ensure that all the devices were running perfectly in-sync (at least up to and including the point in time where the BS ROM was performing its init sequence) your idea just might work. One would also have to ensure that the host controller's TXD output was in hi- Z mode when the slave controllers are reset, but as this is the default case when a HC11 is reset, odds are that this caveat would not present a problem. Thanks for the idea, I'll give it a try.

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

Mark -- Thinking in terms of standard logic as opposed to some clever analog "tricks" or timers, I think a very simple SET-RESET flip-flop (perhaps a pair of spare cross coupled NAND gates) and one of the tiny SOT-5 analog switchs (see Maxim) would do it. Connect the RESET line of the HC11 to the SET input fo the F-F and connect the RESET input to a spare I/O pin on the HC11. The I/O pin of the HC11 will be programmed as an input out of RESET so you may want to consider a weak pull up or down to hold it stable until you complete your bootstrap procedure when you would set it as an output and RESET the F-F thus releasing the Td to Rd gate for communications. Bear in mind that the RESET line is bi-directional and will hold the F-F in the SET condition for a few clock cycles after reset thus assuring that the F-F is correctly initialized at power up. I haven't thought it though completely but you may find that an AND gate or an EXOR gate more suited to switching the Rd / Td connection than an analog switch since they are TTL signals anyway. Have more fun, Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-2608 ----- Original Message ----- From: "Mark Schultz" <> To: <> Sent: Wednesday, May 12, 2004 7:54 PM Subject: [m68HC11] My latest project: HC11 slave I/O controller > I thought it might be of some interest to the members of this group > to hear about the latest HC11 project I am working on, which may be > of some use to those here: A HC11 "slave I/O controller". I have a > few comments and questions to offer with regard to this project that > I would appreciate commentary on. > > I have a fairly large quantity of already-programmed 711E9 and > 711E20 devices that are leftovers from a project I worked on a few > years ago. I have been thinking of ideas as to how I could make use > of these devices, short of using them in a expanded-mode > application. One idea I came up with is to make use of these > devices as general-purpose I/O controllers, using the internal > EEPROM to store the small control program that would implement this > capability. > > The goal of this project is to create a small program that will fit > in the 512-byte EEPROM space that will allow one to use a HC11 as a > general-purpose I/O device. Some of the features it will > incorporate are: > > - Connects to host (master) via SCI or SPI (assembly option) > > - When SCI is used as comm channel, an optional "addressable" mode > will be available, allowing multiple slave devices to share the > same SCI channel (assembly option). > > - When SPI is used as comm channel, an optional "handshake" mode > will be avalable, that will use the STRB output as a interrupt or > busy-state signal to the host, so the host can properly 'pace' > transmissions to the slave controller (assembly option). > > - Code will be written to use the absolute minimum amount of RAM > necessary to perform its functions, leaving the bulk of the > internal RAM free for the host to use as it sees fit. Code will > be written such that various types of RAM used by the controller > (direct, extended, stack) can be easily re-located. > > - Numerous assembly-time options will be provided to tailor the > code generation for a given application (some of these options > have been cited above). > > - Commands understood by the interpreter will include: > = Read/write byte/word from/to zero-page, IO-page, extended (16-bit > address) or "last address referenced", with optional address > post-increment or decrement. > = Read-modify-write (bit manipulation) byte/word write operations > with similar features as above. Operations to include AND (bit > mask), OR (bit set), XOR (bit toggle) and NAND (bit clear). > = Execute subroutine at specified address (typically, a small > program in RAM that you upload using the memory-write operations) > = NOP and soft-reset opcodes. > = Commands will consist of an optional device address byte (when > SCI addressed mode is enabled), a single bitmapped opcode byte, > and 0-3 data bytes, depending on the addressing mode selected > by the opcode. > > The above command set will allow one to utilize almost all of the > HC11's I/O lines and internal subsystems. > > I have pretty much finished writing the code for this application, > but I have not tested it yet. The worst-case size for the code (SCI > addressed mode, most variables located in page 1, all optional > features turned on) is $1ED bytes. This is small enough to fit > within the internal EEPROM of any HC11 device that provides it. > > I do have one question that I am hoping someone can offer me some > advice on. As many of you know, if one wants to auto-execute a > program in EEPROM after reset (on a non-E2 device with EEPROM at > $B600), the bootloader can be configured to do this if PD0 (RXD) and > PD1 (TXD) are connected together while the bootloader is in its > initialization stage. Unfortunately, this condition is not very > desirable for my application, which can (potentially) make use of > the SCI - either as a control port, or as a user peripheral when the > SPI is used as the host interface. I have given some thought to > ways that I could *temporarily* achieve an electrical connection > between PD0 and PD1 after reset that would satisfy the bootloader's > jump-to-EEPROM condition, while releasing this connection sometime > after the EEPROM code gains control (thus allowing the SCI to > function normally). While I have thought of several solutions that > would do the job, nothing that I have come up with so far is very > satisfactory. The ideal solution would be one that used a minimum > of components (e.g. a single transistor and a few passives) that > would release the PD0-PD1 connection sometime after the bootloader > passes control to EEPROM, either automatically (timed interval) or > via use of a HC11 port pin. Does anybody have any ideas on how I > might go about doing this simply, cheaply and elegantly ? > > Also, once I have finished debugging this application, I'd like to > find a HC11/microcontroller-oriented website that would be willing > to serve as a host for the final results (source code, > documentation, etc.) I might have other future projects for the > HC11 (and other) controllers that I would like to find a home for. > > I would welcome your comments, suggestions, ideas, etc. regarding > this project. > > > -------------------------------------------------------------------------- ------ > Yahoo! Groups Links > > a.. To

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

--- In , "Mark Schultz" <n9xmj@y...> wrote: > Yea, that's a thought, and it would work in a single-master / >single- slave (SCI) configuration. > It would probably not work if one were using the SCI in >a "multidrop" configuration with multiple slave >controllers tied to the same host Tx/Rx.... > Thanks for the idea, I'll give it a try.... You are welcome to the idea Mark- (as we say in Oz "leave the money on the fridge" - nice to give something back to the group. The concept was based on the fact that REAL sources are relatively low-impedance drivers, so that any signal from a high impedance loop would be insignificant/overwhemed during normal operation. I don't know enough about "multidrop" operation to comment, except to wonder if somehow "disconnecting" active SCI I/O would need to be a pre-requisite to uP re-booting. If so, some form of switch seems necessary. Regards, jem

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

--- In , "John" <jmacey_au@y...> wrote: > I don't know enough about "multidrop" operation to comment, except > to wonder if somehow "disconnecting" active SCI I/O would need to > be a pre-requisite to uP re-booting. If so, some form of switch > seems necessary. One of the more esoteric features that the HC11 offers is the ability to configure Port C and/or Port D such that their outputs operate in "wire-OR" mode. Essentially, enabling wire-OR mode for either port inhibits the high-side output driver FET on all outputs for that port. Thus, a output pin on a port in wire-OR mode will sink current when set to output a low level, but not source it when set to output a high level. If you think through the implications of this mode, you will find that it is possible, under properly controlled conditions, to connect multiple 'output' signals to a common bus - in the case I cite, this would involve connecting multiple slave-device PD1 (TXD) outputs together, feeding the common connection to the host device PD0 (RXD) input. As long as one has a pullup resistor attached to the common bus, and only one slave device is 'talking' (transmitting) at any given time, it is possible to have multiple transmitters attached to a common receive input. After taking a close look at the bootloader code, and considering the fact that the port D pins on the host will be in high-impedance (input) mode after reset, and also bearing in mind that the bootloader configures the slave-device Port D's to use wire-or mode, I think I have come up with a solution that will work if the host actively monitors and controls its PD0/PD1 during startup. Consider this setup: Host ________ Vss | | RXD/PD0 |---------o-------------o------ . . . o . ---/\/\/---o | | | . 2.2K | TXD/PD1 |----o----|--------o----|------ .o. . . . ---/\/\/---o ________| | | | | . . 2.2K __|____|__ __|____|__ .......... | PD0 PD1 | | PD0 PD1 | . PD0 PD1 . | RXD TXD | | RXD TXD | . RXD TXD . | Slave 1 | | Slave 2 | . Slave n . Immediately after reset (of all devices), all PDx I/Os will be in high-impedance input mode, and the pullups on the RXD and TXD lines will bring both to a high level. The init code on the host would (temporarily) keep its PD0/PD1 lines in input mode. When the bootloader code on the slaves starts up, it places its Port D(s) in wire-or mode, and shortly thereafter transmits a continuous space (break/low level) on its PD1/TXD pin(s). This will force the common slave TXD/master RXD bus line low. The init code on the host waits until it sees the low level on its PD0/RXD input, then responds (after a short delay) by placing a low (space/break) level on its PD1/TXD output and configuring PD1 as an output. The bootloader detects this signal transition, then waits until its SCI indicates a data byte received (one byte time at 7812 bps). If the host continues to hold its PD1/TXD output low during this time, the bootloader will read a $00 byte and initiate a jump to EEPROM. The host can then (after another short delay) configure its Port D and SCI for normal operation. I'll have to give this a try.

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