Isolation between digital output signals and the external pins

[guribec]

Hi,

Is there isolation between:
  - digital output signals, and the
  - external pins?

In the (new)  MC9S08QE128RM.pdf  Reference Manual, page 112:
  - the output signals PTxDn are represented as being DIRECTLY connected to the output pins.

In the (old) MC68HC908GP32.pdf (Data Sheet, 2008, page 119), or similar (original User Manual, for example...):
  - there is a TRI-STATE DRIVER that isolates the signal data from the output pin.

  And there is more: Data stored in the output registers, are read (when requested):

  - NOT from the outside pin, but
  - FROM the register's output (they are isolated !).

The difference is crucial.
  - If there is NO buffering driver, and the output pin is read directly from the outside pin

    (as in Read-Modify-Write instructions, like INC),

  EXTERNAL conditions WILL affect those operations.

Could anybody state, for sure, that the NEW MC9S08QE128 has isolation

- between Output Data (output registers)
AND
- the Output PINs,

 as was the case on the OLD MC68HC908GP32?

I SUPPOUSE that, yes, THERE IS Isolation on the new devices too but, like the new documentation has dropped ALL references (pictorial and textual) to it, I  must  to  KNOW  for  SURE.

Thanks a lot.

Luis G. Uribe C.

[bigmac]

Hello Luis, and welcome to the forum. 

---

guribe wrote:

In the (new)  MC9S08QE128RM.pdf  Reference Manual, page 112:
  - the output signals PTxDn are represented as being DIRECTLY connected to the output pins.

---

I assume that you refer to fig. 6.1, which shows a simplified schematic only.  Actually, the pin connection is not shown - the individual signals for "output data" and "input data" are represented.  The additional circuitry present between these signals and the pin is somewhat more complex than for the HC908GP32 device.  The additional functionality would include -

• Output tri-state control
• Output slew rate control
• Output drive strength control
• Input pullup control
• ADC or comparator signal pick-off, with logic input disabling.

As Rocco has already said, there is no change to the coding method for GPIO pin state control.

However, be aware that there is a potential "gotcha", applicable to both device families, if changing an individual pin from input to output state (using read-modify-write process).  The required output state should be set after the pin has been changed to output.  This may contradict certain recomendations within the datasheet or reference manual.

If the required output state is set whilst the pin is an input, the following scenario could be problematic -

• An interrupt occurs after the new output state is set, but prior to the pin being set to output, and
• The ISR processing alters state of any other pin on the same GPIO port, using read-modify-write.

This will corrupt the future output state for the pin unless the current pin input state is identical to the future output state.

Regards,

Mac

[guribec]

Hi, Mac:

You and Rocco have been very kind and helpfull. Your specific tip on the potential "gotcha" is scarying. The kind of possible bugs that could come from this are very subtle and difficult to diagnose...

Changing the subject, I feel that the technical documentation is not improving compared to the old HC908. I have serious complaints against BANKED Ram information there on the chapter 4 of the MC9S08QE128RM.pdf Reference Manual. I have a remake of one page. Bellow I will atach it for your comments, if you are so kind.

Wish you the best.

Regards,

Luis G. Uribe, Simón Bolívar University, Caracas Venezuela

[bigmac]

Hello Luis,

As I have not previously used devices with paged addressing modes, perhaps you are asking the wrong person for comments.  However, I can see a reason for making use of PPAGE = 0.  This is to gain access to the flash memory that underlies the register blocks, and RAM.  Whether useful or not, PPAGE values of 1 and 3 still locate their data within the paging window, and should remain fully documented.

Regards,

Mac

[guribec]

Hi, Mac:

"I can see a reason for making use of PPAGE = 0.  This is to gain access to the flash memory that underlies the register blocks, and RAM"

No. To use PAGE0, the only thing needed is that the logical addresses fit the PAGE0 range: 0x0000-007F. Whenever the logical addresses are in this range, the CPU read the PAGE0, whith independence of the value on PPAGE register. Same for pages 1 and 3.

"Whether useful or not, PPAGE values of 1 and 3 still locate their data within the paging window, and should remain fully documented"

No; as to my understanding, PPAGE has nothing to do with addressing this pages 1 and 3 either. The only thing needed to address them is to the logical 16 bit addresses covering their respective ranges. Each time the CPU fetches something in this ranges from pages 0, 1 and 3, the acces is done from these pages, no mather what is in the PPAGE register.

This is the only way that interrupts that hit in the middle of a rutine hosted on pages 2, 4, 5, 6 or 7, run without saving PPAGE register. In this case, PPAGE will store the values: 2, 4, 5, 6 or 7 (corresponding to the routine interrupted), and the ISR will be running on pages 0, 1 or 3. As it can be seen, the code is running on pages whose numbers ID are NOT stored on the PPAGE register.

That is why I say that the original drawing is missleading. It shows PPAGE=0 to run code on PAGE 0; PPAGE=1 to run code on PAGE 1, and PPAGE=3 to run code on PAGE 3, and this NOT the case.

And this must be stated as clear as above, in the documentation. And it is not...

Thanks for all of your kind attention.

Regards,

Luis G. Uribe

[bigmac]

Hello Luis,

I do not agree with your interpretation of the memory management process.  My understanding of the reference manual is that, for a PPAGE setting of 1 or 3, the same data may be accessed from two different addresses, the normal address and via the paging window.  For example, the data at address 0x4000 would also be accessible at address 0x8000, provided register PPAGE = 1.

Be careful with the distinction between "page 0" and "PPAGE 0", which refer to totally different address ranges.  The reference manual clearly stipulates that PPAGE 0 flash, located underneath the RAM and register blocks, needs to be accessed via the paging window, (or using LAP).

A setting of PPAGE = 2 could be used when the extended flash range, and MMU, does not require to be used.  ISR code could be placed anywhere within the visible flash memory range, provided the PPAGE setting is never altered.

Regards,

Mac

[guribec]

Hi, Mac:

Thanks for the comments and your patience. Perhaps I will need to review the whoole subject again...

Anyway, it is clear for me that the documentation seems not to be improving (against the old data set: HC908)...;-(

Bye bye for now. I will come back soon, when I have more on this matters.

Best regards,

Luis G. Uribe

[rocco]

Hi Luis,

Nothing has really changed. The old HC08s and the S08s operate the same

When a pin is programmed through its data-direct-register as an input, then any read will return the level on the pin. When a pin is programmed through its data-direct-register as an output, then any read will return the value of the output register that drives the pin.

As you said, this is so that external conditions do not affect read-modify-write operations, like bit-set and bit-clear.

[guribec]

Hi, Rocco:

Thank you for your help. You are very kind.

I've seen horrible problems in Microchip's 16F familly of microcontrollers that does NOT isolate the data register from the output pins.

I was very happy working with the structure of the HC908, and worried not seeing the 3-state driver in the new handbooks.

Thanks for the tip.

Best regards,

Luis G. Uribe, Simón Bolívar University, Caracas Venezuela