Member Since: December 18, 2010

Country: United States

  • This design may use a 485 transceiver and serve for some use (?), but it is NOT an RS-485 at all. The part should be connected to drive transmit data differentially both ways, 1 and 0.

  • Received a defective one today. The baud rate is too far off to work on UART. These do not have a crystal for accurate baud rates. While it is possible to calibrate the internal oscillator I don't think that is being done.

  • The red ones are fine, the green one is so dim it is useless. Too bad I didn't read the comments below first, I see this is a known problem.

  • I hope you can fix the backorder malfunction soon :(

  • Starting at 1 makes them Lua programming compatible...

  • This provided code appears simple, turning a bridge on or off with no PWM or stepper feature. Precise timing was probably not the target. If you wanted to try some stable PWM type of control would this approach work:

  • Obscure tip department: Talking to this from a Raspberry Pi on I2C will experience occasional errors due to a bug in the Raspberry Pi CPU I2C peripheral. Building the software for this display with a delayMicroseconds(3) in the Wire library twi.c file works around the issue. This line goes in the IRQ handler SIGNAL(TWI_vect) right after the slave receiver "case TW_SR_GCALL_ACK". Hackish but errors go away. Keep in mind the problem is in the Pi not this display. // Slave Receiver case TW_SR_SLA_ACK: // addressed, returned ack case TW_SR_GCALL_ACK: // addressed generally, returned ack delayMicroseconds(3);

  • Looks like they just changed the default DISPLAY_TYPE to S7S in the git repo and tweaked the net names in comments to line up better. Another tip, I needed to reset the EEPROM to defaults after the first time it was reprogrammed to the latest.

  • Thank you for the FTDI, addressing my biggest Uno complaint. Not sure about the durability of the SMT headers when pulling shields off, sometimes they can really grab in there, time will tell.

  • Looks like the USB bootloader is in place. Better yet I see a Jtag on the schematic which would work with a debug pod. Atmel studio is free and powerful. I have used UC3 AVR32 at work, they are about equal to ARM Cortex M3. Anyway, I have been pondering stand alone too. It depends what the source for the on board software is like, if it will be practical and fun.

No public wish lists :(