@okyeron Yes, my bad. It will indeed work - I am working late at night, so I missed that the read is only done for one of the nibbles (esp in combination with the “64 byte” claim in the specs). Sorry for creating confusion. So that part is actually fine.

In good news: I solved my communication problems, the Grid is now receiving 100% of the data sent by Teletype, without skipping bytes or updates.

For that, I had to change
#define SERIAL1_RX_BUFFER_SIZE 64
to
#define SERIAL1_RX_BUFFER_SIZE 256
in C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\serial1.c

Otherwise the buffer would quickly overflow, as FTDI gets serial data in chunks of 62 bytes. Now what is left is to test the buttons.

Video:
https://drive.google.com/file/d/12iAIDKQx3YBmtZuk43CWlWwB60ygUvpV/view?usp=sharing

For anyone who wants to try it thus remains:

  • flashing the FTDI breakout (use originals, Chinese copies often will not allow to permanently change the vendor string and serial number). Details in older posts above.
  • change the response to 0x01 to six bytes (for example to 00 01 02 00 02 02)
  • change Serial. to Serial1. for everything non-debugging related, open port with 57600 baud
  • increase buffer size of RX_BUFFER in serial1.c of the Teensy hardware definition in the Arduino folder

Maybe the init can be fixed by simply copying what is in mk.c and sending 3 more bytes

so at line 232 it becomes:

        case 0x00:  // device information
        	// [null, "led-grid", "key-grid", "digital-out", "digital-in", "encoder", "analog-in", "analog-out", "tilt", "led-ring"]
            //Serial.println("0x00 system / query ----------------------");
            Serial.write((uint8_t)0x00); // action: response, 0x00 = system
            Serial.write((uint8_t)0x01); // section id, 1 = led-grid, 2 = key-grid, 5 = encoder/arc	
            Serial.write((uint8_t)0x01);

            Serial.write((uint8_t)0x00); // action: response, 0x00 = system
            Serial.write((uint8_t)0x02); // section id, 1 = led-grid, 2 = key-grid, 5 = encoder/arc	
            Serial.write((uint8_t)0x01);

            break;
1 Like

I thought byte 3 and 6 should still be the number of quadrants, no? Not that it seems to make a difference to my Teletype (no idea, why), but for others it might.

second guessing myself… (and changed it from numQuads)

according to the mk.c source the third byte is output_buffer[output_write] = GRIDS;

and then previously there’s #define GRIDS 1 - but - that’s one 8x8 quad.

So yes - i think it should be number of quadrants.

1 Like

Key presses are unfortunately not yet reflected in Teletype (TX LED on breakout is reacting however). Could it be, because in the Teensy code it is a three byte message, while Teletype seems to expect four? (message id, x, y, val) But again, no mention of a third parameter in the spec…

no, this is not related and it does not differ from the spec.

the spec says that a key press produces [0x21, x, y] and a key lift produces [0x20, x, y].

that function (easier for us if it is linked rather than screen-cap’d…) is internal to the libavr32 stack. instead of treating press/lift as separate events, it adds a state byte (and of course discards the command byte.) additionally, the data that is finally pushed to the internal event loop includes a 4th byte to identify it as a grid key event.

Yes was just a bad guess, indeed, the third parameter is taken from the command byte. I still don’t know, why it wouldn’t react. Or maybe it shouldn’t without a script? I will try tomorrow, I guess.

serial.txt fixed on the repo. wrong for something like a decade. :tada:

6 Likes

Aaaa… I ran a different script, from https://github.com/scanner-darkly/teletype/wiki/BUTTONS
and it looks like the buttons are actually working, they just do not have a function without a script. Great stuff.

Video:
https://drive.google.com/file/d/12mYczRLpylMH2BwIq-JbkfXZRkBqt1ul/view?usp=sharing

So as far as I am concerned, the Grid now seems to be 100% ready to run with the Teletype. If you don’t mind, I will branch on Github or something for those interested in trying the FTDI route. Cudos to @forestcaver who proposed it for the first time in this thread, and gave some valuable directions.

Now if only it would be possible to use keyboard and Grid at the same time) But I will save that for another day on another thread.

2 Likes

If you could branch and give some instructions/pictures that would be most helpful.
If possible upload teensy hex with changes. Would be excellent!

5 Likes

+1 for instructions please:)

Also, does that means that it will work now with other modules as well and/or with norns without a patch?

I don’t have other modules, only Teletype, so I can’t tell you. In theory it should behave like the stock Grid, but in practice there could be hurdles, which are hard to foresee without trying.

The basic idea is that you finish the Grid as published, then add a second USB port to it, which will be used for communication, while the original USB port is used for power, debugging and firmware updates. Try to get a “FTDI Breakout board” with an official 231 or 232 FTDI chip, ideally from some company such as Sparkfun or Watterott, not Chinese copies. I was using:

Where I live, it would cost like $12. It is important that it is either sold for 3.3V, or has a switch which allows it to be set to 3.3V (don’t forget to do that)

Then download the FT PROG tool available on the FTDI website and connect the breakout to your computer. I think for this step you need a Windows PC, no idea if the tool is available for Mac or Linux. Press “Devices”. The adapter should show. There a several pages of configuration. Open the section “USB device descriptor”, chose the option “Custom VID/PID”, and make sure that VID and PID are ID 0403 and 6001 respectively. If not, change them, and then chose “Program device” from the context menu or toolbar (if you bought some official board, VID should already be correct, but the PIDs for adapters vary, if it is 6015, it needs to be changed to 6001). That step should save the changes permanently.

Next go to the USB String descriptors page, change the manufacturer name there to “monome”, and program.
Look for the “serial number” page, turn off auto-generation of the serial number (uncheck checkbox), and enter a number like m00000000. The first small “m” is important here. Program.

Take out the adapter, plug it in again, press again on “Devices” in FTP PROG, and check that everything was saved correctly. You can also use tools like USBDeview for checking USB properties.

One of my adapters, which was very cheap, would support every step above, but not remember the changes. If the same happens to you, you need to try another adapter.

Now solder the breakout box to the Teensy in the DIY Grid, in addition to the existing breakout. I would recommend to just to use jumper wires, so you can remove the breakout box if needed. If you need female or male jumper wires depends on your exact model, there are those with male and female sockets. You need three cables. Connect GND to GND, RX to TX1, TX to RX1. (On some adapters it says RXI and TXO, those are the same connections). DTR, CTS and VCC don’t need to be connected.

Later you might want to integrate this second port in the Grid.

Now open the Neotrellis Grid Teensy firmware “neotrellis_monome_teensy” in the Arduino IDE.
In the first tab, look for Serial.begin(115200); and add a Serial1.begin(57600); under it.

Search and replace Serial. with Serial1. in all open tabs, except for the debug tab.

In MonomeSerialDevice.cpp look for the lines

Serial1.write((uint8_t)0x00); // action: response, 0x00 = system
Serial1.write((uint8_t)0x01); // section id, 1 = led-grid, 2 = key-grid, 5 = encoder/arc	## NEED devSect variable
Serial1.write((uint8_t)numQuads);   // one Quad is 64 buttons

If you have a version of the firmware, were there only those three lines, you need to duplicate them, so that you have six Serial1.write calls. (You might want to change 0x01 to 0x02 in the second block, but it probably does not play a role.)

Finally look for the file C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3\serial1.c - on Macs and Linux it should also be placed in the hardware folder next to the Arduino libraries folder (I am assuming that the IDE is already setup for the Teensy, on that you will find instructions elsewhere)

Look for the line
#define SERIAL1_RX_BUFFER_SIZE 64
and replace it with
#define SERIAL1_RX_BUFFER_SIZE 256

Now, go back to the IDE and load the modified firmware on the Teensy.
Write some simple Teletype Grid script in your Teletype, such as described in “Teletype Grid Studies”. Use ALT-G to verify if the grid inside the Teletype is set up correctly.
Start up the grid and connect the breakout to the Teletype. Voila.

5 Likes

Hi! Thanks a lot for sharing this work and detailed info!
I have a few diy grids that are going to be very happy being able to talk to my teletypes!
Would something like this work?

https://www.digikey.es/product-detail/es/sparkfun-electronics/DEV-09873/1568-1104-ND/5318746?utm_adgroup=Integrated%20Circuits&utm_source=google&utm_medium=cpc&utm_campaign=Shopping_Product_All%20Products&utm_term=&productid=5318746&gclid=CjwKCAjww5r8BRB6EiwArcckCxTPJBjy21BQFptEK6hKBzUSKHPQ52Z-AG2yUs1trNtjmtutj11y6xoChmwQAvD_BwE#images

Gracias!

In theory yes, I bought one of those on Mouser and reprogrammed it successfully. I then had an issue, that it wouldn’t work in Windows anymore, neither for reprogramming, nor for connecting a console to it. No idea why. Probably my mistake, like entering wrong settings. Try it. I ended up using the one by Watterott GmbH. In general, the board should not make much of a difference, as long as it has a legit FTDI chip.

Thanks for the detailed write up. I just found an FTDI breakout lying around in my office (it’s probably 10 years old by now), so I may give this a try.

Also, you can program FTDI chips on a mac. I used this technique to flash the eeprom on my DIY arc.

1 Like

Ah, great, I might try this to salvage the Sparkfun breakout, which wouldn’t show up in the FT PROG anymore.

On another issue: how do you people use (DIY) Arc and (DIY) Grid together?

Looking at the mext protocol, I guess it should be possible to connect them both to one host device. If one would replace the Teensy 3.2 in the DIY Grid by a 3.6 (which is slightly bigger than 4.0, but allows two breakouts) one would get a USB host port on the Grid, to which one could connect the Arc, and then relay its messages to the Grid’s host device.

And then control for example, one Teletype, without an Ansible (the hardware of the latter has not been released as DIY to my knowledge).

That said, it appears that Teletype does not yet support the arc directly on its frontend, but the libavr32 library, which it uses for the USB communication, does. So it should not be hard to add some ops.

Another possibility would be to connect a keyboard to the Grid, to avoid the swapping required by Teletype. However, this would require extending the mext protocol by a keyboard-keyPress message, which IMHO shouldn’t be hard.

the correct way would be to implement usb hub support in libavr32 as a start. this has been discussed for years, it’s just not very fun and nobody has yet weighed the payoff as worth the effort

any hacks with device chaining would work, but these will not be accepted into the main codebase. you’re welcome to maintain a fork of course

1 Like

Yes, I understand the urge for a “correct design”, but if there is a choice between a useful feature not being implemented at all, because the “correct design” requires too much expert knowledge and boring work, or getting it all working without much effort in two evenings (as with connecting the DIY Grid to the Teletype via a second USB port), I would happily chose the latter, even if it means to fork or create a patch. If there is interest, people will use it anyway, and it might be cleaned up and considered for inclusion later.

Another way to solve these three issues would be something like the following- and one wouldn’t even have to open the Grid to connect it to the Teletype: