Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use I2C on pins PF3 and PF2 #112

Closed
miguelwon opened this issue Mar 20, 2021 · 2 comments
Closed

How to use I2C on pins PF3 and PF2 #112

miguelwon opened this issue Mar 20, 2021 · 2 comments

Comments

@miguelwon
Copy link

Hi,

ATMega4809's manual informs that pins PF3 and PF2 can be used for I2C communication (page 7). How can I use those pins for a Wire communication? Is it possible to show a small example?

@MCUdude
Copy link
Owner

MCUdude commented Mar 20, 2021

Hi!

It is correct that these pins can be used for i2c communication, but this is in slave mode only and this "dual-mode" as it is called in the datasheet is not supported by MegaCoreX. I don't have an example to give you, sorry.

You can read more about it in the PORTMUX and TWI section in the complete ATmega4809 datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4808-4809-Data-Sheet-DS40002173A.pdf

@MCUdude MCUdude closed this as completed Apr 4, 2021
@SpenceKonde
Copy link
Contributor

Read the manual more closely, They can only be used as pins for a Wire slave (ie, the atmega480x acting as slave). and only in dual mode. Only PA2/3 and PC2/3 can be master.

@MCUdude - you should seriously steal the megaTinyCore/DxCore version of Wire (I made a pass at trying to make sure that it worked with MEGACOREX parts too, so it would just need a bit of testing). We have come a tremendous way since our wire cores were last similar. There's been a total from the ground up reimplementation, dual mode is now supported (though that doesn't change the fact that PF2/3 are slave pins only), sleep mode doesn't have the risk of blowing up the whole I2C bus, and the missing features that were needed in order for the slave to implement something that acts like a typical I2C device (what I call the "register model", so you can make I2C slaves that use I2C as more than a glorified USART. Oh and the baud rate configuration (finally) actually baud rates pretty close to what you asked for (though it can never guarantee a specific baud rate - the modern AVR TWI watches the levels on the pins so with weak pullups, or high bus capacitance, it'll always run slower than expected, because the rise time is longer)
It supports acting as master or slave on one set of pins, master and slave on one set of pins and dual mode with master on one set of pins and slave on another set (it does require a tools menu added to choose between master or slave (saves flash) vs master and slave. But even master and slave uses less flash than old Wire did (and that's after I cut out the Hardware I2C class that was stuck between it and stream, which bloated it with virtual functions that were never used by the compiler wasn't able to optimize out.
I've been giving the same treatment to Serial as well, for the same reason (I also communed with demons, learning ways to drastically reduce the flash used by the ISRs at the expense of my soul using the most evil of inline assembly - the ISRs are naked, and stubs, push two working registers, exit that inline asm block and immediately enter another (now that we have saved the z register, we can pass the a pointer to the Serial object into it), even as I added support for a bunch of features, so they can now do sync USART and even MSPI mode, it takes up less flash. And autobaud, not that anyone wants it. People think they do, but once they start playing with it, they'll realize they don't).
I've also fixed some bugs that were present in the stuff I added to event last round, and some bugs in comparator (though I think they only impacted tinyAVR). Since they only have two mux options USART, I think you probably want to use the USART implementation from megaTinyCore, not DxCore, which is a lot more complicated because the DD-series have like 6 mux options for USART0, in the name of giving you enough freedom to move the ports around when you've got hardly any physical pins that you have to split them between - and once they add options, the designers seem loathe to remove any.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants