EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: VinzC on January 17, 2016, 11:35:24 am
-
Hi again.
For my current project, i.e. a micro-controlled dummy load, selectable between constant current and constant power, I had opted for an AVR ATtiny1634 as it fitted my requirements: I²C, one UART, at least two 10-bit ADC inputs, 10-bit PWM capable, low number of pins (<=32). I have an Arduino for my testing purposes, still confident that I'd easily port my code to have it run on the Tiny.
I initially intended to use my dummy load through USB or I²C with a Raspberry Pi, an Arduino or a computer for the visual interface because I have other projects in mind based on the same principle. As the project is still at the schematics stage I recently thought about adding three buttons (mode, up, down) and one or two LED for hands-on control. And while I was at it, why not add an LCD...?
Now I stumbled across a section in the documentation that says the 1634 only implements slave I²C circuitry... Though it's no show stopper, does that mean like I believe it does, unlike the ATMega328 it may not initiate any communication on the I²C bus? If so can I work around this hardware limitation on the software side... without reimplementing the whole communication stack, preferably?
-
Bitbanging I2C is not that hard.
-
Bitbanging I2C is not that hard.
Hmmmkay, right. I know it can be done that way — that's how I did that in the nineties with the 8751. That's not my point in fact. First off I wonder why a slave-only implementation... in a microcontroller. Half an implementation doesn't make any sense to me when you can and *need* to do without [pause here] using bit banging. But that's off-topic, of course.
So I deduce from your post there's no hardware support for switching to I²C master, right? In that case having to resort to a pure software implementation and ditch the hardware makes the latter completely useless, which suggests selecting a fitter micro instead. If I got it all right, of course. Did I?
-
I2C Master is usually the simpler thing to implement in software, but needs an extra clock generator in hardware. Having I2C slave hardware also alows to recieve I2C data while in a sleep mode - something not possible in sofware.
The tiny1634 also has an USI unit, that can operate as an I2C master - though with some limitations.
-
The tiny1634 also has an USI unit, that can operate as an I2C master - though with some limitations.
I'm curious. Do you have any link?
EDIT: Guess I've found one on instructables (http://www.instructables.com/id/ATTiny-USI-I2C-The-detailed-in-depth-and-infor/?ALLSTEPS)...
-
Now I stumbled across a section in the documentation that says the 1634 only implements slave I²C circuitry...
Looks that way. I've not seen that in an ATtiny device before, normally they just provide USI.
Looking at the datasheet: It seems a little bit smarter than USI, it has hardware slave address checking and can wake up only when it matches. USI will wake up on any I2C "start" condition and you have to check the slave address yourself.
does that mean it may not initiate any communication on the I²C bus?
Not through that interface, no.
You can do I2C through the USI interface or just plain bitbanging (Me? I'd say a simple bitbanged I2C master is probably easier than using USI... USI is essential for I2C slaves or high-speed SPI, not so much for I2C masters)
-
Thanks a lot for your insights, guys. I still need the I²C bus for the micro to work as a slave though (e.g. to communicate with a host) so using an I²C display would imply doing twice the work, more or less. If I ever plug an LCD I think I'll look at some SPI-enabled devices instead.
-
As people have clarified above, the ATtiny1634 (like most of the current-generation ATtinys) has a USI, which you can use to implement either SPI or I²C in either master or slave mode. This chip has in addition an I²C slave-only module because using the USI to implement an I²C slave is a lot of software work, which hardware can offload.
One thing to keep in mind though with these chips is that while the USI can do either SPI or I²C, it cannot do both at the same time because the two buses would share the same IO pins. The ATmega chips with their separate SPI and I²C controllers let you use both buses on the same circuit, whereas on an ATtiny it's a lot harder to mix them. The same applies to the ATtiny1634's I²C slave module. That slave shares the same IO pins as the USI - you cannot use the I²C slave separately from using the USI.
-
Thanks leonerd. I indeed noticed both I²C and SPI share the same pins so I expected they were mutually exclusive. I haven't finalized my idea yet but I was considering some detection mechanism to switch between SPI and I²C.
The thing is I don't need a display when the board is connected with the I²C bus. And if I have a display then I don't need the I²C bus; or I would use the USB connection to collect data, whatever. This will of course add some complexity to the program but I'm confident.
Or I could as well drop the I²C for good and keep the display *and* the USB channel... I haven't decided yet ::). Sure the fact that the I²C implementation is slave only pleads in favour of dropping it — why bother with a half-finished thing while I can do bidirectional communication with USB.
-
Thanks leonerd. I indeed noticed both I²C and SPI share the same pins so I expected they were mutually exclusive. I haven't finalized my idea yet but I was considering some detection mechanism to switch between SPI and I²C.
One thing you can do successfully (and I've done before) is to use the USI as both an SPI and I²C master, at least one at a time. What I did was use the USI normally for SPI, and wire up the data pin also as SDA for the I²C bus but put the SCL line on a separate GPIO pin.
To talk SPI, just talk normally, using a slave-select line on another GPIO pin. The SPI device talks just fine, and by holding the I²C bus SCL line high (because it has a dedicated GPIO pin), you never present a valid start condition, so all the I²C slaves sit idle.
To talk I²C, all the SPI device slave-selects are deasserted, so they're all ignoring you too. You then have to use the GPIO pin as the I²C clock under software control, but tell the USI to shift itself manually. This gives you I²C data transfer via the USI.
-
To talk SPI, just talk normally, using a slave-select line on another GPIO pin. The SPI device talks just fine, and by holding the I²C bus SCL line high (because it has a dedicated GPIO pin), you never present a valid start condition, so all the I²C slaves sit idle.
Are you sure you haven't got SCL and SDA mixed up?
(http://www.best-microcontroller-projects.com/images/i2c-tutorial-star-stop.png)
-
Huh, oops. So it seems I have. I guess I just got lucky then and the chip I was using didn't mind the constant high-speed start/stop conditions with no bytes of transfer inbetween.
-
Thanks leonerd. I indeed noticed both I²C and SPI share the same pins so I expected they were mutually exclusive. I haven't finalized my idea yet but I was considering some detection mechanism to switch between SPI and I²C.
One thing you can do successfully (and I've done before) is to use the USI as both an SPI and I²C master, at least one at a time. What I did was use the USI normally for SPI, and wire up the data pin also as SDA for the I²C bus but put the SCL line on a separate GPIO pin.
To talk SPI, just talk normally, using a slave-select line on another GPIO pin. The SPI device talks just fine, and by holding the I²C bus SCL line high (because it has a dedicated GPIO pin), you never present a valid start condition, so all the I²C slaves sit idle.
To talk I²C, all the SPI device slave-selects are deasserted, so they're all ignoring you too. You then have to use the GPIO pin as the I²C clock under software control, but tell the USI to shift itself manually. This gives you I²C data transfer via the USI.
A version of this principle is successfully used in Linear Technology's demo board - see http://cds.linear.com/docs/en/demo-board-manual/dc934af.pdf (http://cds.linear.com/docs/en/demo-board-manual/dc934af.pdf) page 5.
On all LTC demo boards the I2C bus is permanently occupied buy an identification and calibration memory chip - U6 in the schematics in the link. This means that demo boards that contain an I2C device (ADC, DAC etc.) must use the SPI bus for I2C data transfer.
The board in the link contains an I2C DAC U1 and an SPI ADC U2. The commonly used SPI bus has the 4 standard pins CS(bar), SCK, MOSI and MISO. When CS is low everything is just a standard SPI bus.
Setting CS high disables the SPI device and activates a dual single pole single throw switch IC U7. This switch hooks up SCL to SCK and SDA to MOSI (and also connects the pull up resistors). The SPI bus is now an I2C bus.
The clock arrangement and data transfer formats are taken care of in the software of the PIC or Atmega that controls the demo board. The code is free to copy from LTC's Linduino library.