#728

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

1 Like
#729

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
#730

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

#731

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.

#732

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.

#733

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.

#734

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.

#735

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!

#736

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
#737

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.

#738

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
#739

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).

#740

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

#741

Could a device request a particular baud rate when initialized? Based on the device data sent it would know what baud rate it should work at? Way above my head but taking some stabs anyway.

#742

Did you try this MonomeSerialDevice file? That fixed things for me. (Aside from the problem that the baud rates are different between libavr32 and serialosc, which still doesn’t make sense, since official grids work fine)

#743

While it may behave the same as serialoscd, note that norns uses libmonome so it might be best to check against those sources

Note there is a 57600 baud reference for the old arduinome https://github.com/monome/libmonome/blob/14aa95a6edfd5f67369e09ad92d4cbc137eb10f9/src/private/devices.h#L36

and then the baud rate “quirk” is set in posix.c although the default is #define MONOME_BAUD_RATE B115200

#744

It seems like libmonome and serialoscd use 115200 for grids. My neo-trellis grid (both with and without the FTDI breakout) works with both libmonome and serialoscd when the teensy firmware is set to use a baud rate of 115200. When I change it to 57600 neither of those work. But Teletype is just the opposite.

#745

I think you are right. I looked at how communication was working in the old mk firmware. In that case the MCU communicates with the FTDI chip over a parallel port connection (manually clocking data in/out of the FTDI chip). This means the MCU doesn’t know/care about the serial baud rate – the FTDI chip can negotiate that with the host however it likes. So multiple baud rates should be possible with a monome grid.

With the neotrellis, on the other hand, the communication between the FTDI board and the teensy is done over the serial port, so an agreed upon baud rate is necessary right from the start. I’m starting to think that maybe it isn’t possible to make the neotrellis work with the Teletype and Norns simultaneously? (Although, maybe the baud rate used by the Teletype could just be increased to 115200).

#746

Yes, changing the Teletype’s baudrate is a one-line change, if you have everything set up to compile and upload the firmware. But there are many workarounds using the Teensy code only. For example, like switching between 57.600 and 115.200 until a valid command is received, and then remaining at this baud rate, until switched off (we don’t need hot plugging, do we?) Or switch between Norns/Teletype mode, when a button is pressed while switching on etc.

1 Like
#747

Hope to not bother anyone as i’s not a teletype question but:
As i’m almost blind and I have to change every grid code that uses varibright (was thinking about of a color change instead of brightness) can I do this project with the old trellis board? They are cheaper and easier to get for me