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
Is your feature request related to a problem? Please describe.
When MRL is running on the Raspberry Pi, it would be good if it auto started the Raspi service.
The runtime.getPlaformInfo() does return the word "raspberrypi" as the first few characters of the returned string.
The Raspi has the ability to scan the I2C bus
the Arduino does not yet have that ability.
Describe the solution you'd like
After the Rasperry pi has been detected, start the raspberry pi service for a first install default config.
Then scan the I2C bus.
Then attempt to identify known supported devices and start the appropriate services for those devices found.
Describe alternatives you've considered
Manually started the installed device services, but having is done auto-magically would make it easier for new first time users.
Additional context
Attached is a spread sheet of all the possible I2C addresses and what devices are on those addresses.
I have also attached a text document listing the device part numbers, the configurable addresses and what the devices are. I2C Bus Addresses.ods I2C Bus device list and bus addresses.txt
Some devices can be identified by being the only device type at the listed address such as the PCF8574 and the BNO055
Other devices may be able to be identified based on the read and/or write to different registers and getting valid results.
The SSD1306 OLED driver is located on I2C Addr 0x3C or 0x3D sending a read command will return the status of the SSD1306 display as on or off on the returned bit D6, then we can send a command to change the display state to off Read the command state and then send the command to turn the display on.
The command status should show the display state changing from off to on.
The command from off to on is a change in bit 0 when writing and the status change will be on bit 6.
A PCF8574 which could also occupy the same address will show a change on bit 0 only confirming the device type as either the SSD1306 or a PCF8574.
I will add more comments as I work out how to test between different devices sharing address space ranges.
Ray
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When MRL is running on the Raspberry Pi, it would be good if it auto started the Raspi service.
The runtime.getPlaformInfo() does return the word "raspberrypi" as the first few characters of the returned string.
The Raspi has the ability to scan the I2C bus
the Arduino does not yet have that ability.
Describe the solution you'd like
After the Rasperry pi has been detected, start the raspberry pi service for a first install default config.
Then scan the I2C bus.
Then attempt to identify known supported devices and start the appropriate services for those devices found.
Describe alternatives you've considered
Manually started the installed device services, but having is done auto-magically would make it easier for new first time users.
Additional context
Attached is a spread sheet of all the possible I2C addresses and what devices are on those addresses.
I have also attached a text document listing the device part numbers, the configurable addresses and what the devices are.
I2C Bus Addresses.ods
I2C Bus device list and bus addresses.txt
Some devices can be identified by being the only device type at the listed address such as the PCF8574 and the BNO055
Other devices may be able to be identified based on the read and/or write to different registers and getting valid results.
The SSD1306 OLED driver is located on I2C Addr 0x3C or 0x3D sending a read command will return the status of the SSD1306 display as on or off on the returned bit D6, then we can send a command to change the display state to off Read the command state and then send the command to turn the display on.
The command status should show the display state changing from off to on.
The command from off to on is a change in bit 0 when writing and the status change will be on bit 6.
A PCF8574 which could also occupy the same address will show a change on bit 0 only confirming the device type as either the SSD1306 or a PCF8574.
I will add more comments as I work out how to test between different devices sharing address space ranges.
Ray
The text was updated successfully, but these errors were encountered: