#788

Ok, will check, could you please post the Debug output coming from the first port (Serial)?

#789

To be honest, everything points to the suspicion that your runtime baud rate switch code does not work, at least not in this situation. This would totally lead to the scenario you describe, because a grid still at 115200 wouldn’t get the greeting, or think it’s Chinese. The TT would keep sending 0x00 (or 0x01) ad infinitum.

I would first check what happens if you set the speed to 57600 initially.

Also you might try

Serial1.flush() 
Serial1.begin(57600);

In the switch. You could also check report like this one: https://forum.pjrc.com/threads/59201-Change-baud-rate-end()-begin()-also-needs-clear()

Serial1.end();
Serial1.begin(57600);
Serial1.clear();

Also, I would very much recommend to connect the USB cable to the FTDI adapter not to the Teletype, but to your PC and see what happens when you imitate a TT. First send it a 0 hex value (0x00 byte), you can do that easily using Serial Port Monitor, at 57.600, and at 115.200 baud. There must be six bytes back. If that works, send a 1 hex value (0x01 byte), and check, if you get 32 bytes back.

#790

I added a Serial1.clear this afternoon. I’ll try your suggestions tomorrow. A reminder that my code seems to works great if I power the USB first, then connect the FTDI. Thanks for thinking about this!

#791
  1. The FTDI chip on board of the adapter is probably only powered by USB, not by the Teensy via VCC. VCC is supposed to be an output.

In other words, when the Grid is starting and you connect FTDI to TT later, the FTDI chip activates only AFTER the grids startup sequence, so that can make a difference.

  1. Ok, also please remind us which FTDI adapter you are using. Could it be that is simply not coping with the load created by the Neotrellis LED boards starting up, and malfunctioning? Maybe worth measuring Ampere and comparing to the datasheet. Just a thought. That was actually the reason why I did not connect the VCC of my FTDI board. Those LEDs can draw a whole lot, but on the other hand, they are not all switched on during startup, usually.

  2. I assume you set the FTDI to 3.3V line level? In this mode, VCC still outputs 5V? Can you set line and VCC level separately? Because the Teensy would obviously prefer to talk 3.3.

#792

I used this: https://www.adafruit.com/product/284

Yes - of course VCC is an output - I am using it to power the Teensy. The ‘friend’ defaults to 3.3V line level, with VCC at 5V (you can switch all these things on the back of the board). When I power the Teensy separately, I disconnect the VCC-VUSB jumper.

The FTDI friend seems fine with the Neotrellis LED current load - the thing works great, without a hitch with my norns shield. There is a brief flurry of RX TX LED lights, and then a nice regular red light pulse as ‘awake’ script sends LED info. The FTDI LED freakout from the TT occurs in the first 2 seconds of attaching it to the TT - at least 10 seconds before any LED’s light up. The problem really seems to be a boot sequence issue.

#793

Wow, looks like a great board… ok. There is no way to solve this but to check what the board receives, and what it sends back. First step is to get the dump which it sends out on the first port (Serial.) during startup, second is to connect the PC instead of the Teletype and simulate it. Unfortunately, I am behind schedule with work, so probably cannot put a hand on it in the next few days.

#794

I think you’re right. Is there a freeware serial port monitor? The 14 day trial of the software you recommended doesn’t allow serial sends.

#795

Actually, I used the trial version, and it worked fine for this purpose. I sends bytes without problem, but you first need to connect to the port using the menus (the UI takes a bit to get used to - it looks like it is connected, when in fact it does not automatically connect). I don’t think you need the paid extra functions.

You can always use free terminal tools like TeraTerm, but one would need to check how to easily send and read hex values in them (for getting the debug output out of port 1, TeraTerm is fine, or Arduino Serial Monitor). But if you find alternatives, let us know, I am sure there are.

(To check, whether the monitor is working, connect RX to TX of the FTDI and you should get echo back)

#796

You could try the command line screen program which is on Linux/mac. I believe you invoke it like this: screen /dev/cu.usbserial 57600, where you obviously should change the device path and baud rate as desired

#797

OK - progress. First I connected my FTDI friend to an FTDI USB cable (also adafruit) and looked at the TT output - a whole bunch of zeros. Sent it a hex 0 1 2 0 2 2 and it shut up.

So I went back and added the six bytes the end of MonomeSerialDevice::initialize()

And I went through and made sure I used Serial1.end() and Serial1.clear() at the right spots. Also made the default Baud rate 57600.

Now, when I plug into norns, and select the right baud rate - it works fine. Good - I didn’t lose ground. When I plug into TT - once the grid wakes up - the six bytes are sent and the screaming 0,0,0,0,0,0,0,0,0 output of the TT stops. But… the RX red LED never goes back on - if I push buttons the green one flashes, but the TT isn’t seeing these button presses either. So - the Serial1 connection must be good. Is there something else after the first 6 bytes required for the wakeup handshake process?

I uploaded my current code revision to my github. Switching baud rates on the norns doesn’t cause any problems, other than the norns being deaf to the grid if you choose the wrong one. But you can switch it right back and you’re back in business. The baud-switching seems OK.

2 Likes
#798

Excellent

Yes. The TT should reply to the six bytes with a 0x01 (1) byte
And it expects to receive a 32 byte ID back, as you can see in the Teensy’s code MonomeSerialDevice.cpp, line 252: https://github.com/mcleinn/neotrellis-monome-for-teletype-via-ftdi/blob/master/neotrellis_monome_teensy/MonomeSerialDevice.cpp
It probably will take any bytes, but I didn’t research this further. I’d try 32 space signs.

What I didn’t really get is why the processSerial routine is not handling the zero (and then, one) as soon as the grid gets active. I guess it would be worth looking into that, after duplicating the existing code.

“if I push buttons the green one flashes, but the TT isn’t seeing these button presses either.”
Did you load any specific scene in the TT to test button presses?

#799

I added the ID send routine just after my 6-byte hack. Didn’t help. You’re right that just adding the six bytes on startup isn’t solving the underlying problem.

For testing I have been using one of the grid-scenes you linked to that shows up as ‘DOT2’ listed under pong or something. Pressing buttons makes walls the 3-point line bounces off of. But alas, no line, no walls. When I powered the two boards separately, it worked fine.

Taking a big step backwards, I set up my FTDI-FTDI comms box again and tried to make the TT happy typing in commands.

TT spits out 00’s; I respond with 00 01 02 00 02 02
TT responds wtih a 01 (though sometimes a 00 01)
I send it a hex 01 and then send it a 32 char string ID “01234567890123456789012345678901”
And all is quiet. I can’t wake it up enough to send data every time the TT script moves the grid pixels (which it should).

Clearly something is missing!

1 Like
#801

I keep going back to the fact that
a) the code works perfectly with norns, powered over FTDI
b) the code works perfectly if you power up the grid THEN connect the FTDI to the TT.

So - the handshake works fine, just not when the grid and FTDI are both powered by the TT. I dropped the intensity of all the LEDs to make sure it wasn’t a current draw issue - it wasn’t the problem.

So it HAS to be a sequencing issue. I changed the code to hold off all Serial1 comms until the grid is up, and Baud rate selected, but that didn’t do it either. I’m sure this is possible…

Anyone know what a ‘valid monome grid ID is?’ The one that I should send when TT asks for it with a 0x01?

#802

The reference once more: https://monome.org/docs/serialosc/serial.txt

“device ID string” ? I believe it can be anything and I think it’s “monome” for a stock grid (or you could try “monome 128”). I thought it needs to be a specific length. In my code it’s set to 32 - which I’m confused about now looking back at the reference.

@tehn Did this change in your recent update to serial.txt? I thought device ID was 32 previously?

pattern:	/sys/id s[64]
desc:		device ID string
serial:		[0x01, s[64]]
args:		s = id string, 64 chars

EDIT - apologies as I think I’m confused. Looked at github changes and that’s the same as it’s always been. Not sure I understand why it’s d[64] there tho.

@Gerald_Stevens do you think these delays in libavr32 could be involved?

#803

The .cpp code pads the ID length to 32 with extra zeros. I started using ‘monome’, with a bunch of extra zeros while talking directly with the TTbut still haven’t found a magic string that wakes it up.

That said, it wakes up happy if the grid is initialized first, so all these ID details may be moot.

1 Like
#804

¯_(ツ)_/¯

I keep wondering if this is involved somehow

// ftdi sends 2 status bytes at top of each packet.
// seems to usually be 0x31 0x60
#define FTDI_STATUS_BYTES 2

Really need to get a logic analyzer in between the TT and the FTDI board.

1 Like
#805

Yeah - I soldered up some extra pins to monitor. Here are three examples of what the Teensy is sending after I select a baud rate - what are the 20 02 06’s? Ah… maybe that’s my final grid press. So it definitely hangs on the ID response.

[01/11/2020 13:42:30] Read data (COM7)
20 01 06 00 01 02 00 01 02 00 01 02 00 01 02 01 …
6d 6f 6e 6f 6d 65 00 00 00 00 00 00 00 00 00 00 monome…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …

[01/11/2020 13:43:37] Read data (COM7)
00 01 02 00 01 02 20 01 06 00 01 02 00 01 02 01 … …
6d 6f 6e 6f 6d 65 00 00 00 00 00 00 00 00 00 00 monome…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
[01/11/2020 13:44:11] Read data (COM7)

[01/11/2020 13:44:32] Read data (COM7)
00 01 02 00 01 02 20 02 06 00 01 02 00 01 02 01 … …
6d 6f 6e 6f 6d 65 00 00 00 00 00 00 00 00 00 00 monome…
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …
[01/11/2020 13:44:48] - Close port COM7

#806

yep, followed all the instructions. I can’t see grids from my norns shield

#807

The device fix/hack may need an adjustment after the last system update.

I’ll test this later today.

#808

IMHO there is only one point where it could be hanging in the libavr32 code. Just look at the relevant file in https://github.com/monome/libavr32/blob/main/src/monome.c, function setup_mext(), lines 630-655.

It indeed does not require any specific ID to connect. There is a check, whether the second byte of the ID is “k” in line 641, but it is not a requirement for the connection, it just disables “vari” mode. I compared this to the original grid firmware, which has been posted above.

The original grid sends “mk” as ID, while the DIY grid sends “neo-monome”. Both pad the rest to fill 32 byte: https://github.com/monome/mk/blob/master/firmware/default/mk.c, line 253, lines 391-394

The only place where TT could be locked seems to be the “busy” loop at 635-637 in monome.c.

TT is waiting for ftdi_rx_busy() to become false. To see when this happens, we need to go to https://github.com/monome/libavr32/blob/main/src/usb/ftdi/ftdi.c. There you see that this function returns false when the global variable rxBusy is set to false. The only place where this can happen is line 60 of the same file. So we need to see why it does not get there.

This function (ftdi_rx_done) indeed uses the constant @okyeron mentions, the FTDI_STATUS_BYTES. But it does not lock in itself. It is supplied as a callback function in line 91. In the same line, we have the parameter FTDI_RX_BUF_SIZE, which is 64 - not 32.

We can go deeper from there in the USB driver, https://github.com/monome/libavr32/blob/master/asf/avr32/drivers/usbb/usbb_host.c, line 1601, but I think the theme is the same: It could have something to do with the 32 vs 64 stuff. Apparently, USB packets are usually 64 byte, including 2 status byte: https://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04smalldataend.htm

So maybe the USB FTDI packet with the ID is not actually sent to the TT by the FTDI adapter, for some reason, at least in the mode we are in when the FTDI is switched on first. Try to pad the ID to at least 64 temporarily, try to add a Serial1.flush() to force send, maybe try to send the ID multiple times?

You could be bold and solve the gordic knot by modifying the above mentioned part of TT’s firmware, like removing the ID request with the busy loop etc. completely, and see how it goes. Or changing the FTDI_STATUS_BYTES constant. That could help pinpointing the issue. Also, you might activate the TT’s debug output in monome.c and ftdi.c, which is commented out, and read it during boot.