Si5351a and AtTiny3216

[WaynePauly]

Does anyone have an example of getting a Si5351a to work with an AtTiny? The basic example in the Si5351a.h library works fine with a Nano or ESP8266 but not with the AtTiny3216. I am using the Arduino IDE 1.8.15 with MegaTinyCore, wire.h and Si5351a.h and it seems like an I2C issue.

[hmeijdam]

And you did not forget the 4K7 pullup resistors?

You can give Wire.usePullup() a try and see if you get away with the internal pullups.

On your nano they are already on.

more info

[WaynePauly]

Thank you for the prompt response. No I didn't forget them and I just tried the Adafruit_SI5351 library and it works, but not the Skyworks library.

…

------ Original Message ------ Received: Sat, 16 Dec 2023 07:53:13 AM EST From: Hans ***@***.***> To: SpenceKonde/megaTinyCore ***@***.***>Cc: WaynePauly ***@***.***>, Author ***@***.***> Subject: Re: [SpenceKonde/megaTinyCore] Si5351a and AtTiny3216 (Discussion #1040) And you did not forget the 4K7 pullup resistors? You can give `Wire.usePullup()` a try and see if get away with the internal pullups. On your nano they are already on. more [info](https://github.com/SpenceKonde/megaTinyCore#i2c-requires-external-pullup-resistors)

-- Reply to this email directly or view it on GitHub: #1040 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[SpenceKonde]

Sounds like a bug you should report to the skyworks library maintainers. If they have questions about what they're doing wrong, I'm happy to help (but I don't even know who they are or what the repo is because you haven't shared enough information to uniquely identify the library).

Please, any time an issue involves code from somewhere else, like a library always include the link to the repo or site that you downloaded the library from, not just it's name; the former identifies it uniquely, no two sources can have the same URL. The latter doesn't - there are hundreds of LiquidCrystal_I2C libraries, most of which have seen important changes in various combinations to the source code without any changes to the readme from upstream.

It's like if I said, "Joe's an expert on this sort of thing, he knows a perfect solution, talk to him" and left... and you're just standing there like "Joe? Joe who? The owner of Joe's Diner downtown? Joe Smith in accounting? Joe Biden?" (The last one is unlikely, for a variety of reasons. But from the information I'd given, that could totally be who I meant). I have consistently been unable to guess sucessfully which fork of a library someone is using. I have gotten it wrong I think every time I've attempted it.

Which is not surprising statistically, considering the way github promotes (by making it super easy and automatic) creation of low quality and unmaintained forks not clearly marked as such (github should prefix the readme when they fork a repo from another user, something like #This library was forked from <user>/<repo> by <new owner>. There have been <number> commits to this repo and <number> to the upstream repo, and during this time the readme file has not been modified. Before removing this notice, please describe why you made the fork and your plans for it's future (personal use, or do you expect and want the public to use it, or are they better off sticking to the upstream version? If it's intended for public consumption, how does this fork differ from the original? The unmodified original contents follow. That wouldn't keep there from being literally hundreds of forks of some libraries, but it would make it clear which ones you shouldn't use, and would encourage better marking of the intended audience.

[SpenceKonde]

Closing since it is apparentl;y a bug in the library, likely a total absence of support for modern AVRs combined with either ignorance of the fact that their old test won't work here, even though their library will work fine since it just uses [Wire,SPI, Serial, etc through the standard libraries or built-in, or because it rolled it's own I2C interface or something like some of these libraries do - but that means they need to reimplement it for modern AVR (note that a single implementation will cover tiny0, tiny1, tiny2, DA, DB, DD, DU, EA, and EB and any future parts for the forseeable future)

OH!!! I'll bet I know what this is!!
It's probably trying to use the internal pullups, but doing it like a classic AVR would by writing the pin high while it was an input. That not only doesn't turn on the pullups, on some modern AVRs (even microchip seems unsure which ones, it's come and gone from errata sheets without a die rev, implying that they're struggling to know which parts are impacted), in manifests a silicon bug regarding the port override behavior of the I2C peripheral. The design intent was that it would override both the data direction and force the output value to LOW. On impacted parts, under some conditions, the output value was not correctly overridden, allowing the AVR to illegally drive the open collector bus HIGH instead of LOW, potentially damaging downstream devices and certainly fucking up communication.

If he tried to force on the pullups via any means other than pinMode(pin,mode) or pinModeFast(constant compiletime known pin, constant compile time known mode).

This situation was particularly bad a year or two back before I started asking for comments on it and found that the people who demanded this obnoxious backwards compatibility thing were nowhere to be found, and users were united against it: In the past, not only did digitalWrite on input emulate the old behavior and turn on the pullup, *pinMode() also emulated the classic AVR behavior so that pinModeing a pin input_pullup would result in output value being set high as well as turning on the pullup. this was invisible to the user. Unless they used pinMode() which would fuck everything up. So where in the past there was nobody opposed and many in favor, the supporters had all scurried away when the angry bug report came in . So if you're using an old version of the core, lotsof things are not expected to work, don't use old versions of the core.

[SpenceKonde]

Reopened, didn;t realize was discussion not issue

[WaynePauly]

Sorry I wasn't clear as I wrongly assumed everyone was familiar with this chip. The Si5351 is an extremely popular clock chip made by SiliconLabs, now owned by Skyworks and the Si5351.h library is in the Arduino library manager under Etherkit Si5351 or https://github.com/etherkit/Si5351Arduino, not exactly Joe's Diner. Since the Adafruit Si5351 library works perfectly with the AtTiny3216 I agree it is an issue with the library and not MegaTinyCore and I will follow up with them, whoever them is. Thanks again. Now you can close it for good!

[SpenceKonde]

Damn, it;s so popular I've never heard of it....