I2C to a completely new device
Buck Rogers Posts: 2,146
Adafruit has created these amazing devices. They call them SeeSaw and they come in three flavors, each for a different specie of ATtiny. And this is one of them, Adafruit ATtiny817 Breakout with seesaw - STEMMA QT / Qwiic they've created an interesting series of examples for them. In Python3 and in that peculiar language that the Arduino uses. I'm convinced that if the languages that the Prop1 uses could be appropriately worked into to use that thing, it would greatly extend the usefulness of the Prop1. I believe a Python dialect was explored for the Prop2, but, ah, I do not have any of those devices living here at the moment.
Two Mascots watching.
There's nothing magic about I2C, in fact, it's part of the P1 ecosystem given the P1 uses an I2C EEPROM for program storage. I've written I2C code in Spin1, PASM1, and inline PASM2; others have used C and Forth, perhaps even BASIC under FlexProp. Again, it's a standard protocol and easy to implement.
If you have one of those amazing devices, connect it to the P1 with its SCL connected to P28 (P1 SCL), and SDA connected to P29 (P1 SDA) and run the attached program. In this image you can see the P1 found two devices on its I2C bus. The device at $A0 is its EEPROM, the device at $4E is an I2C LCD.
You can, of course, use other pins for I2C devices. To check them in the attached program you'll need to modify the SCLX and SDAX constants.
Thanks! I'll try your program Jon and see what does happen. Right now the parts are waiting for me to install their headers.
I believe I am doing something wrong. I've wired a QS appropriately. (I think.) I found that I still had one of the things that shows the pin names for a QS-Version. A, and connected power appropriately, and even the I2C connectors, and made sure the colors on the cable were wired correctly. Black to Ground and Red to the voltage that the Prop uses, and then blue and yellow matched also. But each time I instruct the Prop Tool to load your program modules, there I used the readme text file for that information. And running the whole thing tells me that it found the EEPROM for the device. It does not tell me that it found the Adafruit device.
Matched to what, exactly? Details matter.
Since you're seeing the EEPROM the scanner is still set to pins 28 and 29. Move you device SCL pin to 28, and your device SDA pin to 29.
Just to double-check
I use those connectors on my own P2 accessory boards (this simple board is for P2 laser-tag development. I had extra pins, so I added a Qwiic).
Right again. Those were the colors and the pin names I used for trying. Now that I've got confirmation, from you, I'll try again.
Tribbles purring but no mascots.
I ordered a couple of those devices to play with. I have the same scanner program on the P2 which I used because I have a board with a Qwiic connector on it for the P2.
Jon? Besides the P2 board, which could be any of the ones out there, which of the P1 boards did you use? I ask because I have here a batch_of QS boards. And two or perhaps three not used P1 chips. And a project board for the P1, the USB one. Oh and two PAB ones.
To connect those guys to the P1 on the QS board I used a label that was decidedly the same as the back of the QS rev. B boards. I am convinced that the label wasn't properly pointed to the connector.
Purring tribbles, and sleeping mascots.
I used a FLiP and a QuickStart -- just to prove that I2C is I2C.
Here's the scan -- same for both boards
I used a QuickStart RevB and followed the connector markings.
Here's a a screencap from an old project that shows the QS pinout of the connector. Note that the Odd/Even nature stops and P27, and P28/P29 (I2C), and programming (P30/P31) are inline on the inside edge.
I believe I am loading the individual programs into the prop tool wrong. Is the pattern exactly as the README that was enclosed with the individuals the method behind the loading of each? I followed:
But it's the last two that are in fact causing me to be rather confused.
Mascots and tribbles purring.
The topmost file in that list is the only thing you have to open, compile, and download. The others (called child objects) will be sorted out by the compiler -- so long as they're present. The only reason to open a child object is to look at the available methods. DO NOT modify any of the child objects. If you need to change pins, you only have to do that in the parent (jm_i2c_devices.spin).
If you're trying to download object files they're not going to do anything. Most of my object/class files have this as a first method:
If you run that it just stops.
Okay, I closed everything else and then opened the topmost file. And with the device disconnected, I'd then run things and the terminal shows only its EEPROM. Then with the device connected back, making sure to connect SDA and SCL to the proper points of course, The terminal then shows again only the EEPROM. I'm still convinced something is still not quite right here. Oh and thank you for confirming what to load and with what. Of course this is a work in progress and we are making good ones.
You're right. It's your connections. I have made that thing work with the P2, the P1 in QuickStart format, and the P1 in FLiP format.