MK60 / MK64 - Peripheral Sharing on Same Signals

[dusanferbas]

Hi,
sharing a pin for GPIO input and a peripheral, e.g. ADC works (pin sharing between ADC and IO output).

Is it safe to share pins of 2 peripherals, ie. physically wiring them together to use them on same signals?
As long as outputs (or peripherals) will not be enabled at once and if I expect peripheral is disconnected from a pin, if it is disabled, I think yes.
Can someone confirm this?

Dusan

[dusanferbas]

Hi @myke_predko, you are right :-).
But we will be using both peripherals exclusively and there is no space on the board, neither device has additional terminals.

We are designing a unit, which should be space constrained and fits in a 2U DIN rail box.
It also has a limited number of terminals. And it is intended to support various use cases - RS232 / RS485 / isolated inputs / DC/DC + isolated. CAN is also a possibility, 1-Wire probably too.

There can be 2 approaches - either a different board for each case or something in between terminals and cpu.  And we decided to go the 2nd way - piggy-back boards.  Then, you can have CAN or UART on a piggy-back and with a different transceiver we have a solution.  We used also different radio boards to support various radio networks.

Formerly we used the MCF51CN128, which perfectly fitted into the constrained design, modems with MKL02 are nice - see photo in an article here.  Now, we are adding a control unit in a same form to fit into nearly every occupied.cabinet.

[myke_predko]

@dusanferbas 

I wondered if you were space constrained.  

If you're using piggy-backed boards, At the very least, I recommend that you have different piggy back connector/signal options (ie an MCU input line pulled high or low) depending on the board's connections to indicate to the processor which one is plugged in.  

Good luck!  Keep us updated as to how you are doing,

myke

[dusanferbas]

Hi@myke_predko,

I kept your words in my mind, where it warm a soup of - mostly, there is a solution.

Initially, I placed 24C01 EEPROM but even if there is 1 chip available with SOT23 package, there can be a potential of creating I2C "start" condition. Finally I was browsing Maxim's and DS28E05 marched along. However its DQ will reside on a same signal as a transceiver direction one, I think they will be "frequency isolated" from each other, as 1-Wire has faster timing. And this solution also fits same board dimensions.
Adding DS28E05 for identification.

[myke_predko]

Hi @dusanferbas 

Could you explain your application timing in more detail? 

When I look at the DS28E05's datasheet, I see that it requires data timing in the range of 63.5kHz to 4MHz (DS28E05 Datasheet - in "Electrical Characteristics") which is a pretty broad band and I'm not sure what data rates you are using that would ensure that theDS28E05 ignores what's on it's "IO" pin and doesn't attempt to respond and drive the lines.  I should also point out that if the DS28E05 does drive the data line and corrupts the data going to other devices, it's going to be very difficult to identify when the corruption is taking place as you have the open drain driver in the DS28E05 pulling down the bus, exactly the same as any other device on the bus.  

Again, using the same lines for different device communication protocols is not recommended and I can't think of any cases where it will be guaranteed to be successful.  

If you're looking for non-volatile storage for your application, why don't use the Flash built into the K6x (and even choose one with built in EEPROM)?  

myke

[dusanferbas]

Hi @myke_predko ,

thank you for checking my post.

Attached schematics shows RS485 variant. Let me explain my assumptions - data signals for application are physically separated, the only conflict can be between control signals and the DQ data signal for the 1-Wire chip. Control signals are needed only for certain transceivers - a fast CAN transceiver, e.g  the ISO1042DWV does not have any control pin.

For serial, UART based, communication - our application uses max. 115200 bps, i.e. there is an 86 us time slot between guaranteed high to low signal change (start & stop bit). The longest pulse period for DS28E05 is 80 us max. So the 1-Wire is using higher frequency band and RS485 control will use lower frequency changes, because it does not make sense to turn RS485 direction in the middle of a byte transmission.

We can go even to faster UART speeds if we do not send only 1 byte, which is commonly true for packet oriented protocols. With packets of 10 bytes, we can go up to 1 Mbps transfer speed.

P.S. If we test it as unreliable, we can leave the DS28E05 unpopulated.

Dusan

[myke_predko]

Hi @dusanferbas 

That looks like a reasonable approach to adding the EEROM chip - however, there are two things that concern me.  

The first is that the power up/power down sequences are not (well) documented in the DS28E05 datasheet.  Everytime you raise or lower the pin for !RE you're going to be powering up/powering down the DS28E05.  You will definitely want to put a 'scope on the line when you are activating/deactivating !RE.  

Secondly you should be checking the signal levels on !RE when it is active (pulled low).  You have the 1k pull up as well as the "100Ohm MOSFET" on the line.  I don't know the pin you are using to drive !RE, but it should have a high power option so you get the lowest possible voltage - the 3mA of the standard IO pin may have problems with the 1k pull up, the 100Ohm load of the DS28E05 and the impedance of the ADM3485E could lead to an strange "low" voltage as well as larger than expected rise/fall times.  

I have experience with single pin devices like the DS28E05 wired to PICs and AVRs which have very specific IO Bus timing while with the Kinetis (or any ARM MCU) it's a lot fuzzier.  When you are accessing the DS28E05 I highly recommend that you disable interrupts and verify what you are doing with an oscilloscope - you should also time the operations using something like a PIT.  

Good luck!

myke

[dusanferbas]

Hi @myke_predko ,

thanks for your valuable input.

Today we discussed an influence of DQ handling to the RS485 line, which will not be affected, because !RE only enables reading from line.  So initial short time pin toggling after power up can be acceptable.

Your comment escalated me to check current conditions (you can also read my P.S. at end).  We are using pin 97 (PTD4) of MK60DN256vll10.  Kinetis has 3 mA only if Vcc < 2.7V. We use 3.3V.  Both Ioh and Iol are 9 mA for high drive strength, 2 mA for low drive strength.

When Kinetis drives the signal low, the MOSFET in 1-Wire is closed and its 100R does not influence the circuit.  You are right 3.3 mA is too much, better to use 1k2 or the limit 1k5 as per the datasheet of the DS28E05.

When DS28E05 drives the circuit low, there will be 2.5 mA current to DS28E05 - we does not care.  The voltage on Kinetis will be 250 mV (as per simulated R-divider screenshot below) which is far below 0.35 x 3.3 = 1.155 V threshold. Why do you call it "strange low" voltage? Because polite CMOS pulls down to zero?

Now the ADM3485E - it has 2 uA input current on !RE. Same has MAX3485 with minimal input impedance 1k for 1st transition only.  Why do you think this can influence circuit conditions?

---------------------
I also have experience with bit banging for 1-Wire DS18B20 and DS2438.  We measured a lot with a scope, tested different cable lengths and after playing a lot, which mostly worked, we coped with rare cases, when different DS18B20 chips behaved like phantoms - sometimes they were found twice, sometimes not found at all.  When we placed the DS2482S-100, all problems went away.

P.S. I remember current limit issue from a resistor divider used for level shifting of 100 MHz clock signal.  25 mA was needed to drive the divider to react fast enough and a gate driving it had only 4 mA current capability (AUP version vs LVC gate variant).  The gate was not found with a thermal camera and a long long time bug finding process started ...

Dusan

"Strange Low" voltage when 1-Wire transmits

[myke_predko]

Hey @dusanferbas 

It looks like you've already addressed my concerns.  

A "strange low" (for lack of a better term) is what I call it when you have multiple drivers on the line - what happens when the K6x drives the line low and the DS28E05 dumps current (stored in the device's capacitors because the line has been dropped) - you might see the line rise over the 1.155V threshold some time later.  It's probably less of an issue when the line goes high because you will be, by definition, not receiving data but the DS28E05 may cause problems on the line going low.  

With your analysis, "might see" is probably a very low probability, but I strongly suggest you scope the operation of the line during making !RE active.  

I'm cautioning you for two reasons, the first is that the power-up/power-down sequeces and current draws are not documented in the DS28E05's datasheet. 

The second is experience.  I've been in a number of situations where multiple drivers on a logic line do not work as expected.  There is the 2.5mA draw which you seem to be accouting for as well ensuring the pin is driving at 9mA but there may be something lurking out there that is going to cause a problem - it sounds like you've dealt with that type of problem before.  Going over the datasheet again, Maxim notes that mutliple one-wire devices can be on the same bus, but does not comment on using the bus for different signal types.  

Good luck!  Chances are you'll be fine, but make sure you do some testing to ensure there won't be any problems.  

myke

[dusanferbas]

@myke_predkoThe design continues well, we now tune base board stackup and are checking options for RF stackup. Insight of the device can be seen here, some screenshots from development are here, preliminary video can be watched on Youtube.

I thought about auto recognition of the boards as you are suggesting. Till now, we used to detect a presence of a piggy board with a single pullup, which was on RS232 variant. This perfectly worked and I think it prevented several errors.

But now if there are so many possibilities (6+2 planned), it is a call for I2C and a kind of EEPROM, which on the other way brings a cost for parts, pcb space and mostly required time for handling it. I am kidding :-). The main reason is there are no signals for it. Maybe we can use 2 signals (used for RS485 direction setting - 2 because of a loopback line diagnostics) in combination with a shift register, but now I decided to have it simple

Dusan

[kerryzhou]

Hi dusanferbas,

    Although you can do it like that, but to the project application, I still highly recommend you separate the CAN and UART signals, as you know, the external circuit is also different, CAN need to add the transceiver.

  So, if you still can modify the board, I think you can separate it.

Wish it helps you!

Best Regards,

Kerry

[dusanferbas]

@kerryzhou  Thanks for the comment. As I described - there ae piggy boards.

[myke_predko]

Hi @dusanferbas 

The short answer is "yes" but I'm not sure why you'd want to do that.  Normally, the issue is requiring multiple external device on a single MCU peripheral (bus) because of a lack of MCU pins (aka "IO limited").  

In your drawing you're going the other way and tying together UART IO with a CAN bus - they're quite different in operation (as well as electrical termination) and really not very compatible.  Could you explain the application?

myke