Attiny85 USI I2C
Looks like USI not working properly at Attiny85. When I set USITC high it stuck (besides i can't set it back to 0 manually) and USISR not count. I even try downloaded hardware I2C libraries and get the same behaviour.
void i2c_clock(unsigned char mask)
{
PORTB &= ~(1<<PIN_SCL);
USISR = mask;
do
{
_delay_us(WL);
USICR |= (1<<USITC);
while ((PINB&(1<<PIN_SCL)));
_delay_us(WS);
USICR |= (1<<USITC);
}
while (!(USISR&(1<<USIOIF)));
_delay_us(WL);
USIDR = 0xFF;
}
v.1.1.0-RC0 R1909 OS:Debian 12
Hi.
USI module is not implemented.
There is some work done, but not finished.
It will be finished soon.
I was just about to ask the same question. Now I know why my ssd1306 driver based on usi doesn't work. Many thanks for taking care of this.
It is almost done, just some details to add or fix.
But for some reason this module was not so easy to understand.
You can see the source code here:
https://bazaar.launchpad.net/~arcachofo/simulide/trunk/view/head:/src/microsim/cores/avr/avrusi.cpp
https://bazaar.launchpad.net/~arcachofo/simulide/trunk/view/head:/src/microsim/cores/avr/avrusi.h
If you have good knowledge of this module you could even help to finish it.
In any case it will be good that you can test when it's done.
I had a look at the code and it appears that start and stop conditions in TWI are detected but the corresponding flags USISIF and USIPF are not set in the status register (USISR). I also couldn't identify the code where the USIOIF overflow bit set, when the 4 bit counter overflows. When are configureA() and configureB() are called?
Thanks for having a look to the code.
flags USISIF and USIPF are not set in the status register (USISR).
Yes, that is not implemented yet, in part because each module has only 1 interrupt by default and this one has 2, so I need to add another interrupt for the start condition, but not yet sure how to do this.
The clock hold stuff in TWI mode is also missing.
I also couldn't identify the code where the USIOIF overflow bit set, when the 4 bit counter overflows.
Right now the default interrupt is assigned to the counter.
Interrupt flags are not set directly, you just raise the interrupt and it will set the flag and do anything needed:
void AvrUsi::stepCounter()
{
*m_statusReg = overrideBits( m_counter, m_USICNT ); // increment counter
if( ++m_counter == 8 ){
m_counter = 0;
m_interrupt->raise();
}
}
When are configureA() and configureB() are called?
You can more or less infer when configureX() is called by the argument: configureA( uint8_t newUSICR )
In this case configureA is called when USICR is written.
Quote from arcachofo on December 24, 2023, 1:51 pmThanks for having a look to the code.
flags USISIF and USIPF are not set in the status register (USISR).
Yes, that is not implemented yet, in part because each module has only 1 interrupt by default and this one has 2, so I need to add another interrupt for the start condition, but not yet sure how to do this.
In my particular application I don't even use the interupt, but check USISIF if a start condition was detected. It would help if USISIF was set, even without triggering an interupt.
In my particular application I don't even use the interupt, but check USISIF if a start condition was detected. It would help if USISIF was set, even without triggering an interupt.
But this should work for all cases, if somebody else wants to use that interrupt it should work.
Maybe I can just "hardcode" the Start Condition Interrupt by now until I find a good solution.
This way we could start to test the overall logic and find some possible issues.
Not sure about the hold of USCL in two-wire mode, maybe we could just ignore this by now.
I will "activate" the module and add it to Attiny85 so we can start some testing even with those functionalities unfinished.
AVR USI is active and added to AttinyX5 at Rev 2108.
It is not finished, but I think it is enough to start doing some testing.
I compile it and just had a quick look at it, but didn't test it. Just one thing that catches my eye, USISIF isn't set when a start conditon was detected. Shouldn't that be the case just like USIPF for a stop condition. I also don't see where OSIOIF is set when a counter overflow occurs.