Common MCLR

I have a project that I am working on that has two PIC18's (one for system control one to drive an onboard 7 seg display) on the same board.

I am communicating via I2C. My plan is to use a button on the system mcu and send a reset command (via I2C) to the drive mcu.
Is this sufficient OR should I tie both MCLR pins to one button OR separate buttons for each mcu?

If you're planning on sending a reset command via I2C, that may not work so well. If the micro is hung up, it won't be able to act on the reset command.

If you're using ICSP, paralleling /MCLR pins to one switch will be problematic, as the programmer puts a high voltage on /MCLR to enter programming mode.

Maybe a DPST button for reset?

For The Popcorn said:

If you're planning on sending a reset command via I2C, that may not work so well. If the micro is hung up, it won't be able to act on the reset command.

Click to expand...

For The Popcorn you make a good point that I didn't think of!

I am using ICSP and had separate RJ-11 jacks for each mcu.
I like the DPST idea!

Or a couple of diodes to isolate the MCLR pins from the common switch.

One suggestion which may or may not be helpful....

I recently discovered the TM1638 LED driver chip. It drives eight 10-segment LED displays, using a simple spi-type interface. The two "extra" segments may be used to drive 16 individual LEDs. It features 8 steps of PWM dimming but the brightness of individual segments can't be changed (i.e., all segments are at the same brightness). The chip also supports reading an 8x2 switch matrix.

It's pretty easy to interface and will set you back a whooping 25 cents at LCSC.

For The Popcorn said:

One suggestion which may or may not be helpful....

I recently discovered the TM1638 LED driver chip. It drives eight 10-segment LED displays, using a simple spi-type interface. The two "extra" segments may be used to drive 16 individual LEDs. It features 8 steps of PWM dimming but the brightness of individual segments can't be changed (i.e., all segments are at the same brightness). The chip also supports reading an 8x2 switch matrix.

It's pretty easy to interface and will set you back a whooping 25 cents at LCSC.

Click to expand...

Yes, a handy little chip - I've also got a PIC C 'library' for it.

The price is certainly right!

I am communicating via I2C. My plan is to use a button on the system mcu and send a reset command (via I2C) to the drive mcu.

Click to expand...

Instead of a software reset, another option is to use an IO pin from the system uC to provide the MCLR to the drive uC. Connect the IO pin (with a pulldown) to the gate of a logic-level n-chan mosfet, connect the drain to the drive MCLR, and the src to gnd.

That way the system uC can reset the drive mcu by asserting the IO pin high. It shouldn't interfere with programming the drive mcu as long as the system isn't asserting the IO pin.

You can still have a software reset if you like

We see this a lot recently. Two chips instead of one and the complication of I²C. Why not do everything on one chip. Multiplexing a 7 segment display is trivial and should take less than 1% of the processing power. If this is done on interrupt then the main code can do the rest of it. It's probably simpler to sort out interrupts than the complications of getting Master/Slave I²C to work (which ideally needs interrupts).

Mike.

Pommie said:

We see this a lot recently. Two chips instead of one and the complication of I²C. Why not do everything on one chip. Multiplexing a 7 segment display is trivial and should take less than 1% of the processing power. If this is done on interrupt then the main code can do the rest of it. It's probably simpler to sort out interrupts than the complications of getting Master/Slave I²C to work (which ideally needs interrupts).

Mike.

Click to expand...

I see no problem with two chips - but why use I2C? - as you say it greatly complicates things. Just use a simple RS232 serial connection between the two. I2C has it's place, which was originally to interconnect IC's on TV boards, and now of course to interconnect IC's all over the place. If you're using an IC that is I2C, then it's a 'no brainer', but why on earth try and create one for little or no advantage (and I2C slave is a lot more difficult than master).

However, as you say, depending on what I/O he has available, it should be trivial to multiplex the display and do everything else from one 18F IC.

I currently use an 18F and an ESP32/SIM800 - the ESP32 does all the on-line stuff, the PIC does everything else (the display uses a MAX7219) - in particular the power handling, you can't get decent low power from the ESP32/SIM800 boards, so the PIC switches the power to it.

Pommie said:

We see this a lot recently. Two chips instead of one and the complication of I²C. Why not do everything on one chip. Multiplexing a 7 segment display is trivial and should take less than 1% of the processing power. If this is done on interrupt then the main code can do the rest of it. It's probably simpler to sort out interrupts than the complications of getting Master/Slave I²C to work (which ideally needs interrupts).

Mike.

Click to expand...

Pommie I would if I had the resources but the system mcu (40 pdip) is driving some valves and pump operation with use of 4 ADC's for thermistors temp sensors so it is pretty full.

I like farming out display driving to another chip, it just makes things easier.

The TM1638 I mentioned above is straightforward to use and only costs 25 cents in quantity 1.

TucsonDon said:

I would if I had the resources but the system mcu (40 pdip) is driving some valves and pump operation with use of 4 ADC's for thermistors temp sensors so it is pretty full.

Click to expand...

Just use 74HC or 74LS shift registers to expand the I/O
74HC595s are perfect for outputs and 74HC165 for inputs.

Or you can use MIC5841 / MIC5891 shift register based power drivers, low side or high side respectively.

You can drive all those directly from the SPI port, plus two extra pins total for input and output latch signals.
For more than one of each, cascade data outs to data ins and transfer additional bytes.
Five MCU pins for effectively unlimited digital I/O.

Each 8 bit input and 8 bit output transfer together in a single SPI transfer instruction; latch the input register data, transfer all bytes, latch the new outputs.

Updating eg. 16 inputs and 16 outputs takes just two SPI I/Os plus moving & latching & the data at the appropriate time; a few microseconds at the start of each program pass.

You need the analog inputs on the MCU itself, but just about anything else for external I/O, LED display, keyboard inputs etc. can easily be done like this.

Just keep "image" bytes for the external input and output registers in RAM variables and use those in the normal program, with everything updated in one fast burst at every pass start or end.

I guess nobody looked at the TM1638 LED driver chip I posted. It's approximately the same price as a shift register or about 16 × less than the MIC high-side driver chips. The interface uses 3 lines like a shift register.

For the 25 cent cost, you get:

● Control of up to 8 7-segment digits

● Driving 16 additional LEDs

● The ability to read 16 momentary switches in an 2 × 8 matrix.

And for the win:

● Eight levels of brightness.

All this for 25 cents.

For The Popcorn said:

I guess nobody looked at the TM1638 LED driver chip I posted.

Click to expand...

I have a TM1637 based display that handles 4 digits that I got off of ebay for a couple of dollars. Very handy.

They do a very nice TM1638 based module with lots of goodies for a few dollars.

Mike.
There's even a pdf for the module with example code.
Edit2, Hmmmm, might have to get one of these to play with.
Edit3, can't it read 24 switches? 3x8? The diagram suggests so.

Yeah, 24 switches.... I was going by memory.

The interface for the TM1637 isn't the same as the TM1638.

For The Popcorn said:

The interface for the TM1637 isn't the same as the TM1638.

Click to expand...

Yes, I've been trying to find a datasheet, I can kinda see how the DIO line works but it would be nice to have an actual datasheet. They're (datasheets) hard to find now as Arduino libraries are released instead of datasheets.

Mike.