Si5351a and AtTiny3216 #1040
Replies: 7 comments 1 reply
-
And you did not forget the 4K7 pullup resistors? You can give On your nano they are already on. more info |
Beta Was this translation helpful? Give feedback.
-
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:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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!! 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. |
Beta Was this translation helpful? Give feedback.
-
Reopened, didn;t realize was discussion not issue |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm the author of the Etherkit Si5351 library. Oddly enough I decided to try a ATtiny3226 in a project with a Si5351A and I discovered that it doesn't work, as you did. I'm just one person who does this part-time, so testing a bunch of different microcontrollers is difficult for me, but I'm glad I was able to see this bug on my own bench. Thanks for the bug report on the repo, I will be closing that now as well. Please let me know there if you run into further issues with this chip, although I don't anticipate it. |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions