วีดีโอ

You are most welcome, if you need more personalized tutorial on power system topics, you can either become a Patreon for CMTEQ Channel or Join my channel membership, that way I will send you personalized turtorial directly. 👉 th-cam.com/users/c@CMTEQ/join 👉 www.patreon.com/c/cmteq/membership

Obvioulsy it would not work in a normal use case where you have Master and slave separated. The loopback test typically doesn't involve an external slave device, so there is no need to control the SS pin. In a SPI loopback test, the MOSI (Master Out Slave In) pin is connected to the MISO (Master In Slave Out) pin via the jumper red wire @5:10. Since the same device acts as both transmitter and receiver, the SS (Slave Select) line does not need to be explicitly driven low or high.

Hi, yes you are correct, that is because @ minutes 3:35, I forgot to change my Data Size from 4 bits to 8 bits to match the buffer size. If you change it to 8 bits the Rx buffer will be able to store all data from the Tx buffer.

Hi, Thank you for your comment, check @ minutes 6:34, the main program can be interrupted by the SPI Callback function which is triggered after the DMA transfer is completed.

@@CMTEQ I am talking about DMA interrupts. On 5:01 however you explicitly disable the SPI interrupt and still HAL_SPI_TxCpltCallback gets called, so maybe some explanation might be useful. I looked into HAL implementation and got some information: " (++) No-Blocking mode: The communication is performed using Interrupts or DMA, These APIs return the HAL status. The end of the data processing will be indicated through the dedicated SPI IRQ when using Interrupt mode or the DMA IRQ when using DMA mode. The HAL_SPI_TxCpltCallback(), HAL_SPI_RxCpltCallback() and HAL_SPI_TxRxCpltCallback() user callbacks will be executed respectively at the end of the transmit or Receive process The HAL_SPI_ErrorCallback()user callback will be executed when a communication error is detected " If I understand correctly the callback gets called via DMA IRQ so that interrupt must be enabled and that is the reason why it works even with SPI interrupt disabled. Also if the DMA transfer is complete that does not mean that the SPI transfer is complete so it very well may be possible that still some polling is done under water and it seems a good idea to enable SPI interrupt to avoid this.

@@CMTEQ Well I am talking about DMA interrupts. At 5:01 you disable SPI interrupt and still HAL_SPI_TxCpltCallback gets called. I would say that needs some explanation. From the HAL implementation I got: " (++) No-Blocking mode: The communication is performed using Interrupts or DMA, These APIs return the HAL status. The end of the data processing will be indicated through the dedicated SPI IRQ when using Interrupt mode or the DMA IRQ when using DMA mode. The HAL_SPI_TxCpltCallback(), HAL_SPI_RxCpltCallback() and HAL_SPI_TxRxCpltCallback() user callbacks will be executed respectively at the end of the transmit or Receive process The HAL_SPI_ErrorCallback()user callback will be executed when a communication error is detected " So it seems that DMA IRQ is the callback context which means this must be enabled and that is also the reason that is still works with a disabled SPI interrupt. But still it is not trivial because DMA Tfer complete does not means that SPI data is transferred so it may be very well possible that some form of polling is done in the implementation. So it still seems a good idea to have SPI interrupts enabled.

When a DMA transfer is initiated using the HAL_SPI_TransmitReceive_DMA(), the SPI peripheral and DMA controller handle the transfer in the background. Once the DMA completes the transfer (all data has been sent or received), the DMA controller generates a "Transfer Complete" interrupt. The HAL library's interrupt handler (HAL_DMA_IRQHandler) processes this interrupt and calls the appropriate SPI transfer completion callback function, notifying the main program.

Yes, in this mode you do not have to enable the spi interrupt, the DMA Controller does trigger the interrupt after transfer completion, and this interrupt then call the callback function.

I'm glad you found it useful and I appreciate the feedback. Stay tuned for more stm32 application driven tutorials.

Hi, Please check on the description box. There's a GiHub link to the SourceCode and the Proteus model.

Hi, thank you for watching, yes I will get to the renewable once I'm done covering the relevants topics of power system. Stay tuned. You can also join my Patreon sites if you want me to assist you with specifics tutorials asap.

You're very welcome, I'm passionate about sharing this knowledge.

This is a brilliant idea, myself I have been thinking of developing a similar tool for myself. I made something similar without a display, not very fancy, mostly just for RDS ON and Testing if it's defective. Let me know if you need some collaboration on this open-source project.

@@CMTEQ sounds great, since with a project like this, base functionality should be super simple to reach(ofcource I already figured out how I would do it before even searching online and then checked online to see if there where better, more easy, or already done methods.(as in how I would do it for my use)), but it are things later on which really benefit from more people and reach. as for a screen, I mostly only planned on adding that for a opensource version so people can make cheap standalone tools. originally for myself I planned to just use serial or simulated usb keyboard input to read the values. main function is essentially to just have a simple cheap tool which can be used to see if mosfets are real or likely to be fake. and when doing that already it becomes quite easy to also add some other functions the normal budged mosfet testers don't have. ofcource for many things there are good cheap tools already, but most of them are inaccurate surrounding Rds(on) and also obviously can't trace such graphs as often they are meant as handy multi purpose component testers and not speciffically for things like mosfets or transistors. so would be great to work together. also what did you make for doing such tests? as in that perhaps that method might be quite usable already. I shall also explain roughly what I planned to do now. I planned to base it primarily upon the ESP32-C3 or RP2040(pi pico), however using arduino code primarily to make it easy to use other boards instead. I selected those 2 boards primarily because both have 12bit(4096) ADC resolution and multiple ADC pins. the pi pico is faster with 500ksps where the esp32-c3 only reaches 100ksps, both should be plenty of fast enough however. the pi pico also is faster and has PIO which might be usable, next to that it is super popular thus many people would already have them. the esp32-C3 however has wifi and bluetooth in it, this allows to do things like wireless terminal or interface to the module which can be very nice. I planned to just use a powerresistor and measure the voltage drop on the resistor to calculate current (optional) and the voltage drop on the mosfet to calculate the Rds(on). the mosfet will be pulsed on for a while and measurements taken. for the temperature measurements a heat sensor can be screwed to the mosfet and temperatures measured and mapped like that. as for the pulses, if the ADC proves fast enough for the used mosfets reaction time then it is possible to take multiple measurements when turning it on, even though that might be harder as for most mosfets they will probably both be to slow for measuring that. as for screen and interface and such. all such things which aren't the bare functionality would be in a way so that they can be easily added modular. either as their own files or copied in the main code by the user, some basic functions can perhaps be added by default and just enabled or disabled with a variable. as for calling the methods in a loop to make it easy, it is probably most easy to give them tiers and already add sections for them using comments, either tiers to abstract it and allow more options, or just things like input, processing and output. for example a screen function would be called after the calculations, and those would be called after the measurements. measurements however should first enable the mosfet, then wait a very short time before measuring and turn it off after measuring. I didn't properly design it out or to far yet however, so this is just how I currently plan on doing it. it uses microcontrollers instead of dedicated or analog hardware because microcontrollers are cheap and do not require as much manual soldering often(as you can get full development boards). less different parts makes it more easy to make and less easy to accidentally make a mistake.

Thanks for sharing your detailed approach-sounds like you're setting up a solid foundation! For my part, I’ve prototyped a basic MOSFET tester on a breadboard. It uses a resistor network to turn the MOSFET on and measure RDS(ON). Nothing fancy yet, as I haven’t integrated a microcontroller into it. What you’re doing is fantastic! I’d recommend using the ESP32 over the Pi Pico for its additional features like WiFi and Bluetooth, which can open up possibilities for a wireless interface or remote logging. While the Pico is great for raw speed and its PIO capabilities, the ESP32’s flexibility might serve your project better in the long run, especially for sharing data or controlling the device remotely. Once you’ve got the basics working, it’ll be straightforward to add a user interface, whether it’s a screen or wireless control. Also, consider adding a dedicated ADC chip with 16-bit resolution to improve measurement precision when interfacing with the ESP32. That might be a valuable enhancement for ensuring accurate RDS(ON) measurements, especially if precision becomes a bottleneck with the onboard ADCs. Looking forward to hearing how it evolves!

@@CMTEQ yes a dedicated ADC would indeed be usefull for greatly increased resolution. but first it should be working for as simple and cheap as possible, so all can use it. adding modular dedicated ADC support should be easy and can be usefull. as for the microcontroller, I will be using general C++ with arduino(altered C++) code. with that it should work with any microcontroller which is aduino compatible. as for the test, it is quite similar to the basic resistor test but then instead of using a dedicated volt meter it uses the microprocessor and automatically does the calculations and could do some special methods. in my case, the soldering is the main issue right now, not the design, but soldering properly also a connector for the mosfet with low losses, I guess in the end I will just use one of those general connectors like on a arduino, as for soldering, while I can solder it is winter now and as I solder outside most often when I have time either someone else is working there or it is already dark outside. perhaps I should start on a breadboard as well, avoided that for now fearing it might overheat.

Thank you for picking it up, I will revisit it and double-check. It could just be that the test conditions were not fully met as per the datasheet.

@@CMTEQ yeah such test conditions can differ a lot. mostly since the datasheet mentions it being on from around 2 to 4 volts, so despite the Rds on being at 10v logic would assume they are either close or that there should be some some kind of linear like curve atleast(transistor) but for mosfets generally it turns on very rapidly from a certain point and then very slowly increase after that until the Rds point and then go down again. but different behaviour happens normally as well in some cases. just worth checking if it is real as there are many fakes these days(even though less famous chips are less often targeted). but next to that the chip doesn't have a Rds on to gate voltage graph. so might also be normal behaviour indeed. for that it is usefull to test that curve yourself since if that is normal then it means that it reacts very heavily to the gate voltage and that lowering it to 5v reduces the load it can handle by over 5 times.

Thank you for your Subscription, you just reminded me about Part 3, practical demonstration of this tutorial, I had it coming in the pipe line, I've just been too busy lately. Stay tuned, I will upload it in the coming week...

This is because the generator's impedance is inversely proportional to its power rating. Its just a power supply, so the higher the capacity the lower the internal resistance which means the higher the short circuit current. So, think of it as a battery with 1Ah rating and 0.2 ohm internal resistance, if you increase the Amp hour (Apparent Power) the internal resistance will decrease lets say to 0.1 ohm, resulting in a higher potential short circuit current.

It's always a pleasure to share.

Awesom, I'm glad you liked it.

Thank you for the feedback. It means a lot to me as well. Stay tuned.

You're very welcome! I'm glad it was helpful.

It's a pleasure, thank you.

Hi, you can fill up this google form with your details. forms.gle/rH2E6YwMzeVuiT3R9 Make sure you include your email address, or you can find my email on my TH-cam page about section, then you can send me an email. I also recommend you join my channel membership then I can upload short video explaining you specific topics.

Its always a pleasure to share, thank you watching.

Thank you, I'm delighted you found it helpful.

Thanks for the tutorial ideas. Stay tuned it's coming as soon as I get my hands on the dev kit.

That is correct, When ARR is set to a value N, the timer counts from 0 to N.

This is Proteus Labcenter simulation.

You are most welcome, thank you !

Thank you, I'm glad it was helpful. Stay tuned for more power systems tutorials!