Welcome, Guest
Username: Password: Secret Key Remember me

TOPIC: Pi Zero Wifi / STM32F103CBT6 Project Node Servers

Pi Zero Wifi / STM32F103CBT6 Project Node Servers 2 months 1 week ago #17977

  • Jon Chandler
  • Jon Chandler's Avatar
  • Offline
  • Moderator
  • Posts: 329
  • Thanks received: 340
Level shifting isn't difficult - one chip can handle several lines. That might be good to look into if you can't handle the reduced processor speed.

Bah humbug for 3.3 volt systems!
The following user(s) said Thank You: hop

Pi Zero Wifi / STM32F103CBT6 Project Node Servers 2 months 1 week ago #17981

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 427
  • Thanks received: 45
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 months 1 week ago #17982

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 427
  • Thanks received: 45
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 months 1 week ago by hop. Reason: Grammar, typo

Pi Zero Wifi / STM32F103CBT6 Project Node Servers 1 month 1 week ago #18001

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 427
  • Thanks received: 45
OK, stumbling on with I2C, I was curious as to why my implementation path did not mention addressing at all. Well, it's simple really, although it took me awhile to figure it out. The inter-connection I am making with my MCU boards is more about messaging, and not about reading and writing to registers. Although I might implement register addressing in the future, all I really care about right now is getting a fixed packet from one device to another addressed device, and back again.

Addressing works well when dealing with a sensor, or other I2C slave device. Certain registers control the slave's operation, and it makes sense to be able to write data directly to those registers to get the expected results.

But in my design, a fixed sized packet is sent instead. The slave MCU knows it has it and acts on it. Hopefully, it has a packet ready to be returned. This is an important step because there is not a lot of time to waste getting that data back to the host. SO... my slave code has taken a bit of a change in direction.

I am trying to keep the traffic to a minimum but also want to keep all the sub-systems up to date. SO, a good way to do that is to have a set packet, or maybe a small array of them, and have the slave system write to those buffers when data needs to be updated. The buffers are already populated with the latest data, and when the host wants that data, it's a simple matter of decoding the request, and sending that packet after a new packet arrives. SO (I'm saying that a lot, sorry), instead of decoding the request by the host and then preparing the data, then writing it to the buffer, and finally sending it, the data is already there. I just need to send back the appropriate buffer packet based on the request. One buffer can be system status, the next can be data from the connected daughter board, and a third could be calculated results, maybe a forth is directly written by the slave daughter board. This should keep the need for clock stretching to a minimum and be ready to send that data BEFORE the request comes through.

The packet itself can wrap the payload with identifiers as to what it relates to, if there is more to send, etc. The host can then decode that and act on it. Maybe even tell the host that there is a long string of packets related to a large data cache that needs to be read sequentially. Then the proper request can be made and the data can flow by request.

How fast at 400000k? I don't know. It's the frame work I'm working on. Maybe SPI is better suited for some applications. Baby steps, and we will see.

Thank you for your time!

Pi Zero Wifi / STM32F103CBT6 Project Node Servers 1 month 1 week ago #18003

  • jmessina
  • jmessina's Avatar
  • Offline
  • Senior Boarder
  • Posts: 44
  • Thanks received: 189
I actually prefer I2C to SPI when linking multiple uC's together. SPI seems like it would be better at first (and faster), but it can be surprisingly difficult to get master-slave comms reliable since there's no form of handshaking or protocol involved... if the slave can't keep up with the master you're screwed. It's also less forgiving hardware-wise since everything works on the clock edges.

Many I2C devices will operate faster than 400K. I routinely use 800K in my systems, especially when I have slave uC setups so I control how the slave device works.

The limiting factor is usually the pullups. If you use an active setup instead of just resistors things work much better. TI, Linear Tech, Maxim, NXP, On Semi all have them... search for "rise time accelerator".
The following user(s) said Thank You: hop, Jon Chandler

Pi Zero Wifi / STM32F103CBT6 Project Node Servers 1 month 1 week ago #18004

  • Jon Chandler
  • Jon Chandler's Avatar
  • Offline
  • Moderator
  • Posts: 329
  • Thanks received: 340
Hop is really pushing the limits and doing great stuff!

I don't know if this helps at all. In the old days, the company I worked at had a data collector with 4 independent boards, each with its own microcontroller. The data collector had four boards internally and could talk to another board externally. The protocol was a master/slave protocol, using UART serial data on one data line which was somewhat like I2C, pulled high when idle.

The 4 boards were:

C - control board

A - analog data acquistion board

F - FFT board

D - data storage board

The protocol started with 16 sync bytes so that each receiver could lock onto the signal (no clock).

Then
[Board sending the message][board receiving the message][ID of the measurement point][command][size of data block][data block][check sum]

A message might be [C][A][999][command to aquire data with certsin parameters]

Which means the comtrol board told the analog board to take measures for ID 999 with certain parameters.

When that data was aquired, a message would be sent back with the data attached.

The the C board would tell the F board to perform an FFT with certain parameters on the attwched data.

When the FFTs were done, they were attached to the message and sent back. In this case, the data message was ever expanding, but each board only acted on the part relevant to it. This was a useful protocol in thst new boards could be added and the control board was the only one ehi needed to know anything about it.

In thinking about this, I think each message included a command of who to hand off to next, rather thsn going to the control board between each step. The shadows of time :)

Forgive the typos. I'm doing this while half awake with gunked up eyeballs!
The following user(s) said Thank You: hop
Time to create page: 0.257 seconds