Tools for embedded electronics (pt. 2) | VIDEO 39

[@Netryon]

These drawers have everything may need usually for thermals, CD ROM power supply. Parts obviously includes harvesting metals which is free salvageable 9:20. Hope you remember this anti static GPU packaging you received few years ago. 6:55 may you find best guitar picks for you.

[@leosedf]

If you want some serious flux get Warton metals HF rework jelly. One of the best (even amtech) I use it on bga 's since 2002. The piergiacomi cutters are also some of the best for electronics.

I'll check it out at my next resupply :)

[@leosedf]

@ love your videos btw

[@samuele5931]

What do you think about getting a portable soldering iron like the Pinecil instead of a soldering station? Do I need ESD safe? Also for desoldering pump you should checkout engineer tools. They have silicone tip and it should be replaceable

If you don't do much soldering than a good portable soldering iron is a good buy. Do go for modern ones with usb-c and barrel for good power delivery and a integrated tip and geater cartrige style system. I don't have any specific recommendations but that's what I would look for. Also check out various youtubers that do these kind of reviews.

[@guruG509]

Does the HAL provided by ST and CubeMX code generator used in professional world? or do they use gnu tools, or both are used in industry?

tldr: Yes, but a thorough inspection into initialization part is important. Well HAL is just a library along with system information about peripherals and their options. What CubeMX does it speeds up prototyping and testing and trubleshooting which comes in handy. This removes all the guesswork and time spent just initializing peripherals to your needs. HAL as in itself is very usefull because it provides a more abstracted and easier to use layer with the hardware and you don't need to write, test and verify your own which would take a long time. Yes, it does have its fair share of quirks, but for the most part it's good. After most of the testing and prototyping is done, we take a closer look into generated initialization code. Not so much all the structs and setup functions, but some critical sections, like where are interrupts for peripherals enabled, do we want them enabled in the init section? How about some peripherals, do we want to call the init function by ourselves? A good example is RTC peripheral with Wakeup timer interrupt. If you have it enabled and you use it for some data collection for time accuracy, it keeps on running even when the device is disabled, if you have a RTC battery. What can happen is that when the device powers on, before any initialization of system clock, other peripherals and even your code, that interrupt can and WILL trigger right when you enter main. Any code in that interrupt that works with peripherals or any uninitialized data will break and cause problems. Also, HAL initialises RTC time and date at every start to a default value set in CubeMX (i don't like it, I would like to see an option to disable this). If you don't want to get your time run over at power on, then you need to manualy remove that piece of code in the RTC init and remember to do so after every CubeMX generate run. Git really helps as you can just revert that part back. Once we finish intialization also on our code, all the structures are ready, we can manualy call init function for that peripherals and first interrupt that happens is going to work with initialized data, structures and peripherals. CubeMX offers an option to disable a init call for a peripheral, so that you don't have to delete it after every generate.