I'm trying to find a solution to the ISP peripheral components programming interference conundrum of this chip... and so far the only thing I can think of is using an analog switch on each of the chip's programming pins to reroute their connections from whatever they're connected to, to the Pickit3 programmer's I/O's. So as to avoid any conflicts during the programming process.

@joeyd999 , I remember following a thread of yours a year or so ago in which you needed to find a low-power analog switch IC for one of your projects. Was that for an applications such as this? What chip in particular did you end up using?

 

I was the one that posted the switch for joey

 

I used a simple slide switch for ISP/PIN switching.
https://www.digikey.com/product-detail/en/c-k/JS202011SCQN/401-2002-1-ND/1640098

 

Thanks for the suggestion, NSA. But I'm trying to find a solid state option since the circuit will be completely enclosed and sealed, and only 5 (or maybe 6) headers will be protruding from it for reprogramming purposes.

 

I was the one that posted the switch for joey

I think I remember now ... so what chip was used in the end? was it for this same purpose?

 

Thanks for the suggestion, NSA. But I'm trying to find a solid state option since the circuit will be completely enclosed and sealed, and only 5 (or maybe 6) headers will be protruding from it for reprogramming purposes.

Maybe something like this then:
http://www.ti.com/lit/ds/symlink/ts5a23157.pdf

 

Maybe something like this then:
http://www.ti.com/lit/ds/symlink/ts5a23157.pdf

Very interesting. The device you're suggesting is very similar to the one I was considering:

http://www.onsemi.com/pub/Collateral/NLAS3158-D.PDF

 

So now I'm upgrading my learning and diving into the world of the PIC16LF18223, which is a device with (electrically speaking) similar characteristics to the PIC10LF322, but with a bit more capacity and bells and whistles ... I chose this device because I'm need to control a bi-directional solenoid, and the PC10 does not have enough I/O's to accomplish this and the other tasks I need it to do.

Compared to the PIC10, the PIC16 has I/O's aplenty. So I plan to use a pretty straightforward circuit and have four of its pins control each of the transistors (nFets and pFets) needed for an H-Bridge.

I've already successfully used a DMN1019USN nFet at the circuit's low side to control a solenoid in a single direction, driving it directly from one of the PIC10 pins.... no problem there. But now for the high side part of the H-Bridge, I plan to use the DMP2066LSN. Which has characteristics that seem appropriate for my circuit.

Now for the details. I'm running the MCU at 3.3V, whilst the main power supply consists of four batteries delivering 6V. And I need to activate the solenoid at those 6V for it to work the way I want it to. As I've already said, I had no problem switching it with a single low side nFet by applying 3.3V at its gate. But something tells me that switching the high side pFets might not be that simple.

Question, would it stress the PIC16's pins too much if I were to directly drive the gates using a circuit like this one?:

​

 

Not so much stress the pic pins, but maybe whether you will see the P mosfets turn off fully?
No practical experience with it, just thinking out loud!
Max.

 

Not so much stress the pic pins, but maybe whether you will see the P mosfets turn off fully?
No practical experience with it, just thinking out loud!
Max.

I don't mean to be cheap... but I have very limited PCB space, and I'd like to avoid placing extra components if I can.

On the other hand, I forgot to mention that I plan to switch them on by pulling their gates down, but switch them off by configuring the MCU's pins as high-z inputs. That way they should completely turn off...

My question remains ... would the MCU's pins (which would be working at 3.3V) withstand a 6V pull up through a 100k resistor? ... or maybe I could use an even higher resistor... say 470k?

 

Extremely low current at 100k.
Should be quite different using a Mosfet than a Bipolar for example.
Max.

 

If you are going to have turn-off pull-ups for the P-mosfets, why not turn-off pull-downs for the N-mosfets. Same logic for each. 100K seems a bit large to me; 10 K will give faster on/off and add no more stress. I would not worry about gate resistors to limit current, but if you have ringing, you may want to use a small (10 Ω to 100Ω or so) gate resistor on each. Ringing can delay the transition and lead to heating.

 

If you are going to have turn-off pull-ups for the P-mosfets, why not turn-off pull-downs for the N-mosfets. Same logic for each. 100K seems a bit large to me; 10 K will give faster on/off and add no more stress. I would not worry about gate resistors to limit current, but if you have ringing, you may want to use a small (10 Ω to 100Ω or so) gate resistor on each. Ringing can delay the transition and lead to heating.

There will definitely be pull down's at the nFet's gates, sorry for the omission. As for ringing and such, I don't consider that an issue, since I won't be applying PWM, and activation will be very sporadic (in the order of just one per several hours), and it would last for about 3/4 of a second.

I'm going to experiment with values between 10k and 100k as pull-ups/downs, see which is the highest I can use without affecting performance. Low current draw is critical in this application.

 

A dumb question. What's the need of using the banksel instruction at all? For example:

       banksel PORTC   ;initialize Port C
       clrf PORTC      ;clear all bits in Port C

Wouldn't "clrf PORTC" by itself work just as well? Or does the "banksel" instruction add a "location offset" necessary for the clrf instruction, which maybe has a "two bytes location" limit when working with memory banks?

 

It all depends on what memory Bank you are in for chips with more than one Bank. The PIC10LF322 only has one bank, so that is not necessary. (NB: It does not have a PortC, though.) Banksel is unnecessary/

With chips that have more than one memory bank, then it can make a huge difference. The include file sets PortA at a certain offset. TrisA has the same offset in a different bank. If you are in the Tris bank and write, clrf Port A, you will actually clear TrisA. At least that is what my Assembler does.

EDIT: To appreciate that, look at a chip like the 16F1829. In Bank0, "clrf PORTA" will clear that port register. In Bank1, the same instruction will clear TRISA, Bank2 will clear LATA, Bank3 will clear ANSELA, and Bank4 will clear WPUA.

 

It all depends on what memory Bank you are in for chips with more than one Bank. The PIC10LF322 only has one bank, so that is not necessary. (NB: It does not have a PortC, though.) Banksel is unnecessary/

With chips that have more than one memory bank, then it can make a huge difference. The include file sets PortA at a certain offset. TrisA has the same offset in a different bank. If you are in the Tris bank and write, clrf Port A, you will actually clear TrisA. At least tha is what my Assembler does.

EDIT: To appreciate that, look at a chip like the 16F1829. In Bank0, "clrf PORTA" will clear that port register. In Bank1, the same instruction will clear TRISA, Bank2 will clear LATA, Bank3 will clear ANSELA, and Bank4 will clear WPUA.

Thanks ... I figured that's what might happen ... I'm working with the PIC16LF1823, btw.

 

So, if I wanted to enable the general weak pull ups at its input pins, using the PIC16LF1823, I had better perform that instruction as follows, right?

       ;clear the NOT_WPUEN bit in OPTION_REG to enable the general weak pull-up feature at the pins
       banksel OPTION_REG
       bcf OPTION_REG, NOT_WPUEN

 

I use the instruction movlb 1 to get Bank1 rather than banksel TRISC. They do the same thing, but I like keeping track of what bank I am in.

EDIT: Yes, that should work, if the Assembler recognizes "NOT_WPUEN" as a pin label. It should. If not, you will get an error that is easily fixed. (I honestly don't know what character it uses.) !WPUEN also means negate, but I suspect the Assembler will also recognize simply "WPUEN" as the bit label.

 

The datasheet states that:

"A write operation to the LATx register has the same affect as a write to the corresponding PORTx register."

Does that mean that the first two lines of the following instructions are unnecessary?

       banksel PORTA      ;initialize Port A
       clrf PORTA
     
       banksel LATA       ;Data Latch, set output pins as low, input pins as high
       movlw b'00111011'  ;RA5 and Ra4 are inputs, RA3 is always an input, RA2 is an output, RA1 and RA0 are inputs
       movwf LATA

NOTE: I hate it when people confuse the word "affect" with the word "effect" ...

 

The datasheet states that:

"A write operation to the LATx register has the same affect as a write to the corresponding PORTx register."

Does that mean that the first two lines of the following instructions are unnecessary?

I am not certain of that answer.

Port latches (LATx registers) were implemented to avoid the Read-Modify-Write (RMW) error that writing to ports was susceptible to in the earlier chips. As a general rule when LATx registers are available, one should "write to a LATx and read a PORTx." That translates to writing an output to a LATx and reading an input on the PORTx.

That is the safest thing to do; however, the LATx registers are in a different bank than the PORTx registers and switching banks takes 2 steps (switch to and then switch back). You can still write to a PORTx and in simulation, it will show the LATx changing. But that may still be susceptible to RMW error. You can also use instructions that are not susceptible to RMW, such as movwf PORTx. The classic RMW instructions that cause problems are bit instructions, such as bsf, bcf, incf, etc.

RMW error occurs when a pin on a port is changing during the read portion of the instruction. So, if it is going low to high and is read while it is low, when the port is then written after the captured register is modified, it will be written as low. Pins driving high capacitance loads can cause that. The TRIS register is also susceptible to RMW. @JohnInTX has written extensively on the subject. High-speed serial communications, like I2C, that change a pin's direction can cause such problems.

EDIT: Before JohninTX mentions it, "movf PORTx ,w" then modify, then write (movwf) doesn't solve the problem as the first instruction could read during a change. Experts will keep a shadow register of what the outputs are supposed to be, modify that, then movwf. In essence, they are using homemade latch registers. Others just write to the ports judiciously and suffer the consequences, if any.