#707

fyi norns has a usb hub, so this is really only a solution for libavr32 systems.

keep in mind that power management is going to need attention.

a solution i (sortof) like is a 2hp module that is a usb host and communicates to tt/etc via ii. this way you could just stack up more modules.

1 Like
#708

True, but that solution would again need all sorts of (relatively deep) driver additions to the Teletype, that is, rewriting of libavr32. Then one could just as well add hub support etc. I think I will personally just go via a Teensy 3.6 in the Grid, and see how it works.

#709

Thanks a LOT to @mcleinn for figuring out / ironing out the issues - will try out this during the coming days. And sorry for adding to the general confusion / noise before in the thread, posted a silly idea before going to sleep here, and only got back to my computer now to see it was as silly as I thought…

#710

no, it wouldn’t require rewriting— it’d simply need an additional layer i2c abstraction, which in the long term would be an extensible, interesting addition to the ecosystem with implications beyond just fulfilling the immediate desire of two-at-once.

adding usb hub support would be substantially more difficult, not to mention that unless you use a powered hub (which will be an ugly hack) you’ll have power issues (tt has limited delivery).

this is just to say, i’m interested in elegant, extensible, sustainable solutions. (though i empathize with your aim to just get it working asap.)

1 Like
#711

Yes, you’re probably right, it’s a good plan. With rewriting I mostly thought of all the code in libavr32/monome.c, which does the low level interfacing to mext protocol (handshake & encoding the LED maps). If you connect the Grid via I2C one would need to rewrite all the functions there for I2C, because at the moment it is extensively making use of FTDI functions. But I agree that this would be trivial in comparison to adding CDC or hub code, especially if one limits the I2C support only to mext devices (a lot of code in monome.c is for 40h and series protocol).

#712

One still would need a USB host, which supports a number of device classes. At the very least FTDI for the stock Monome devices… but if we want to support the DIY grid natively, and add keyboard support, then we would FTDI, HID and CDC. I don’t think one Raspi per 2HP module is a good idea. Do you have something in mind?

Short research yielded something like the FTDI VNC-2, but it bridges to SPI instead of I2C.

We could either add am SPI-to-I2C bridge, such as SC18IS602B.

Or we could use the VNC-2 to output serially (there are opensource VNC-2 firmwares for HID, FT232 and CDC host to UART), and then use a serial to I2C bridge.

#713

Teensy 3.6 (and 4.x I believe)

@scanner_darkly and I built a multi-protocol* translation device called enigma a year or two ago (using teensy 3.6), but it hasnt gotten beyond the prototype stage.

EDIT: * protocols being monome serial, MIDI, HID, and i2c

EDIT #2: example of enigma being an “app host” to grid/arc/midi https://www.instagram.com/p/BtHge1khovg/

1 Like
#714

stm32 can do all of this easily, with low power.

#715

Yes, that brings me back to my original idea to put the Teensy 3.6 in the Grid, and use it as a crude hub for a keyboard and Arc. (3.6 is better here than 4.0, because 4.0 does not allow to put in a breakout as alternative to its USB slave port, which we need to power and flash the Grid)

As a next step, I could connect the Grid Teensy’s I2C pins to a 3.5 stereo jack, and from there throw a I2C-TRS-cable to the Teletype via my TXb expander, fullfilling the definition of a “fiendishly wonderful Frankenstein machine” (Pusherman)

Based on that, add a I2C layer for mext (and keyboard), and then @tehn could put the Teensy 3.6 into a separate 2HP module, as he suggested

#717

If there are ready opensource solutions for CDC/FTDI/HID to I2C bridges, a bare stm32 would indeed be an option, otherwise it will be probably easier to use the Teensyduino platform, or the FTDI VNC-2. Because if we need to do low level STM32 coding, we could just as well finish the AVR code, I guess.

…or we could simply wait until Ansible is completely DIY’yed, that would also fulfill the task, partly. Do you know whether this is to be expected? I can see the firmware source, but not the hardware files.

#718

mcleinn, firstly, thank you.
Secondly, is it possible to export a hex file with changes made to the code for use with the Teensy loader?
This might save a whole bunch of further thread posts of people asking for help with code. :slight_smile:

#719

my 2c:

i’d estimate the difficulty a little differently. yes, there are many calls to FTDI I/O functions in monome.c (so yeah that source is not just a parser but is also driving I/O logic.) but it is not complicated to refactor these, and its necessary regardless of what other I/O you want to add.

there are basically 5 I/O functions involved:

  • read
  • write
  • busy?
  • connected?
  • bytes available?

these would of course have to be refactored in some way for other I/O channels. [in a nutshell, there needs to be a device data structure used by all these functions, which contains FPs to I/O routines.) but that is just a mechanical change, it doesn’t really require any new problem solving.

CDC i’d say is the simplest since its straightforward to add a new USB host driver. @okyeron has this most of the way there but i think could use some assistance with refactoring monome.h/.c.

i2c is pretty much equally easy.

adding hub support to libavr32 is way, way harder. it’s not even really feasible at all with the atmel avr32 middleware stack that we are using. would require extensive and deep rewrites with an expert understanding of the low-level USB spec.

(ok, i don’t actually think i have useful opinions on these “ecosystem” ideas.)

1 Like
#720

I wonder if the FTDI board could replace the extra power jack in the neogrid? Would need to be able to handle high current. Of course you’d want to be able to select a dim mode so the teletype doesn’t have a heart attack. But my palette selector code does that on bootup.

1 Like
#721

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

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

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

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

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

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.

#727

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.