Combining teensies with the Arduino Yun

local_dani_21

Well-known member
Hi

I'm in the middle of a project building an installation using severeal SPI-driven TFT displays using an Arduino Yun. The displays are on the 32u4-side of the yun because it's the easy way to handle multiple SPI devices using it's libraries. The images to be displayed are stored on the AR9331-side of the yun - making it very easy to upload them using WIFI or ethernet from the internet. I then use the built-in Bridge library (and it's co-libraries Process, FileIO etc.) to transfer the images from the AR9331 to the 32u4 and send them to the displays.

Since the 32u4 is very limited in flash- and RAM-memory – I ran out of space very quickly.

Then I thought maybe it would be a good idea to replace the 32u4 with a teensy! Maybe the Teensy 3.1 with a lot more flash, RAM and MHz! Looking at the Arduino Yun schema (http://arduino.cc/en/uploads/Main/arduino-Yun-schematic.pdf), it should be possible to simply put another microcontroller using UART to Arduino Yun pins 0 and 1. The level converter (yuns processor expects GPIO levels to be +- 2.5V) is already onboard the yun.

Since the Bridge libraries are only built into Arduino IDE 1.5.8 and Teensduino only works with Arduino IDE 1.0.6 I tried to backport the libraries to the "old" library Arduino 1.0.X-style - which didn't work since I know very little about Arduino libraries.

--> I would find it very cool if there was a Teensyduino that works with an Arduino IDE that has the bridge library (etc.) onboard.

One could think further: The bridge works VEERY slowly (5 minutes for 1.5 MB of data). Why not connect the processors together alternatively: If there was an USB-possibility, that would speed up things extremely! Or over Ethernet or WiFI (that wouldn't block the USB-port for programming the teensy over the Arduino IDE - if blocked, one would have to re-plug the cables all the time)!
And if the server-side of this USB-/Ethernet-/Wifi-bridge were written in a language other than one that runs only on arduino yun, would maybe be portable to Raspberry Pi or other cool servers.

I would be the greatest fan of anybody who would be able to do such things!
Best regards, Dani
 
Last edited:
Any chance you'll publish a blog or even just detailed setup steps here (especially for how to set up the Raspberry Pi) if I do the programming on the Arduino/Teensy side?
 
Sure! I would be happy to!

What do you think would be the best connection between the computers (see above added concern about not being able to program the teensy when it's USB plug is used for inter-computer-communication)? Ethernet?

Dani
 
Ok, here's my first attempt....

https://github.com/PaulStoffregen/Bridge

By default, it will try to use Serial1 (pins 0 and 1) to talk to the Linux side, just like Arduino Yun.

I added a tiny patch so you can use any port. You can try Bridge.begin(Serial) to talk over the USB serial. Or you can use Bridge.begin(Serial3) to use Serial3 instead of Serial1. The only caveat it you need to use Serial3.begin(250000) before Bridge.begin(Serial3).

Well, there may be other caveats. This is totally untested, but at least it compiles and looks like it ought to work. There are a lot of compiler warnings, because the Arduino devs made this only for 8 bit AVR. I'll look into those later (I'm out of time for hacking this morning). Hopefully this is at least a good start.


Oh, also, this depends on Arduino 1.0.6, so if you have 1.0.5, be sure to upgrade to 1.0.6 and Teensyduino 1.20.
 
I just added one more little change, so Bridge.begin(Serial2) or Bridge.begin(Serial3) will try to set the baud rate automatically, but (hopefully) Bridge.begin(Serial) will still work and let you communicate over USB Serial.

In theory, Bridge.begin(client) should also be able to work, if using Ethernet with surrounding code that opens a connection.

But if you care about speed, USB Serial will probably be the fastest. There's probably a lot of opportunity for improvement inside the Bridge library, speed-wise... but first, let's get things just working before trying to optimize.
 
Bridge doesn't yet compile for teensy++ 2.0

At the moment, I only have a teensy++ 2.0 at hand. When trying to compile the HttpClient example, I get the following errors.
Code:
Arduino: 1.0.6 + Td: 1.20 (Mac OS X), Board: "Teensy++ 2.0"
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=at90usb1286 -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=106 -DTEENSYDUINO=120 -felide-constructors -std=c++0x -DUSB_SERIAL -DLAYOUT_GERMAN_SWISS -I/Applications/Arduino_1.0.6.app/Contents/Resources/Java/hardware/teensy/cores/teensy -I/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src /var/folders/g9/6r6j2ghh8xj4b_001s726yj80000gq/T/build4396337424840366100.tmp/HttpClient.cpp -o /var/folders/g9/6r6j2ghh8xj4b_001s726yj80000gq/T/build4396337424840366100.tmp/HttpClient.cpp.o 
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=at90usb1286 -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=106 -DTEENSYDUINO=120 -felide-constructors -std=c++0x -DUSB_SERIAL -DLAYOUT_GERMAN_SWISS -I/Applications/Arduino_1.0.6.app/Contents/Resources/Java/hardware/teensy/cores/teensy -I/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src -I/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src /Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp -o /var/folders/g9/6r6j2ghh8xj4b_001s726yj80000gq/T/build4396337424840366100.tmp/Bridge/Bridge.cpp.o 
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp: In member function 'void BridgeClass::begin()':
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp:48: warning: only initialized variables can be placed into program memory area
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp:50: warning: only initialized variables can be placed into program memory area
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp:54: warning: only initialized variables can be placed into program memory area
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp:63: warning: comparison between signed and unsigned integer expressions
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp: At global scope:
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.cpp:247: error: no matching function for call to 'SerialBridgeClass::SerialBridgeClass(usb_serial_class&)'
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.h:94: note: candidates are: SerialBridgeClass::SerialBridgeClass(HardwareSerial&)
/Applications/Arduino_1.0.6.app/Contents/Resources/Java/libraries/Bridge/src/Bridge.h:92: note:                 SerialBridgeClass::SerialBridgeClass(const SerialBridgeClass&)

I use a freshly installed Arduino IDE 1.0.6 with a freshly installed teensyduino 1.20 and the Bridge master from the above link.
 
At the moment, I only have a teensy++ 2.0 at hand. When trying to compile the HttpClient example, I get the following errors.

Opps, pins_arduino.h for Teensy 2.x lacks the required definitions.

I've just added them on GitHub. You'll need to grab this file:

https://github.com/PaulStoffregen/cores/blob/master/teensy/pins_arduino.h

Put it in hardware/teensy/cores/teensy, replacing the copy that's already in there. This update will allow the code to compile for Teensy++ 2.0. Of course, this change will be in the upcoming Teensyduino 1.21 in a couple months.
 
Heja, GREAT!, that worked! I have a running bridge from a teensy++ 2.0 to the AR9331 of a yun and into the internet using only two wires (teensy++ pin D2 to yun pin 0; teensy++ pin D3 to yun pin 1)!

Setup:
Schaltplan_Teensy_an_Yun.png

BTW: To make sure that the 32u4 on the arduino yun board doesn't interfere with the bridge, one should not use Serial1 on the 32u4. I even uploaded a sketch as follows to the 32u4 on the yun:
Code:
void setup() {}
void loop() {}

The working sketch on the teensy++ 2.0:
Code:
/*
  Yún HTTP Client

 This example for the Arduino Yún shows how create a basic
 HTTP client that connects to the internet and downloads
 content. In this case, you'll connect to the Arduino
 website and download a version of the logo as ASCII text.

 created by Tom igoe
 May 2013

 This example code is in the public domain.

 http://arduino.cc/en/Tutorial/HttpClient

 */

#include <Bridge.h>
#include <HttpClient.h>

void setup() {
  // Bridge takes about two seconds to start up
  // it can be helpful to use the on-board LED
  // as an indicator for when it has initialized
  pinMode(6, OUTPUT);
  digitalWrite(6, LOW);
  Bridge.begin();
  digitalWrite(6, HIGH);

  Serial.begin(57600);

  while (!Serial); // wait for a serial connection
  Serial.println("Starting...");
}

void loop() {
  // Initialize the client library
  HttpClient client;

  // Make a HTTP request:
  client.get("http://arduino.cc/asciilogo.txt");

  // if there are incoming bytes available
  // from the server, read them and print them:
  while (client.available()) {
    char c = client.read();
    Serial.print(c);
  }
  Serial.flush();

  delay(5000);
}
 
Last edited:
Displaying images from the internet on a TFT connected to a teensy++ using the bridge

Now I connected a 5" (800x480) TFT display http://www.adafruit.com/products/1680using a RA8875 driver board (http://www.adafruit.com/products/1590) by adafruit.

Code:
Teensy++ Pin | RA8875 pin
-------------------------
MISO/23      | MISO
MOSI/22      | MOSI
SCLK/21      | SCK
SS/20        | CS
D1/1         | INT
C7/17        | RST
Gnd          | GND
+5V          | VIN

Put images (BMP-format) at a location that the arduino yun can reach (e.g. on its own SD card that is available to it's webserver uhttp). In my example there are two files at the locations «/mnt/sda1/bilderrahmen/bilder/800x480/IMG_7862.bmp» and «/mnt/sda1/bilderrahmen/bilder/800x480/P1110713.bmp».

I uploaded the following sketch to the teensy++:
Code:
/***************************************************
  5" (800x480 from Adafruit PID1680) an Arduino Yun
  displaying images that are stored on AR9331's SD card.
 ****************************************************/

#include <Adafruit_GFX.h>    // Core graphics library
#include "Adafruit_RA8875.h" // 5" TFT
#include <SPI.h>
#include <Bridge.h>
#include <FileIO.h>

// Hardware SPI pins are specific to the Arduino board type and
// cannot be remapped to alternate pins.

#define RA8875_INT 1
#define RA8875_CS 20
#define RA8875_RESET 17

Adafruit_RA8875 tft5 = Adafruit_RA8875(RA8875_CS, RA8875_RESET);

void setup(void) {
  Bridge.begin(); // Noetig, damit die Console laeuft, man also ueber Internet etwas vom Arduino yun hoeren kann
  Serial.begin(57600);
  while (!Serial); // Warten, bis der Port besetzt ist.
  Serial.println(F("Starting"));

  //------------ Files on AR9331
  Serial.print(F("Connecting to SD card of yun..."));
  if (!FileSystem.begin()) {
    Serial.println("failed!");
    return;
  }
  Serial.println("OK!");






  Serial.println("RA8875 start");
  pinMode(RA8875_RESET, OUTPUT);
  digitalWrite(RA8875_RESET, LOW);
  delay(50);
  digitalWrite(RA8875_RESET, HIGH);
  delay(200);

  /* Initialise the display using 'RA8875_480x272' or 'RA8875_800x480' */
  if (!tft5.begin(RA8875_800x480)) {
    Serial.println("RA8875 Not Found!");
    while (1);
  }

  Serial.println("Found RA8875");

  tft5.displayOn(true);
  tft5.GPIOX(true);      // Enable TFT - display enable tied to GPIOX
  tft5.PWM1config(true, RA8875_PWM_CLK_DIV4096); // PWM output for backlight
  tft5.PWM1out(255);
}

void loop() {
	char url1b[] = "/mnt/sda1/bilderrahmen/bilder/800x480/IMG_7862.bmp";
	char url2b[] = "/mnt/sda1/bilderrahmen/bilder/800x480/P1110713.bmp";
	bmpDrawTft5(url1b,0,0);
	delay(5000);
	bmpDrawTft5(url2b,0,0);
	delay(5000);
}

// This function opens a Windows Bitmap (BMP) file and
// displays it at the given coordinates.  It's sped up
// by reading many pixels worth of data at a time
// (rather than pixel by pixel).  Increasing the buffer
// size takes more of the Arduino's precious RAM but
// makes loading a little faster.  20 pixels seems a
// good balance.

#define BUFFPIXEL 20


void bmpDrawTft5(char *filename, int x, int y) {
  int      bmpWidth, bmpHeight;   // W+H in pixels
  uint8_t  bmpDepth;              // Bit depth (currently must be 24)
  uint32_t bmpImageoffset;        // Start of image data in file
  uint32_t rowSize;               // Not always = bmpWidth; may have padding
  uint8_t  sdbuffer[3*BUFFPIXEL]; // pixel in buffer (R+G+B per pixel)
  uint16_t lcdbuffer[BUFFPIXEL];  // pixel out buffer (16-bit per pixel)
  uint8_t  buffidx = sizeof(sdbuffer); // Current position in sdbuffer
  boolean  goodBmp = false;       // Set to true on valid header parse
  boolean  flip    = true;        // BMP is stored bottom-to-top
  int      w, h, row, col;
  uint8_t  r, g, b;
  uint32_t pos = 0, startTime = millis();
  uint8_t  lcdidx = 0;
  boolean  first = true;

  if((x >= tft5.width()) || (y >= tft5.height())) return;

  Serial.println();
  Serial.print(F("Loading image '"));
  Serial.print(filename);
  Serial.println('\'');

  File bmpFile = FileSystem.open(filename);
  if (bmpFile == NULL) {
    Serial.println(F("File not found"));
    return;
  }
  else {
    Serial.println(F("File found"));
  }
  // Parse BMP header
  if(read16(&bmpFile) == 0x4D42) { // BMP signature
    Serial.println(F("File size: "));
    Serial.println(read32(&bmpFile));
    (void)read32(&bmpFile); // Read & ignore creator bytes
    bmpImageoffset = read32(&bmpFile); // Start of image data

    // Read DIB header
    (void)read32(&bmpFile); // Header size
    bmpWidth  = read32(&bmpFile);
    bmpHeight = read32(&bmpFile);

    if(read16(&bmpFile) == 1) { // # planes -- must be '1'
      bmpDepth = read16(&bmpFile); // bits per pixel
      Serial.print(F("Bit Depth: "));
      Serial.println(bmpDepth);
      if((bmpDepth == 24) && (read32(&bmpFile) == 0)) { // 0 = uncompressed
        goodBmp = true; // Supported BMP format -- proceed!
        Serial.print(F("Image size: "));
        Serial.print(bmpWidth);
        Serial.print('x');
        Serial.println(bmpHeight);

        // BMP rows are padded (if needed) to 4-byte boundary
        rowSize = (bmpWidth * 3 + 3) & ~3;

        // If bmpHeight is negative, image is in top-down order.
        // This is not canon but has been observed in the wild.
        if(bmpHeight < 0) {
          bmpHeight = -bmpHeight;
          flip      = false;
        }

        // Crop area to be loaded
        w = bmpWidth;
        h = bmpHeight;
        if((x+w-1) >= tft5.width())  w = tft5.width()  - x;
        if((y+h-1) >= tft5.height()) h = tft5.height() - y;

        // Set tft5 address window to clipped image bounds

        for (row=0; row<h; row++) { // For each scanline...
          // Seek to start of scan line.  It might seem labor-
          // intensive to be doing this on every line, but this
          // method covers a lot of gritty details like cropping
          // and scanline padding.  Also, the seek only takes
          // place if the file position actually needs to change
          // (avoids a lot of cluster math in SD library).
          if(flip) // Bitmap is stored bottom-to-top order (normal BMP)
            pos = bmpImageoffset + (bmpHeight - 1 - row) * rowSize;
          else     // Bitmap is stored top-to-bottom
          pos = bmpImageoffset + row * rowSize;
          if(bmpFile.position() != pos) { // Need seek?
            bmpFile.seek(pos);
            buffidx = sizeof(sdbuffer); // Force buffer reload
          }

          for (col=0; col<w; col++) { // For each column...
            // Time to read more pixel data?
            if (buffidx >= sizeof(sdbuffer)) { // Indeed
              // Push LCD buffer to the display first
              if(lcdidx > 0) {
                tft5.drawPixel(col, row, lcdbuffer[lcdidx]);
                lcdidx = 0;
                first  = false;
              }

              bmpFile.read(sdbuffer, sizeof(sdbuffer));
              buffidx = 0; // Set index to beginning
            }

            // Convert pixel from BMP to tft5 format
            b = sdbuffer[buffidx++];
            g = sdbuffer[buffidx++];
            r = sdbuffer[buffidx++];
            lcdbuffer[lcdidx] = color565(r,g,b);
            tft5.drawPixel(col, row, lcdbuffer[lcdidx]);
          } // end pixel

        } // end scanline

        // Write any remaining data to LCD
        if(lcdidx > 0) {
          tft5.drawPixel(col, row, lcdbuffer[lcdidx]);
        }

        Serial.print(F("Loaded in "));
        Serial.print(millis() - startTime);
        Serial.println(" ms");

      } // end goodBmp
    }
  }

  bmpFile.close();
  if(!goodBmp) Serial.println(F("No BMP?"));

}

// These read 16- and 32-bit types from the SD card file.
// BMP data is stored little-endian, Arduino is little-endian too.
// May need to reverse subscript order if porting elsewhere.

uint16_t read16(File *f) {
  uint16_t result;
  ((uint8_t *)&result)[0] = f->read(); // LSB
  ((uint8_t *)&result)[1] = f->read(); // MSB
  return result;
}

uint32_t read32(File *f) {
  uint32_t result;
  ((uint8_t *)&result)[0] = f->read(); // LSB
  ((uint8_t *)&result)[1] = f->read();
  ((uint8_t *)&result)[2] = f->read();
  ((uint8_t *)&result)[3] = f->read(); // MSB
  return result;
}

uint16_t color565(uint8_t r, uint8_t g, uint8_t b) {
  return ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3);
}

byte decToBcd(byte val){
  // Convert normal decimal numbers to binary coded decimal
  return ( (val/10*16) + (val%10) );
}

And let it run!
P1120016_1200.jpg
 
Last edited:
Of course there is still the speed issue of the bridge (and if that were solved there remain still the only 16MHz of the teensy++):
P1120017.jpg
271seconds (almost 5 minutes) to draw one image ... but we are working on that, aren't we? Looking forward!
Dani
 
Last edited:
On the side - I setup the image-delivering php-scripts on both arduino yun and raspberry pie: the AR9331 (400MHz) seems to be a lot quicker handing out websites and images than raspberry pi (700MHz). If possible, I'll stick with the yun. But porting the whole application to raspberry pi shouldn't be a problem - if we get a fast connection from a teensy to the apache of the raspberry pi. I'll document it with both systems.
 
Last edited:
I just got a teensy 3.1 and an ethernet shield; rpi is up and running; I'm looking forward to alternative ways to let the two systems communicate.
 
Renaming class File to MyFile to avoid conflicts with the SD library.

Hi Paul

I just altered your Bridge library version renaming the File class (in FileIO.h/.cpp) to MyFile to avoid conflicts with the File-class of the SD library. It works well and allows me to copy files from the linux to the SD card on the arduino/teensy side. Maybe this is something you might want to add to your version. I like the functionality a lot! I also left the file at http://forum.arduino.cc/index.php?topic=273347.msg1991058#msg1991058 because I once had started a post there. Do you think that I should write this de-conflict-try to some arduino-library-admin guys?

Regards,
Dani

The following code copies a file on the linux-side to the SD card on the teensy 3.1 side, that is connected over a serial connection to the AR9331.
Code:
/***************************************************
  Copying a file from Yun's AR9331-SD to teensy3.1-SD
  over FileIO (Bridge).

 ****************************************************/

#include <SPI.h>
#include <SD.h>
#include <Bridge.h>
#include <FileIO.h>

#define SD_CS 10

void setup(void) {
  Bridge.begin(); // Start bridge
  Serial.begin(57600);
  while(!Serial){;};
  Serial.println("Start");
  pinMode(SS, OUTPUT); // Hardware SS must be set to Output!

  Serial.print("Initializing SD card...");
  if (!SD.begin(SD_CS)) {
    Serial.println("failed!");
  }
  else {
  	Serial.println("OK!");
  }

  File sdFile = SD.open("test.bmp", FILE_WRITE);

  // if the file opened okay, write to it:
  if (sdFile) {
    Serial.println("File opened ...");
    // Open requested file on SD card of AR9331
    MyFile bmpFile = FileSystem.open("/mnt/sda1/bilderrahmen/bilder/75er/001.bmp");
    if (bmpFile == NULL) {
      Serial.println("File not found");
      return;
    }
    else {
      Serial.println("File found");
    }
    // Now read from the bridge and write to sdFile.
    while (bmpFile.available()){
    	sdFile.write(bmpFile.read());
    }
    sdFile.close();
    Serial.println("and closed");
  } else {
    // if the file didn't open, print an error:
    Serial.println("error opening test.bmp");
  }
}

void loop() {
}
 

Attachments

  • Bridge.zip
    134.2 KB · Views: 129
Last edited:
I posted a question on their mail list.

Sadly, this seems like a shortsighted design that's now solidified in 2 widely used libraries, so I'm not hopeful for a good solution.
 
Paul, as much as I would like to use a teensy3.1 together with a RPi and a bridge in between them - I have not heard of anybody who feels like porting the bridge to RPi or of anyone who has done it already (http://www.linino.org/forums/topic/porting-the-bridge-linux-side-to-other-linuxes/, http://forum.arduino.cc/index.php?topic=280585). Unfortunately, I have neither the ressources nor the knowledge to do that task - so I'm stuck with your teensy3.1 and an original Arduino Yùn - connected over UART and your bridge version (which is a good combination apart from the «old» php 5.4 on the AR9331 and the relatively slow AR9331).

Therefore it looks like I won't be able to set up a detailed blog on how to accomplish such a thing as you asked me to. I'm sorry - I would have loved to do that. If you (in the next few weeks) hear of someone who has done it - I'll be happy to pick up the task again! Otherwise I'll build my installation with what I have.

Best regards, Dani
 
Last edited:
It's interesting to see that command on the Linino forum about "make a porting of the Bridge on MCU side for the Cortex…"

This is actually on my very long-term list to try, probably after we have a Teensy based on Cortex-M7. Well, not porting the Python code itself, but rather emulating a subset of it with native C++ code.
 
Ok, maybe it's not so simple & easy to just run it on any Linux machine.

But I'm not going to let lack of familiarity and experience with a language like Python stand in my way......
 
Well, turns out the Bridge.begin(port) and Bridge.begin(port, baud) functions weren't working. I've committed a fix.

https://github.com/PaulStoffregen/Bridge/commit/498a662d0e3d79509e45b67bdbe847b43e31e616


I've also started working on the Linux side. It's slow going, since I'm not very familiar with Python. Here's the repository:

https://github.com/PaulStoffregen/GenericBridge

On Arduino Yun, the serial console is connected to pins 0 & 1 (Serial1). The baud rate appears to be established before Linux boots. The Bridge library simple sends a CTRL-C to interrupt any running program, then it sends "run-bridge", expecting the command line to run a script which starts the python code.

I'm still debating how this should work for non-Yun systems. Perhaps a udev rule should run it? Or maybe the Python code should be changed to it open the a port? This startup, managing device removal (for USB Serial), and how to specify which device to use is still a lot of unresolved decisions. Any input is welcome......
 
Ok, here's another attempt. I tested these pieces and it's looking pretty good, but I still haven't had time to try actually using it for a project. I'm really hoping you can give this a good try and let me know how it goes?

I fixed a couple critical bugs in the Bridge code (stuff I didn't consider in my first round of edits) on the Arduino side. This time, I verified Bridge communication really is getting to the USB serial.

Please make sure you're using the latest:

https://github.com/PaulStoffregen/Bridge

Here's the code for the Linux side:

https://github.com/PaulStoffregen/BridgeUSB

Earlier today I had considered heavily modifying the Linux side, to manage reconnecting. But that's udev's job. This approach should be much cleaner. A udev rule causes a script to run, which sets up the freshly-created USB Serial device to work like Yun's console.

While I'm pretty sure this will work, there's probably a ton of little differences between the Linino system on Yun and Linux distros like Rapian, Debian (or whatever's on Beaglebone now), and Ubuntu. That stuff can probably get investigated and fixed later, when the two Bridge sides are talking well over USB.
 
Another piece of this puzzle, which is definitely missing, is supporting Yun's ability to reprogram the Teensy side over the network.

Truth is, I really don't know much about how that part works. Maybe someone who knows more can comment? I know a good number of people have really wanted to be able to move up to more powerful hardware. If there's really interest, hopefully we can get at least a few more people willing to endure bleeding edge code (and swapping USB cables around to reprogram) to at least figure out if the basic Bridge functions are working.

Whether (and when) I put more time into supporting the reprogramming over the network will depend on how many people seem really interested, and how many are actually using a Teensy 3.1 + Linux board combo.
 
That is so cool! Unfortunately, I'm very (like day and night) busy this week with my payjobs - but I'll give it a thorough try as soon as I can! Thanks already! Dani
 
Last edited:
Back
Top