Almost everything I have is 3.3v now. I have to conform. I do have a ton of level shifting modules and devices though. I just find that I destroy fewer devices when I keep everything on a multi-system design the same voltage. I cooked a few 3.3vdc RTCC modules over a year's time interfacing them to a 5vdc PIC. The first one was failure on my part to RTFM. Then it was powering it by the wrong buss. Then it was not level shifting the data signal. They were samples but still made me feel sick. A lot of stuff is "5v tolerant" now though, on inputs and sometimes VCC. I even found that I have some 5vdc devices that are tolerant of 3.3vdc signal levels without level shifting needed. Some are designed that way, some just have tolerances that work that way.
I do not understand the switch to 3.3v from 5v but I am sure there is some logical reason for it, at the linear-analog level. My brain is designed to work in binary mode, not ohms law. I am slowly working on that though. Even if available time has prioritized that for me as "need to know only".
I have the books now though, and most of the test equipment to start experimenting and learning about analog, and I am sure my digital side will benefit from that knowledge. I just need to push my other work aside, even if it is just a few hours a week, to get that done. Then the only light bulbs exploding on my lab bench will be the ones metaphorically floating over my head. lol
Pi Zero Wifi / STM32F103CBT6 Project Node Servers
2 weeks 2 days ago #17982
I ran into a condition known as locked buss (HAL_I2C_ERROR_AF) for I2C communications. For my ARM systems, my bandaid solution was to detect that anomaly and reset the master I2C system via software. It works every time but it is crude and not the recovery code I was looking for. It will do for now though.
The condition arises when the master is sending an address, or expecting a reply when the slave system powers up and initializes in the middle of it. I am so close to using the protocol to move data around my 3 MCU system that the band aid fix will just have to do for now. I already chased my tail for over a week on this.
Now that the messaging is almost completed between my test master board (STM32F411RE-DISCO) and my slave board (STM32F103C8T6), it will be time to move the master role over to the RPI ZERO and controlling that message system via Debian Linux with Python. This will offer me a data portal to HTML interfaces and I am really excited about that. I will run the message system through the paces overnight though to make sure my data integrity and recovery code is adequate.
That's where I am now with this beast of a project. It is starting to feel like I need to design templates for cutting and drilling my case for the interactive gear and wrap this baby up. FINALLY! Then deploy it in an embedded project for support. This is SO EXCITING!
Last Edit: 2 weeks 2 days ago by hop. Reason: Grammar, typo