#591

No - sorry :frowning:
All I’ve done is connect the teensy to the ftdi, flash the ftdi, hack the code on the teensy and have a quick play - not really done much else - I’ve started a new job that has been crazy - any spare time has gone into finishing off a few of my own modules - so this has been parked for ages ! Thanks for the prompt though - I ought to go back and look at it again… (I havent even turned on my soldering iron since May - I think - and that was probably the last time I turned on my modular or Fates !!!)

2 Likes
#592

For a 256 buttons at full brightness, at 60 amp per led, wouldnt you need 15 amp?

Im making an 512 buttons, so I was thinking of 30 amp…?

Extra question.

Is it possible to connect the neotrellis boards to other pins on the arduino uno, rather than analg A4 and A5.? I need them…

#593

I’m not doing full LED brightness, so don’t need that many amps. Depends on your code I guess.

neotrellis connects via i2c pins. Not sure what those are on Arduino Uno… looks it up… so that’s A4/A5 that you mentioned. Don’t think there’s any way around that.

2 Likes
#594

I’ve got my 8x16 board put together and working with the Teensy, no issues on the fates USB plug at brightness 128. Working on the case now.

I’m glad I tested all the NeoTrellis boards individually first because three of the eight I bought from Adafruit were DOA, including the first two that I hooked up so I really thought I was doing something wrong until one finally lit up.

3 Likes
#595

Man, I took at libavr32 and what it would take-I got intimidated real quick. Forest’s idea for an ftdi in between seems like the simplest but in practice I have no idea how to implement it. I’ve read through old posts about how the teensy direct uses a CDC(? I think that’s the right acronym) which would require writing an entirely new driver or at least adding significant amount of code. I’d imagine a lot of the functions that exist in libavr32 could be used but the driver would have to deal with how that communication would go down between the teensy and whatever hardware was hosting.

I know Forest doesn’t have a lot of time to devote to it but I’ve thought about snagging a neotrellis board and seeing if I can get it to talk. I’ve got a spare teensy and ftdi 232 board to play with. It’s easy enough to reprogram the ftdi chip m_prog from ftdi after fooling with that the other day.

#596

i can probably help with pointers to the libavr32 USB stuff if that is helpful.

it is atmel code, which is deep and weird, and then it was somewhat messily adapted. could use a scrub of dead code.

anyway, it is not really too hard to add a driver:

here, we tell usb host stack about the different USB host interfaces:
https://github.com/monome/libavr32/blob/main/conf/conf_usb_host.h#L16

you would add a new interface UHI_CDC or whatever

the driver code itself woud go in a new directory here:
https://github.com/monome/libavr32/tree/main/src/usb

you would mirror the structure of the existing drivers; in particular the configuration header expects a struct like this:
https://github.com/monome/libavr32/blob/main/src/usb/ftdi/uhi_ftdi.h#L18-L23

lets see, looks like we put atmel host interface glue stuff in usb/uhi_foo.h/c and business logic in usb/foo.h/c. in the FTDI case we just keep a static buffer of RX bytes and call the monome serial parsing protocol when there is enough stuff in the buffer:
https://github.com/monome/libavr32/blob/main/src/usb/ftdi/ftdi.c

we strip status bytes by appliying an offset to the rx buf accessor:
https://github.com/monome/libavr32/blob/main/src/usb/ftdi/ftdi.c#L138

so, the BL stuff is straightforward. the protocol stuff is nastier, e.g. these control requests for FTDI on connection:
https://github.com/monome/libavr32/blob/main/src/usb/ftdi/uhi_ftdi.c

i think CDC protocol would be easier to deal with. but it still would probably be better to teack down some atmel demo code than to try and figure it out from first principles and sitting down with the USB spec.

(… to be continued? LMK)

it does seem like writing a new driver for libavr32 would be more efficient than making a new hardware thing, and then having to write drivers for that thing anyways.

3 Likes
#597

I have the bare bones of a CDC thing working in libavr32 - I just dont have the monome functions attached there because I don’t know what I’m doing. :slight_smile:

Perhaps I can chat with you about this in a DM?

EDIT - It’s been awhile but i think my WIP is here: https://github.com/okyeron/libavr32/tree/cdc-work

3 Likes
#598

The m4 seems to have ftdi drivers baked in, would that facilitate getting the neotrellis recognized by a stock norns?

#599

Hmmm.

I have a firmware for the m4 that works.

I’ve not tried it on stock norns (shield) install. Guess I could test that.

TESTING:

>> ttyACM found, but not a crow
dev_list_add: error allocating device data

Still shows up as an ttyACM* device and not ttyUSB* (same as Teensy) and thus will not be recognized as grid.

FWIW - the SAMD chips have USB built into the chip so I’m not sure where you’re getting “FTDI driver baked in” stuff from? Aha… there’s some FTDI drivers bundled with the Windows driver install I guess? but that’s on the computer host side, not the device side.

1 Like
#600

I too am curious. Looks great!

#601

a question about this project, I know grids can’t directly connect to iPads, would this be able to communicate with an iPad over usb?

#602

As a midi controller - probably (adapters like camera connection Kit or whatever is currently used for that). Would require different firmware than what’s described in this thread

Power is the big issue. You’d likely need some kind of power splitter or powered hub.

1 Like
#603

are you all leaving the teensy free floating in the case? as far as i can see theres no easy way to mount the teensy anywhere in the shallower case designs.

also, which is the best case design to get printed from ponoko?

#604

see the last couple pictures here for what my little flexible pcb solution looks like (and also on instagram).

Case design also there on that first link (neotrellis-128-12-cut.ai) is the most recent revision.

1 Like
#605

cool thanks!

does this look right on ponoko? don’t wanna drop $60 only to have it be cut out wrong.

image
image1912×896 167 KB

#606

So yes, that should be OK.

A couple notes/thoughts…

If you order fancier material like matte black, all of the pieces will be cut from that (and may be more expensive). I don’t know if it would be cheaper to make separate orders of the top/bottom from one material and then the others from glossy.

With 3mm material your stack will be 9mm in the middle - Thus use 8mm standoffs and you should be OK.

2 Likes
#607

Argh. I’ve managed to lift a data pad on the bottom of the teensy with some clumsy soldering.

Is there any reason I can’t take the D+ and D- out of the onboard usb slot by cutting open a micro usb cable and have the power run under the board?

#608

Sounds like a reasonable bodge to me.Try it and see?

Worst case, replace the teensy.

1 Like
#609

Question
I have the opportunity to buy an old 128 for 290 euros near me in Italy. Is the walnut one so no varibright. Should i go for that or build the neotrellis one? I already built a fates so I’m not scared about going diy, the thing that scares me is the possible problems with this clone

1 Like
#610

Varibright makes a huge difference for most norns scripts. Some are just not very effective with mono-bright.

Not sure what possible problems you might be expecting. Neotrellis grid works like a champ with Fates.

1 Like