arduino - Controlling NMOS gate switch with PMOS

The goal of the circuit below is to use a PMOS to turn an NMOS on and off which will blink the LED. A microcontroller is providing the square signal. Both MOSFETs are logic level and when I use them individually with the LED the behavior is what I expect. However in the circuit below when I send 5V to the gate of the PMOS the LED will just remain ON, but I expect it to turn off. Is it incorrect to wire the drain of a PMOS to the gate of an NMOS?

Answer

You need a drain resistor on the gate of M1. And by drain, I mean from the gate to ground.

The gate has a capacitance that needs to be drained off or the channel will remain open. Select a resistor size that will drain that in the order of magnitude of time that is reasonable for your application.

Is it possible to get a high efficiency buck-boost converter by switching between the two?

Many buck-boost converters work by boosting to an intermediate voltage, then bucking to the desired voltage. What if instead, it had a separate buck and boost section in parallel, and switched between the two based on input voltage and desired output voltage.

For example, if the converter is set to 15 volts, and it's being supplied with 12 volts, the buck side would be disabled and the boost side would be boosting the 12 volts to 15 volts. Likewise, if you set it for 5 volts, the boost side would be disabled, and the buck side would drop the voltage to 5 volts.

Could this lead to high efficiency buck-boost converters?

mbed - I2C Scanner not working properly

First of all, please see my other question HERE as it is related (Any help with that is greatly appreciated too).

If you read through my other question, you will know that I am attempting to interface with a magnetic sensor IC, the MLX90393, on the Sparkfun Breakout Board.

I have been having trouble reading the data from it, and I am confident the issue is in the code, not any of the hardware. The reason for this, is when I use the ARDUINO EXAMPLE CODE on GitHub, with the Arduino IDE (still using the STM32 Nucleo hardware), everything works and I can read the data from the sensor. However, when I attempted to convert that code over to mbed, I just get an error, and I am unable to extract the data.

I have now decided to see what would happen when trying to do a scan to find the address. Previoulsy, when doing an I2C scan in the mbed IDE, I got an ACK from every single address. The code I used was HERE. When running this code, this is the response I got:

Please note I added an additional \n after "I2C device found at...." so that it didn't scroll across the screen. Please note I have tried it with Error ==0 and 1. When I use Error ==0 for mbed, I get 'No devices found'

This is almost an exact copy of the Arduino I2C scanner, which can be found HERE. Looking through the 2 of them, they are basically exactly the same, and I cannot find the difference between them (bear in mind this is my first time working with I2C). When I run this code on the same hardware but via the Arduino IDE, this is what I get:

Does anyone have any idea why this is happening? What is the difference between doing this with the Arduino IDE and the mbed? I hope solving this issue may assist in solving the issue with my other question, but this is really getting frustrating. I have tried changing I2C pullups to different values and that had no effect either.

Answer

Working with the OP, this problem has been solved.

Short version:

• De-solder STM32F303K8 Nucleo-32 (NUCLEO-F303K8) board solder bridges SB16 and SB18 when using Mbed I2C functions.


• Use the "extended" 4-parameter Mbed i2c.write() call with the STM32F303K8 Nucleo-32 board.

Long version:

As I mentioned in comments (agreeing with Chris Knudsen), we needed to look at the signals. From my own experiences over the years, it can sometimes be important to start with a 'scope, since that can show important details about the shape and voltage levels of the signal waveforms, which cannot be seen with a logic analyser. Then after the analog waveforms have been verified, move on to using a logic analyser.

Using Arduino IDE and libraries for the STM32F303K8 Nucleo board, and running the I2C scanner just for I2C address 0x1 (which didn't exist on the bus), we saw this image of valid I2C activity (yellow = SDA, blue = SCL):

However running an equivalent I2C scanner for Mbed, configured for the STM32F303K8 Nucleo board, we saw this on the I2C bus:

This shows SDA stuck at approximately 2V, which is invalid i.e. not within the allowed range for logic 0 (typically < 0.2 Vdd) or logic 1 (typically > 0.8 Vdd). This is a classic symptom of two output pins driving the same signal in opposite directions.

Looking at the STM32F303K8 Nucleo user guide (UM1956) we see that it actually connects the SCL and SDA pins to other pins, for some kind of compatibility with Arduino Nano analog input functionality.

(Above edited from Table 8 in STM32F303K8 Nucleo user guide (UM1956))

(Above schematic extract from page 33 in STM32F303K8 Nucleo user guide (UM1956))

That means that if the Mbed initialisation code didn't configure pins PA5 and PA6 as inputs without any pull-up/down resistors, then through those solder bridges, pins PA5 and PA6 could affect the I2C signals using pins PB6 and PB7.

De-soldering those two solder bridges allowed I2C signals to be correctly seen, with the Mbed I2C scanner code:

During research, we found this posting about using the STM32F303K8 Nucleo-32 (NUCLEO-F303K8) board with Mbed, which said:

It looks like this device does not support the i2c.write(int data) method. i2c.write(int address, const char *data, int length); works.

Changing from the original Mbed I2C scanner (adapted from the standard Arduino I2C scanner) which used the sequence:

i2c.start();
error = i2c.write(address << 1);
i2c.stop();

to a different Mbed I2C scanner using this different version of the i2c.write() function call instead:

returnCode = i2c.write((address << 1),&outByte,1,0);

then this different Mbed I2C scanner worked correctly.

This would be an area for deeper investigation of the Mbed source code and detailed I2C behaviour using a logic analyser, however we ran out of time. By documenting the process so far and what was found to work, I hope this is useful as a starting point for anyone else who wants to take the investigation further.

modulation - RC time constant and diode detector

For a better detection of the modulated signal with the diode detector below, one requirement is that the time constant of the RC filter conforms to:

$$ \frac{1}{\omega_{c}} \leq RC \leq \frac{ \sqrt{1-\mu^{2}}}{\omega_{m}\mu} $$

where:

• \$\omega_c\$ is the angular frequency of the carrier


• \$\omega_m\$ is the angular frequency of the information, and


• \$\mu\$ is the modulation index.

How exactly can we prove that?

Answer

The formula is derived from practical experiences and not from mathematical 1st principles. It is unprovable other than by being practical and thinking what a diode detector has to achieve.

Firstly, the formula states that RC has to be equal to or greater than \$\dfrac{1}{\omega_c}\$.

If the RC time constant were too short there would be significant levels (ripple) of the carrier frequency on the output - this is not what is wanted from a diode detector (or an AC rectifier in a power supply) BUT, it's never going to be a perfect brick wall filter and so carrier ripple has to be acceptable (to some degree).

Personally, I would like to see the RC time constant 5 times greater than \$\dfrac{1}{\omega_c}\$

At the other end of the scale, RC cannot be too big or it will start to significantly attenuate high frequencies in the "detected" analogue waveform that is represented by \$\dfrac{1}{\omega_m}\$.

Here is a picture that hopefully explains: -

This picture was taken from here and basically is saying, if the modulation index is too high for the value of RC chosen there will come a point in the detection of the signal that the RC time constant is too long.

You should also note that as the modulation index approaches 1, the RC time constant has to theoretically be very small and this will make it likely clash with the requirement for it to be significantly greater than \$\dfrac{1}{\omega_c}\$.

resistors - Finding an unknown resistance with superposition

I've been given a problem in which I need to calculate the resistance of an unknown resister \$R_2\$ by using the superposition method. The only other info which I have is that \$R_2\$ needs to be such so that \$I_1=I_2\$ and \$I_3=20\text{ mA}\$.

I hope the image is readable:

I've set up the three superpositon cases, but at the start of trying to calculate the solution I realised that I had no idea how to proceed with an unkown resistor.

A sort of idea I had was to solve for \$R_2\$ in the first two cases, but then I don't know what to do with the third case.

Answer

With superposition just write three components of I1 (say I1.1(R2), I1.2(R2) and I1.3(R2) ) each with one single source activated.

Each expression will be function of unknown R2. Then you sum them up and finally solve this to be 10mA.

I2 will automatically be 10mA too for a simple KCL at center node.

Alternatively Ohm's law would solve this right away:

Given I1=10mA Ux at center node will be \$U_\text{x}=U_1-R_1I_1=6.53\,\text{V}-458\,\Omega\times10\,\text{mA}=1.95\,\text{V}\$

On the other hand $$I_2=\frac{U_2-U_\text{x}}{R_2+R_\text{i}} \quad\Rightarrow\quad R_2=\frac{U_2-U_\text{x}}{I_2}-R_\text{i}=\frac{8.5\,\text{V}-1.95\,\text{V}}{10\,\text{mA}}-0.4\,\Omega\approx 655\,\Omega$$

switches - Mosfet suggession for large drain current Sample Hold application

I'm using a MOSFET for a sample and hold circuit controlled by a microcontroller. I want to control the charging and discharging of a capacitor by a solar cell. For this I'd be using two MOSFETs. The solar cell can have a large area and can source upto 3.2 A of current. This flows through the drain of the MOSFET. I want this flow to be switched ON and OFF by applying a gate voltage from an MCU. I can boost the MCU output to required gate voltage levels, but what would be a suitable MOSFEET for my application? I'd need approximately 250 ms ON time and 750 ms off time during switching. The IC (or transistor) package may be any one of the packages that may be connected to a breadboard easily that is NOT surface mount.

EDIT: Strictly speaking, the purpose isn't sample and hold but its very similar. I'd like to characterize the solar cell IV by sampling the voltage across the cap and the current flowing to it while charging.

Schematic here.

Answer

While a schematic of the application, and the solar panel voltage, would make it simpler to provide a definitive answer, here is how one could select a suitable MOSFET:

• MOSFET should (ideally) switch on hard at the MCU's GPIO output voltage. Let's say 3.3 Volts, so we are looking for a logic level MOSFET, one designed for 3.3 Volt operation. The Gate-Source threshold voltage V_GS(th) for such MOSFETs would typically be below 1 Volt.


• MOSFET Drain-Source voltage rating should be significantly higher than the expected voltages in the application. If the solar panel in question operates at say 10 Volts maximum, I would look for a MOSFET rated for V_DS of 20 Volts, fairly common.


• MOSFET drain current rating should be significantly higher than the expected drain current. For 3.2 Amperes, I would limit my search to MOSFETs rated to 5 Amperes or higher


• The power dissipation at the MOSFET during full conduction needs to be dealt with, either via heat sinks, other forms of cooling, or simply by keeping the power dissipation well below the rating for the MOSFET package without heat-sink. Since through-hole was specified, the common MOSFET package of TO-220 would typically be quite safe at 0.5 Watt dissipation, and would run hot but probably not too badly at 1 Watt, without a heat sink. To achieve this, one would look for a MOSFET with on resistance R_DS(on) of under 49 milliOhms (501 mW) or at worst, 100 milliOhms. A heat sink allows far greater latitude, of course.


• Given the rather relaxed timing requirements, switching losses are not much of a concern, nor is switching speed or gate capacitance, really.

So, given the above parameters, a search on Digikey yields at least 79 results as I just checked. On sorting by lowest price for single unit purchases, a couple of options are:

Of course, if SMD were an option, many, and less expensive, options would open up, including some excellent devices by Alpha Omega and International Rectifier.

---

As pointed out by Russell, if providing a gate drive voltage higher than the MCU power rail is not a problem, and a P-channel MOSFET is preferred, then a similar Digikey MOSFET search yields several P-channel MOSFETs that meet the specifications above, setting aside the V_GS(th) point. For instance:

microcontroller - Which of these approaches for a watchdog timer?

I recently learned about watchdog timers, and am trying to implement one for my circuit for the purpose of resetting my (AVR) microcontroller if it hangs (i.e., doesn't respond to the watchdog).

Based on some research, it appears to me that there are around four options:

1. Connect my microcontroller with an external dedicated watchdog-timer-specific IC.


2. Connect my microcontroller with an additional microcontroller (some very basic, inexpensive one), the latter coded for the sole dedicated purpose of watchdog-timing.


3. Lay out my own 555-timer-based watchdog circuit and connect it to my microcontroller.


4. Use the internal watchdog timer capability on my microcontroller.

.

Which of the above approaches would you rank higher and why?

I would like to set a watchdog time of around 6 seconds, based on certain criteria for the way I'm making the rest of my design and code (the device will be a battery-powered, periodic temperature logger).

A little note: My preference would be Option 1, for simplicity, however, based on the couple I have found, these parts either appear to be expensive (I'd like a solution under 1.25 USD at most), or only allow only less than 2 seconds for the watchdog timing period.

Answer

1. More expensive, as you already found out. But it should give you the highest level of reliability: because the watchdog is completely independent of the microcontroller it will still keep running, and reset the microcontroller when the latter is on fire, so to say. See 4)


2. Brian is against it, but there are cheap microcontrollers in a small package, like the PIC10F200 in SOT-23, which you can use as a retriggerable MMV (monostable multivibrator), which the watchdog actually is. If you would consider a 555, a 10F200 is better: no external parts, and more accurate timing (1% accuracy).


3. a 555? Seriously?



4. The internal watchdog will do if the dedicated IC is too expensive. If you're really paranoid you can think of a scenario where some hardware error will lock up the microcontroller and the watchdog with it. I've never known this happen, but I don't know how well you sleep.

Like pjc50 says 6 seconds is a long time. A typical microcontroller will execute tens of millions of instructions in that time, and then a lot can go wrong. Suppose you're controlling some load with PWM, and a low 10 % duty cycle keeps the dissipation low. Microcontroller goes bananas and the output gets stuck at a high level, 100 % duty cycle. The load doesn't like it, and dies. You don't want to wait 6 seconds for that to happen. There should be some part of your code where you pass much more frequenct. A main loop may be as short as 10 ms, then you could set the watchdog's timeout at 100 ms, for instance. If you kick the dog once every 10 ms, then a timeout means that you missed it 10 times! Once, OK, but ten times is disaster, and you have to take action. The load will be switched off after 100 ms instead of 6 seconds, which may be the difference between dead or alive.