Wire.h and ATtiny as slave-sender #592
FabiousBIT
started this conversation in
Support / Q & A
Replies: 1 comment 1 reply
-
Did you make sure to select. from the Tools -> Wire Mode menu. the "slave"
option?
Background (you can skip this whole runon rambling paragraph) The Universal
Wire library (the special version of Wire.h the core ships with - see, for
ATTinyCore, depending on the part, there are three different
implementations of I2C required - the48/88 has standard master/slave TWI
module. The 841, 441, and 828 have a hardware TWI slave only, but no master
functionality in hardware whatsoever, so master mode needs a full
softweare/bitbanged I2C implermentation for master functionality, and
everything else has, instead of an SPI and TWI interface (well, the 167 is
blessed with a real SPI interface - like the x41 and 828, in addition to
the 48/88 have), have what Atmel euphemistically called a Universal Serial
Interface (USI). The Ugly Shit Interface is a miserable excuse for a
peripheral which permits implementing SPI or I2C ever so slightly more
easily than bitbanging - I'd never realized just how awful it was until I
had to fix a bug specific to the 861 asmnd its' USI I2C implementation, but
it's prbably rthe most disappointing peripheral included on any AVR
released in the past decade (the last one was the 1634 in what, 2012 or
2013?), and within the entire zoo of marginal processors that is the
classic AVR product line, I strtugle to think of a peripheral which I found
more dismal.... I can think of multiple peripherals that I disliked working
with more passionately, but they were all capable pieces of hardware, they
just sucked to use. The USI also just plain sucked and sucked to use). But
I digress....My poiny is that, prior to the universal SPI and universal
Wire libraries my core supplies being added way back in 1.1.x or 1.2.x, if
you wanted to use an I2C device on one of those parts, and had a library
the worked great on an Uno, even if it was done the rtight way and included
Wire.h to get it's I2C functionality (*), that didn't get you anywhere -
because you would need to use a different library (ex, USIWire for the USI
parrts). And even though at least some of these alternative libraries
implemented the same API they could not be used as drop-in replacements.
You had to modify the library in several ways to make it puill in that
library and refer to it correctly, Now we all know how good at mucking
around with libraries most arduino users are; that basically meant people
only got to use libraries that had been modfied by an expert to work on the
tiny in question). I did not like that - I didn't like modifying libraries
any more than the next guy, and I also wrorte, and write, code that I
expect to run on radically different hardware without code changes, and ofc
people kept complaining about compile errors when they tried to include the
stock version of wire, which isn't compatible with the tinies. So for both
I2C and SPI, me and a couple of others dug up the closest-to-standard
implementations of those protocols for the three classes of tiny, massaged
over the differences between their APIs so the standard API calls all
worked (or approximated working - a few, like the ones that set the clock
speed are just empty functions because we couldn't think of how to
implement it; no clock generation functionality is present in the Ugly Shit
Interface, instead, there's a magic register you write to that that toggles
the clock line and clocks out a bit on one of the edges (no joke, that's
really what you're supposed to do!)), and papered over the differences
between the hardware the best we could, then wrapped them, all up in files
with the same names as the standard libraries, with the objects and classes
named the same things and so on, and preprocessor macros to conditionally
compile the correct implementation of that interface... So you could now
just pick up an I2C device library that interacted with I2C using the Wire
API, and it would Just Work. Slave I2C code and master I2C code would Just
Work , most of the time.... .
But there was a problem, and one which even with an extra 4-5 years of
embedded programming experience and skill under my belt, my depth of
compiler-understanding and the constraints faced by the optimizer does not
lend clarity to - in the case of the Software-master-hardware-slave wire
implementations (for ther 441, 841, and 828) none of us could get it to
only include in the final binary only the methods that were used. Every
method, master or slave, was built and stuffed into the binary, which
brought unacceptable bloat. The only way I could get rid of the unused
functions was to have a macro which selected whether to support master,
slave, or both. And since the defines controlling that needed to be
propagated no matter what roundabout route was used to finally end up
including the Universal Wire library, the only way to do it was a tools
submenu. And so that's why those three parts have that extra wire mode
tools submenu - Even though it's bloody obvious if it's a master or slave
from the sketch, the compilers not smart enough to understand that, and you
have to explicitly specify with that menu.
I think for 2.0.0, since I am removing support for turning off LTO, I will
be able make the compiler at least error with a helpful message in that
case, so like, you'd do Wire.begin(0x69) and had master mode (default,
because more common) selected - instead ofthe crap you saw, you'd get a
compile error saying "To use slave functionality through the Universal Wire
library (Wire.h), select "Slave" or "both" from the tools -> wire mode
menu" - like how my newer cores will give compile errors when you do things
that we can determine are guaranteed not to do anything useful at compile
time.
For example, megaTinyCore and DxCore. if you. like, digitalWrite to a pin
that doesn't exist, or call analogReference(123) (that function just takes
a number, those keywords like INTERNAL that you're supposed to pass are
just #defined to numbers because the alternatives aren't efficient enough
for embedded systems), instead of it scribbling over the REFs bits with
garbage or silently ignoring your write - we will give a compile error
because we KNOW that there is no possible way that those could ever be
intended, better to tell the user where the problem is immediately, instead
of letting them compile and upload and then wonder why the pin they meant
to write to wasn't being written to, or why the analog readings are messed
up)
…On Tue, Jul 20, 2021 at 4:05 PM FabiousBIT ***@***.***> wrote:
Errors.pdf
<https://github.com/SpenceKonde/ATTinyCore/files/6850918/Errors.pdf>
Hello!
I am writing a sketch for my project on ATtiny 841 using your libraries.
Connecting the Wire.h library, defining the ATtiny 841 as a slave sender -
I get the errors that I posted in the document for this post.
maybe i'm doing something wrong?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#592>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW65NE6HQPK4ETP4JQ3TYXJIJANCNFSM5AWP7E3A>
.
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: ***@***.***
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Errors.pdf
Hello!
I am writing a sketch for my project on ATtiny 841 using your libraries.
Connecting the Wire.h library, defining the ATtiny 841 as a slave sender - I get the errors that I posted in the document for this post.
maybe i'm doing something wrong?
Example at \ArduinoData\packages\ATTinyCore\hardware\avr\1.5.2\libraries\Wire\examples\slave_sender\ returns the same errors of compilation!
Beta Was this translation helpful? Give feedback.
All reactions