Welcome, Guest
Username: Password: Secret Key Remember me

TOPIC: Hacking my new SafePet Rotating Litter Box for Cats

Hacking my new SafePet Rotating Litter Box for Cats 2 months 3 days ago #18085

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
WHAT COMES FIRST? THE CHICKEN OR THE EGG?

Idiom or metaphor, it certainly describes where I am with system control. Is it the ESP8266 that makes the STM32F103? Or the other way around? After all, the STM32F103 is a slave to the ESP8266, but then the STM32 does all the work. Yeah, sounds more like the workplace to me. The ESP8266 is the MANAGER, and the STM32 reports to it, and does all the heavy lifting. But then the ESP8266, at least in this stage of my embedded system's development, is more like an operator that handles communication for the STM32. All this helps me put the system into perspective though.

Eventually, the ESP8266, with its vast memory and processing power, should handle managing the project, with one or more slaves to do the heavy lifting. As it manages this group of tasks to the projects core purpose, it has to answer to the hive, or BOSS, that will tell it what to tweak, change, and ultimately do. When the BOSS is away, the ESP is responsible for autonomously managing it's workers to keep the project functioning to it's core purpose. And if the MANAGER (ESP) has to step out for a bit, the workers (STM32) have to function autonomously to handle their tasks without direction. Hmm. I LIKE IT!

Man, developing a standard in this area is like creating an ecosystem. It's nice to visualize the system's hierarchy.
Last Edit: 2 months 3 days ago by hop. Reason: typos

Hacking my new SafePet Rotating Litter Box for Cats 2 months 3 days ago #18086

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
When I get my sub-systems priorities straight, and this project completed, it is definitely time to test the system's hierarchy by connecting the ESP8266 to a group of STM32F103 boards. With three serial ports other than the one tied to USB or STLINK interface, it should be easy to daisy-chain the communications without fancy rigging. Of course, all this can be done with a can bus or I2C, but coding is simpler with serial. At least for this exercise. And I will have serial buffering between the workers (STM32 devices).

This will allow me to tweak the command interpreter to recognize addressed sub-systems before deploying this in all my projects.

Hacking my new SafePet Rotating Litter Box for Cats 2 months 2 days ago #18087

  • Jon Chandler
  • Jon Chandler's Avatar
  • Offline
  • Moderator
  • Posts: 360
  • Thanks received: 350
So many moving parts! Maybe block diagram would help to show everything? I know posting pictures here is a pain so I'll be happy to get it posted if you send me something. Doesn't need to be fancy.

I laid out a circuit board for a friend in Nicaragua to build a sort of data logger out of ebay modules - GPS, cell modem, IN219A to measure voltage and current...all controlled by an ESP8266 NodeMCU board. That is a powerful beasty - his code has grown quite complex!

I had a bit of a revalation when I built the boards. My initial thoughts were that it was kind of silly to solder modules to a circuit board - why not just put all the parts directly on the circuit board. But there are 2 reasons it makes sense:

1. The cost of a module is less thsn you csn buy the loose parts for, and you get a decently-designed workong corcuit.

2. He can duplicate the design with basic soldering skills, mostly soldering 0.1" headers to the board.

Makes good sense to me now.. Sadly, I think the latest batch of boards os waiting in Miami - Nicaragua is torn by a violent civil war right now.

Forgive the typos....it's 4am and I have allergy eyes.

Hacking my new SafePet Rotating Litter Box for Cats 2 months 52 minutes ago #18088

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
I forgive your eyes Jon, and you pretty much summed up why I use modules mostly instead of reinventing the wheel. And like you, I went on a parts search back a year or two ago when I wanted to build my own boards with all these subsystems on them. Fact is, the parts were MUCH more expensive, and the whole project even higher, MUCH higher than I expected. Of course these costs were at the prototyping quantity level, and not mass runs with reels of components, and thousands of boards being spit out.

So a few years ago I started switching over to the "module" and "breakout" format, instead of trying to breadboard all this new technology. And it has worked very well for me. If I run into a limitation... like say using the ESP8266-01 module where you have very little external access to the SOC, then it is time to either upgrade the module I am prototyping with, or build my own. With prices the way they are now though, building my own at the prototype level has thankfully not been necessary.

And I can run jumpers between pins of the modules. I find myself more worried about securing the modules so they don't move around, than the layout on a breadboard. As a matter of fact, some of my neatest creations do not use a breadboard at all at the prototyping level.
Last Edit: 2 months 50 minutes ago by hop. Reason: typos

Hacking my new SafePet Rotating Litter Box for Cats 2 months 38 minutes ago #18089

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
I ran into a dilemma, but it is not a deal breaker. I ran into an issue where I am using the same serial channel, with multiple systems adding (and listening) to that same channel. I did not want to tackle this just yet, and was actually hoping it could be something for a revision later, but I believe it is time to take the serial communications and bundle them with some sort of protocol. Yes, complete with addressing, CRC, etc. Why?

Because when I type manual stuff in my telnet terminal, and expect the STM32 to respond, that is all well and good. But when the ESP8266 wants to talk to and respond to the STM32 using the same connection, the STM32 has no way of knowing the origin of the data. With a packet-like protocol, simple too believe me, I will be able to differentiate between the sources of the data that is being received, at various levels of the subsystem. With a simple protocol supported by a brief timeout, I can send commands and responses between the ESP8266 and the STM32 without interfering with the manual stuff I do via telnet. All on the same serial stream. I will add CRC but the system seems so stable, there seems very little chance for error. But there is always that stray byte, influenced by a stray power surge or swell of EMI.

Of course, ALL this is simple and much faster and powerful using I2C. I just could not get it to work with existing libraries. Perhaps I will write my own. The hardware EVERYWHERE seems to support it. Maybe even 1-wire.

But that is the BANE of my developer's existence. My projects do not need that speed of data handshaking. At least not yet. KISS! Keep It Simple Stupid works for me, and right now, Serial ports are the way to go.

So a somewhat MAJOR revision of my communications and command processing functions is underway. I can see it in my mind, so now I am going to work coding it. More when it's in place.

Thanks for listening!

Hacking my new SafePet Rotating Litter Box for Cats 2 months 18 minutes ago #18090

  • Jon Chandler
  • Jon Chandler's Avatar
  • Offline
  • Moderator
  • Posts: 360
  • Thanks received: 350
Could you use something like a /busy line? Normally pulled high, when a device wants to talk, it checks that the /busy line is high, pulls it low and sends its message. Anyone else wanting to talk will find the line low, and will wait to send until after it's released by the first device.
Time to create page: 0.251 seconds