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 1 month 2 weeks ago #18111

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
Project Goals and a Clarification - It's a Rube Goldberg Machine!!

For those that are reading this posting thread, one would not be out of line with the assumption that all this programming, features, and considerations would certainly not be necessary for a simple task of controlling a motorized cat litter self-cleaning box. That assumption would be correct!

It was a need for a level of control over my under-designed litter box device that brought on this project. And because I plan to use this framework on ALL my projects, to be able to add a features via software to what that level of control has, that has made this much bigger than the task at hand.

But yeah... it really is like a Rube Goldberg machine that simply turns the cat box on and off at the end. But I will have a frame work that I can throw at any idea I have, set a few configuration settings, and have it online faster than I can connect hardware to it.

I wanted to set that straight. It may seem like I drift, but the end result is this project's needs solved, and probably all my others.

Hacking my new SafePet Rotating Litter Box for Cats 1 month 2 weeks ago #18112

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
ISSUE - System Message Packet system works great on the sub systems, on the blue pills based on the STM32F103C8. But it is a bit more complicated on the ESP8266 which is why I might seriously entertain the idea of replacing the ESP8266 in this adventure with a ESP32. The cost will only add a few bucks, and the timer features seem a bit more vast. I do not have a comparison yet, still researching.

The ESP8266 has two timers, that's it. One of those is strictly used for the wifi features and we really do not want to mess with that. The other, Timer1 has capabilities, but there is not much support unless you use the "ticker" library. I want something more hardware-based, more bare-metal.

Accurate and precise timers with interrupt generation and support for interrupt handling is a key issue with me. With the systems I write, it is important to have some very precise timing happening in the background that does not interfere with the peripherals. This is why I do not readily embrace bit banging any protocol, although sometimes that is necessary. My system message packet (SMP) system looks for a character value that would not easily be entered by a human, and then switches to a mode of reception expecting a machine to send the rest. A timer, and interrupt handling, along with volatile declared global variables are used to handle indexing of the data received, setting (or resetting) of flags, buffer transfers, are used. Any delays in this scheme can cause SMP messages to fail. And while I am multitasking the serial ports for communications, this is a necessity for the systems to be able to communicate with each other. At least until I figure out CAN, or I2C SLAVE on the sub systems, mainly the STM32F103C8's.

Anyway, this is why I am considering the switch to the ESP32 as the managing system in this project. I might have effectively out-grown my Wemos D1 Mini Pro boards.

This is why we prototype! :)

Anyway, next on the agenda is seeing if I can get the same SMP support code to work on the ESP8266. If it proves unstable though, I'm making the change, starting tomorrow. I have a bunch of ESP32's around anyway.

Hacking my new SafePet Rotating Litter Box for Cats 1 month 1 week ago #18113

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
Well I was able to implement interrupts on the ESP8266, and it is also reading the SMP packets, so all seems to be well! Looking at the code, there is a lot of work to be done cleaning it up. I will go after that the next couple of days, then start the code to route the SMP's to MQTT messages. YAY! Finally, OMG!

Hacking my new SafePet Rotating Litter Box for Cats 1 month 1 week ago #18114

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
UPDATE:

As I add commands and messages to the managing MPU and sub-systems, it became clear that I needed to write a tool to control this. So I can keep track of what a project has for topics, commands, etc. This tool will eventually feed a database where the command structure can be accessed and reloaded into a project as part of their firmware upgrades. Right now, the commands and messages are statically coded. But the next step after I get this running will be to make this more dynamic. There is no reason to delay THIS project any further by reinventing the wheel so-to-speak every 15 minutes. lol

Pretty cool idea though, using snippets of code and modules to be loaded into a project based on need. It is also great for project planning, like my todo list for today.

Hacking my new SafePet Rotating Litter Box for Cats 1 month 1 week ago #18115

  • hop
  • hop's Avatar
  • Offline
  • Platinum Boarder
  • Posts: 487
  • Thanks received: 46
UPDATE:
After changing the way the ESP8266 reads serial output from a sub-system and relays it to the telnet connection, I noticed a major slowdown with the characters being displayed, and some of the text was missing. It made me wonder how fast the telnet connection is. Looking over the code, I did not notice anything that allowed a speed to be set, so I figured it would just come through as fast as the wifi connection and supporting hardware would allow. It seemed more like 300 BAUD from the old days however. Apparently, the data needs to be sent in buffered blocks, and after reading about the reason, it makes total sense.

Since this is internet connectivity, even though it is in-house on a wireless LAN network, each piece of data is wrapped in a packet if sent individually. This would explain why prints to the telnet connection directly from the ESP8266 come through very quickly. But sending each character one at a time wraps each character in a packet, and that whole process apparently takes enough time and MPU work to slow it down enough to see the difference.

As far as SMP's, System Message Packets, this should not be an issue at all. But the human interface will need a bit of tweaking. Since the checking for a SMP start byte is performed on each received character, and not as it is sending it out, it would be viable to loop through each available serial character to perform the test, place it in a buffer, then send it all when it catches up. Should be simple enough to implement.

Human TELNET interaction is temporary (maybe) so this is not a giant set back. Automation interaction with the project will involve SMP's exclusively so I am not too concerned. Once that is in place, timing testing can begin so I know the absolute limits.

Hopefully, that data and results will be in the next post. More when I code it. :)
Time to create page: 0.239 seconds