I can’t quite get this working for some reason. I made all the changes you mentioned. I found that on my computer serial1.c was located in /Applications/Arduino.app/Contents/Java/hardware/teensy/avr/cores/teensy3/serial1.c, so that is where I change the RX buffer size.

I was just testing using serialoscd and I get the following output:

$ ./serialoscd
/Users/corey/Development/serialosc/build/bin/serialosc-device: failed to open device /dev/tty.usbmodem22417301
libmonome: could not open monome device: Resource busy
/Users/corey/Development/serialosc/build/bin/serialosc-device: failed to open device /dev/tty.usbserial-m2020001

Note that I could detect the old neotrellis using this program, so something doesn’t seem right with the Serial1 communication. Not sure where to start debugging from…

Edit: as an additional 2 data points:

  1. I notice that when I push buttons on the grid, the TX LED on the FTDI breakout lights up.
  2. When I run ./serialoscd the RX LED on the FTDI breakout lights up
    So there is some communication trying to happen, but it doesn’t quite work for whatever reason

Ok, I double checked the wiring and I was doing RX-to-RX and TX-to-TX instead of RX-to-TX and TX-to-RX. Whoops! After I fixed that the grid is detected by serialoscd

1 Like

yes i just realized there’s no need for an STM (i’ve been in STM land recently so it’s on my brain) and there’s also no need for ansible hw (i’m working on open-sourcing it the same time as the trilogy… it’s all on the todo list)

with the current TT hw source someone could make said 2hp avr32 + usb host + i2c module. nearly all of the usb code is there (not CDC, but that’s easy), and the i2c implementation would be more of a design issue than a coding issue.

edit: i guess the current ansible “remote TT” mode could be extended to have whatever connected usb device also be remote… again, design issues, not code issues.

also, this is way off topic and if this is to continue, someone please start a new thread

3 Likes

I’m just trying this with my Teletype now, and the little rectangle animation. Its giving lights, but is not quite right: https://drive.google.com/file/d/1hNJuY3kzSiA8YXfTJtHCNDcusk886zzn/view?usp=drivesdk

1 Like

Would this FTDI breakout be “beefy” enough to power a Teensy 3.2 + 128 NeoTrellis grid (provided the USB host had enough juice, of course)?

1 Like

Could you try my MonomeSerialDevice.cpp - I might have left MonomeSerialDevice.cpp (27.7 KB) code changes, which I did not describe, because I thought they were not needed. I am suspecting line 448 in particular.

There should be official power specs for both Teensy and NeoTrellis, you should be able to google them and add them up. Teensy seems take up to 45mA. Per LED I read something like 60mA, but that is the extreme case. That would be wopping 7.68A max, but I think this is pretty unlikely. I have a 200-something Neopixel system here, it max. takes something like 1.3A. However, 600mA might in fact be not beefy enough for the 128, but if you don’t go full brightness it might work with all switched on.

Yes, it seems to work with that new MonomeSerialDevice.cpp file! Thanks

1 Like

You need 5v out from the FTDI board to power teensy and neotrellis boards.

This one (or similar 5v version) would be what you want: https://www.sparkfun.com/products/9716 or https://www.sparkfun.com/products/13263

1 Like

This one seems to have 5V out on the header. Real question is if they snuck polyfuses or current limiters in there. And why is there nary a screw hole to be found? Mount with hot glue? https://www.adafruit.com/product/284

Could you check if the line 448 made the difference? That is, does the problem reoccur when commenting it out or removing it temporarily? Because I should update my instructions above accordingly

@okyeron it looks like that for the Teletype, we do need a check whether data for an invalid quadrand is received and ignore it (if readY >= 8 continue;), otherwise the LEDs will be overwritten by wrong data. The existing code does not seem to be enough to avoid that. Obviously, it should be formulated more generally, using the max number of rows set.

You’ve changed my code enough here that I don’t really understand what’s going on (and I have no Teletype to test against).

I’d suggest forking the code and maintaining your own repo.

Maybe. But actually most of the changes turned out not to be necessary - I was just changing a lot of things to see where the problem was; it simply turned out to be the read buffer, which is not set in the code at all.

I don’t have time at the moment to check which ones and clean up the code. That is why I am hesitant, whether a fork is necessary. The main change is to rename Serial to Serial1, but even that could be integrated by replacing Serial. with a pointer, like serial->read() etc. which could be then set to Serial or Serial1 using a preprocessor directive #ifdef FTDI ...

There are two changes which I didn’t mention before,

  1. calling while(!Serial1.available() ){} before each read, to avoid it failing with -1, should there be no data available
  2. the line if (readY >= NUM_ROWS) continue; or something similiar to avoid setting non-existing LEDs.

Personally I think those could go in the main code without causing issues. One of it probably is necessary, the other only for good measure. When I have time, or somebody here can try, we will know.

I don’t understand. MonomeSerialDevice::poll() is already checking Serial.available().

but whatever… do what you like in your own fork with documentation on the FTDI wiring/setup, etc.

That doesn’t appear to be it. I tried commenting out line 448 and the grid still works.

P.s., it’s pretty great that this works with Teletype! Thanks @mcleinn for figuring it out!

One thing I found when playing with the Teletype is that occasionally the grid would lock-up and stop sending/receive serial. This seemed to happen after a series of really rapid fire button presses. I increased both the SERIAL1_TX_BUFFER_SIZE and SERIAL1_RX_BUFFER_SIZE to 512, and it seems to have helped.

1 Like

I don’t understand. MonomeSerialDevice::poll() is already checking Serial.available().

But only once, that is strictly speaking not enough. It would already pass your check in ::poll() if there is only one byte available (usually the command byte). But, for example, after receiving the map command 0x1A it will continue to read 32 bytes without any check. The reads inside the LED map message receiver could still return -1, if the other side is providing the LED data slower than the Teensy is reading them. Don’t forget the Teletype is sending at 57600 baud only, while the Teensy is clocked at around 96 MHz.

quick question to @okyeron. If i ran the diy_device_fix.sh script in the past would that prevent my fates from recognizing a genuine grid in the future? I don’t have one of those, but I’m trying to connect the neo-trellis with FTDI breakout board to my fates and it’s not showing up in the list of grids. Everytime I connect/disconnect the grid in matron it prints:

product: monome_grid_clone
vendor: monome
serial: m2020001

So, I changed the baud rate set in Serial1.begin from 57600 to 115200, and now fates recognizes the grid. However, the teletype doesn’t seem to like that rate – it works at 57600 but not 115200. Not sure what the correct rate should be?

Edit: it seems like serialoscd likes a baud rate of 115200 but not 57600. So the Teletype is the odd one out?

Edit2:
Looking more at the baud rates I found these lines in uhi_ftdi.c from libavr32

  /// baud rate
  // rq : 3
  // value: 26 (baudrate: 115200)
  // value: 49206 (baudrate : 57600)
  // index: 0
  send_ctl_request(FTDI_DEVICE_OUT_REQTYPE,
		   FTDI_REQ_BAUDRATE,
		   NULL, 0,
		   0, 49206,
		   NULL);

Which, from the comments, would seem to indicate a baud rate of 57600.

I don’t really understand how a grid can operate using multiple baud rates (e.g., 115200 when using Norns and 57600 when using Teletype).

Ansible doesn’t seem to like the FTDI bridge (or I messed something up :joy:)