xmegaforarduino/libraries

libraries directory tree, intended to be placed in sketchbook/libraries (or similar), for xmega-specific versions of Arduino libraries

libraries's Issues

XWire does not compile with other libraries

See XMegaForArduino/arduino#38

specifically, there are build errors when XWire is used in place of 'Wire'. The cause is likely to be a portability problem between the way XWire handles multiple 'Wire' objects, and how its being used by the 3rd party libs.

• make XWire work with standard Arduino libraries
• make XWire work with libraries that are commonly used
• provide instructions for modifying libraries, as needed, or add a 'compatibility' definition to force use of the default TWI interface only [thus being 100% compatible with atmega].

need to add standard libs like EEPROM here

standard libraries like EEPROM are now in the 'hardware/avr' tree and need to be cloned in order to be available for the xmega. otherwise, the include path won't be correctly assigned.

The best way to do that would be to just clone the source as a separate lib, and make sure they work on xmega. This means maintaining them against the avr source changes, however.

I2Cdev does not properly write to a register

attempted to write to a register, caused a hang in the library. seems to be looping in the ISR due to a bus error. I2C spec says I write the register byte [word] followed immediately by the data; i.e. no re-start transaction.

Also if the data exceeds the buffer size, there should be no stop sent [it should continue]

need to make sure that if I get a write interrupt while waiting for more data in a 'bus held' state, that I don't loop in the ISR in XWire, either.

See implementation in XWire twi.cpp for twi_sendTo() to make sure this won't happen, and all bytes will be sent, and so forth.

XSD library needs 'optimize hardware' code test

there is a #define in the XSD ibrary for 'OPTIMIZE_HARDWARE_SPI' (utility/Sd2Card.h) that is currently commented out. This needs to be properly tested and submitted with the definition UN-COMMENTED.

A cursory test has already been done. More thorough testing should be conducted to make it 'official', perhaps one that includes code coverage analysis.

provide "compatibility" libs with atmega naming

for SD, SPI, Wire, and others, provide 'compatibility' versions that plug into anything expecting the atmega library, that actually compile and run using the default interfaces defined in the pins_arduino.h file for the hardware.

In the 'XMega' versions, support for multiple hardware interfaces exists (such as multiple TWI and SPI hardware objects). This is not 100% compatible with the atmega libraries that might reference it. Because libraries can now be platform-specific in the Arduino IDE, new libraries with atmega-compatible names can either wrap the 'XMega' versions, or implement them in atmega-compatible ways.

Wire.write slow, millis wrong

Writing to a 7-segment display on I2c run 100 writes full speed in just under 8 seconds (timed by stopwatch in my hand). Timed by millis, returned 78 milliseconds. The same display, same code, just Wire instead of XWire, in the first line, on Mega2560 run in 33 milliseconds, and was, as expected, too quick to be timed by stopwatch.

Here's Arduino code:

`#include <XWire.h>

void setup()
{
Serial.begin(57600);
Wire.begin();

I2CWrite(0x00, 0x0C, 0x01); // AS1115 is in shutdown on power-up. Wake up & reset feature register.
I2CWrite(0x00, 0x0B, 0x06); // Set scan limit to display 6 digits (no digit 7 on this display unit).
I2CWrite(0x00, 0x09, B11111111); // Set all digits to "HEX decode"

unsigned long timeStart = millis();
for (byte j=0; j<10; j++)
{
for (byte i=0; i<10; i++)
{
Wire.beginTransmission(0x00);
Wire.write(7);
Wire.write(i); // This is teh address of the display digit we are writing to
Wire.endTransmission();
}
}
unsigned long timeEnd = millis();
Serial.println(timeEnd-timeStart);
}

void loop() {}`

XWire/utility twi.c, twi.h - anomolous behavior from slave mode

when using 'slave' mode, the slave does not relinquish the bus properly and respond to a stop following an acknowledgement by the master. Further, the slave mode does not appear to correctly determine whether or not the master has done a 'NACK' in response to data sent by the slave.

This may be due to something simple in the library, or the fact that I was connecting TWIC to TWIE on the same CPU [this might have a built-in conflict].

Will need to test slave TWI operation using the "soft TWI master" library, to verify that it is working correctly, then tweek the master accordingly. If soft TWI can run as a slave as well, then it can be used for testing the TWI master.

[alternately if some 3rd party developer wants to run this using a protocol analyzer, then go for it, and submit patches as needed]

need TWI library!

write hardware TWI library compatible with existing library