#768

Yes, I tried the baud rate. I’m powering the teensy with VCC. Brown isn’t connected.

#769

Hi all, successfully built the NeoTrellis, just did the ‘test’ on Max from the Github and all is looking fine, when I plug into DIY Norns Shield it doesn’t find Grids, am I missing something, do I need to upload anything extra onto Shield or onto Max?

#770

@cold.solder Scroll down on the github repo page, instructions near the bottom.

#771

OK, the trick is that it only works if you boot the grid with it’s own power, then plug in the FTDI USB board. Any way around this? The grid takes so long to wake up that I don’t think a simple capacitor delay on the FTDI power rail would work.

1 Like
#772

If it’s a ft232rl, could use something like a mic803 and transistor on reset ??? (Or, I guess need to look at the Teensy to see what RST does on boot on the Teensy - cant remember off the top of my head)

#773

@forestcaver RTS and CTS are disconnected from the teensy, should they be?

#774

No need for RTS and CTS on an FT232RL to be connected to the Teensy…

#775

Before were you going USB->FTDI->Teensy? Have you tried using a breakout to where 5V from USB was powering both the FTDI and Teensy simultaneously? I’d be curious if the FTDI breakout had its own funny propagation with the 5V line and turning on the Teensy or if not all FTDI breakouts perform the same. Don’t have hardware to fool with, more so thinking out loud.

#776

So, I added a device baud rate selector button to my palette selector, and you can switch between norns and TT readily! No recompiling the TT code necessary. Also, curiously I can run the grid powered through the FTDI and it doesn’t get confused with the norns. Is there a serial reset FTDI command I could use?

20201025_145102
20201025_1451021960×4032 2.28 MB

3 Likes
#777

@Gerald_Stevens I just got my FTDI today, care to share your code and wiring please?
Thanks a bunch!

1 Like
#778

@thopa I’ll post after work tonight. Wiring is as described on @mcleinn 's page, but with VCC (5V) from FTDI attached to the large VUSB pad on the bottom of the teensy. If you can do that with a 0.1" pin and socket, it is advised since as of right now I have to disconnect the 5V and power the teensy first with its USB B micro jack, THEN connect the FTDI via USB B mini jack to the TT to get TT communicating.

2 Likes
#779

@Gerald_Stevens thanks for the info! looking forward to it, cheers!

#780

Here is my latest. Press the lower left corner and the greyscale intensity selector turns yellow (TT screen color), or leave it white (norns) and then select a palette. To reload the selector press the lower right 3 buttons at once.

3 Likes
#781

OK - more info on the pathology of the neogrid not working when powered by the TT. I was reading up on what the RTS and CTS do, and it seems that they are there for data-flow control “Request to send” and “Clear to send”. When connected to the norns, the CTS is 3.3V, RTS is 0V. When connected to the TT, both CTS and RTS are 3.3V. Strange - they must be normally high since the CTS is an input. I realize neither of these is being used, but am wondering if this is a clue as to different behavior between the two. According to the interwebs, " If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin." I tried Serial1.flush hoping there was a packed buffer, but that didn’t help.

#782

@Gerald_Stevens Sorry, don’t have time to follow the whole thread. For me, the grid needs to be powered on first, and then plugged into the TT, otherwise the TT will freeze until I unplug the grid. That is okay for me, I basically leave the first port of the grid on a USB power plug, and I didn’t research the issue further.

I don’t think the issue is related to flow control, rather the Teletype recognizes a plugged in FTDI-USB device, which won’t answer to its 0x00 greeting with the required six byte sequence. There is a loop in the TT code (libavr32) which stubbornly waits for this sequence, once an FTDI device with the right IDs is recognized (and it will be recognized, as the TT power activates the FTDI chip). At least that explains my case. And it explains why everything works fine, as soon as I remove the (unpowered) grid, power it on and plug it in again.

The TT boots much faster than the current grid firmware, so chances are high that the TT’s 0x00 greeting will be missed by the grid, even if you power on both devices at the same time. To solve the situation, you could add some code to the grid firmware which will assume on startup that a 0x00 message has been received. And proactively send the six byte identification reply.

Secondly, you could try to tell the host that you are not accepting any data until the grid is ready to run. But for this the host (TT) would need to honor the FTDI adapters CTS input (= Teensy’s Serial1 RTS output, high: not ready, low: ready). I am not sure if the TT or FTDI adapter will care, but you can try.

Thirdly, you could detect in the Teensy firmware after startup, whether a host device is connected (by connecting the FTDIs DTR/RTS to an input pin) and send the six byte sequence only in this case. That might be clean coding, but for personal use, I think this is over the top. It is much quicker just to send six bytes via Serial1.Send to the Teensy code at the end of the init sequence. Try 0x00 0x01 0x02 0x00 0x02 0x02 or something.

If you really want to research flow control further, you can activate it for the Teensy’s Serial1, you just need to connect one extra pin and declare it (https://www.pjrc.com/teensy/td_uart.html etc.). I did this initially, to increase communication quality, but it did not make a difference, and I removed it.

By the way, none of my FTDI adapter has RTS output, are you sure about it? It has CTS input and DTR output. RTS/CTS and DTR/DCD are alternative protocols in my eyes. CTS can be connected to some Teensy pin which will serve as RTS for Serial1. DTR output could be connected to the Teensy’s CTS input pin (see link above) or another input pin. But as I wrote above, the flow control is probably not needed, and if at all, one could check the FTDIs DTR output after startup to see if the grid is connected to a host.

Regarding signal levels, in FT_PROG one can inverse signal levels for the various pins. Not sure that is really something one wants to do, though. Good luck

3 Likes
#783

I tried these suggestions (to the best of my ability, this is fairly foreign territory) but they didn’t help. I even connected both RTS and CTS and hooked them to pins 2 and 20 via Serial1attachRts(2) etc. Still can’t seem to make the TT respond. The solid red RX LED on the FTDI friend means the TT is SCREAMING continuously at the FTDI. Norns make this LED blink whenever It lights another grid pixel, but nothing continuous/fast like that. TT sure wants to be heard. Pressing grid buttons makes the green LED light briefly. So close to making this work. If it does, the necessary second jack (required to bypass the teensy 5V polyfuse that causes brownouts) could easily be swapped with this board, and the neogrid could be used with all of the monome hardware, plug and play.

#784

Yes, I didn’t put much hope into the flow control stuff, as you noticed. Did you try to send the initialization sequence back after startup? (If so, can you copy paste it and tell, where exactly?)

Because what you describe sounds like a failed initiation. The TT would scream 0x00 until it gets exactly six bytes from the Grid back. For some reason, the grid does not respond. It obviously cannot respond as long as it boots up, but it should respond, once it is running, if the TT keeps sending the greeting. Could you post your code here, maybe? At least neotrellis_monome_teensy.ino and MonomeSerialDevice.cpp?

Can you check what the TT is actually screaming? I eavesdroped using a second FTDI adapter connected to a PC, and there Tera Term or Serial Port Monitor. Then RX of this adapter to the grid FTDI’s TX (the Teensys RX1). Quite a handy method, you could also use a third adapter to see what the grid is responding, if anything.

General debug output would also be handy, in my code it is sent to the Teensy USB board. You should see that in the Arduino software’s serial console. A copy would be helpful.

A similiar situation would also happen, when the baud rate is set incorrectly.

#785

I cut and pasted the 6 lines into the end of MonomeSerialDevice::initialize() Also tried it right before the massive case structure following identifierSent = Serial1.read(); (this seemd like a bad place to put it since I think it would dump these 6 bytes over and over. If you still have your bonus FTDI monitor setup, it would be easier for you to check the behavior - all you have to do is solder a jumper from VCC to the big square USB 5V pad beneath the teensy next to the jack.

#786

But in this case (when putting it processSerial) the light indicating data sent from the grid to the TT should have gone on, constantly. I think we really need a copy of the code, debug output (you get this from the first port, and it is there for a reason) and maybe pictures of your wiring and details on the FTDI adapter. It is hard to guess into thin air.

My monitor setup is already back in the storage boxes, and I am quite busy with work, not sure when I will find time, especially for taking it apart, soldering etc.

#787

The wiring is the same as yours - but with the VCC to VUSB(Teensy). The code is linked above in post 772 of this thread. I didn’t update the github with the change we’re talking about - since it didn’t work. The constant red LED happens regardless of any changes. The code lets you select baud rate with the lower left button - if the intensity selector is white - norns, yellow, TT.