I’m tinkering a bit around with the arduino shield and remembered seeing somewhere in a post that some ports are already used by the shield.
Just to be sure:
Are A0-A5 all available?
Are any digital Ports (2-13) used by the shield?
Attached the shield to a Mega and CC won’t work with an i2c display connected to SCL/SDA. It looks like the shield connects these ports, but you don’t mention it in your README. It would be quite disappointing, if i2c and CC can’t be used at the same time.
Ok, the shield doesn’t connect these ports to anything. Just didn’t look closely enough. But still, it’s weird, that ControlChain won’t work as long as some LiquidCrystal_I2C object exists.
spend some time experimenting. My first fault was to print to the lcd on every loop cycle. I’ve read, that this can consume quite a bit of time and as @ricardocrudo wrote in the arduino example code, your code shouldn’t be blocking the loop (for too long).
Right now, I have it working and my display shows the assignment label properly, as I only write to the display if something is changing. However, this doesn’t really feel comforting, as LiquidCrystal_I2C is using Wire.h and it looks like Wire.h is blocking.
So, in order to avoid timing issues, we will need a non-blocking i2c display library.
Yes, that’s a pity. Because the way Arduino code is structured, I cannot control the UART interruption myself. I have decided to was forced to put the cc process function in the main loop. As in the Arduino world the UART buffer is only read after the loop function being executed, if you block (or delay) the loop, it will delay the UART reading (consequently the parsing) which makes the Control Chain understanding it as a timeout.
I’ve open a pull request on the Arduino’s code, a long time ago, which would allow me to create and control the UART interrupt as I want.
Regarding UART interrupt: I wonder if it gets worse, if you start fiddling with encoders. To have them working reliably (especially when using i2c displays at the same time), reading their values inside some ISR seems to be sensible. Though I wonder if it affects control chain as well.
I now have 4 encoders attached to my shield and I’m using ISR on PORTB (pins 50-53 and 10-13). Now I stumbled across port 13 being always LOW while the CC shield is attached. I suspect the little LED is causing my issue. Can I simply cut the connection between port 13 and the LED or will that make my shield unusable?
Unfortunately, Arduino Mega doesn’t expose many pins usable for pinchange interrupts, so I really need pin 13.
Hey @Bollie. The problem in this case is not the shield but the Arduino circuit itself.
On the shield circuit I’ve added a MOSFET to the pin 13 so there is no pull-up or pull-down forcing the state on this pin. On the other hand, if you check the Arduino Mega schematic you’ll see the LED is connected directly to the pin 13 through a resistor to ground. This is causing the pin to be always LOW.
In the meantime, I tried using timer interrupts to read the encoder pins on every 1ms. Though that seems to cause trouble, as the MOD looses the connection to my Arduino.
You could try this
noInterrupts();
TCCR2B = 0x00;
TCNT2 = 130;
TIFR2 = 0x00;
TIMSK2 = 0x01;
TCCR2A = 0x00;
TCCR2B = 0x05;
interrupts();
This will trigger an interrupt every millisecond => (1/16E6) * 125 * 128 = 1ms.
your ISR would look like this:
ISR(TIMER2_OVF_vect) {
your code here…
TCNT2 = 130;
TIFR2 = 0x00;
}
The last two lines will reset your counter and clear the interrupt flag. I just tested this with my arduino and CC and it works just fine if you do an analogread in the ISR.