You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you keep the PB6 and PB7 pins of the MCU free from other signals, these could be used for I2C based peripherals.
A possible use case would be an on board memory that stores the number of components fed, date of feeder assembly or other permanently kept data. This could be read out with commands over the RS485 bus and get used for failure statistics, regular maintenance reminders and other QoL features.
Suggested Solution
Move the IO's on the MCU around to keep an I2C bus access available.
Add some footprints for a standard memory IC and pullups as an option to the design already (don't have to be populated).
Alternative solution would be to just use a software I2C driver for this, so you are not bound by the limits of the onchip I2C peripherals and assigned IO.
The text was updated successfully, but these errors were encountered:
I2C would be great for this. Alternatively, if there is available space in the firmware, the last few 1 kB pages of flash could be used for this as well as a free solution.
Thanks for the idea @Magpie-81! I think using the existing flash for this kind of logging might be a cleaner solution. We don't really have any extra space on the board to add an EEPROM for storage, and if we already have flash space open, I'd prefer to use that.
The lifetime data tracking could also be done by the host instead of being tracked by the feeder itself, however multiple hosts would have to consolidate data for a given feeder if it's used on many machines.
Version Number
1.0.1
Bugfix or Enhancement
Enhancement
Description
If you keep the PB6 and PB7 pins of the MCU free from other signals, these could be used for I2C based peripherals.
A possible use case would be an on board memory that stores the number of components fed, date of feeder assembly or other permanently kept data. This could be read out with commands over the RS485 bus and get used for failure statistics, regular maintenance reminders and other QoL features.
Suggested Solution
Move the IO's on the MCU around to keep an I2C bus access available.
Add some footprints for a standard memory IC and pullups as an option to the design already (don't have to be populated).
Alternative solution would be to just use a software I2C driver for this, so you are not bound by the limits of the onchip I2C peripherals and assigned IO.
The text was updated successfully, but these errors were encountered: