#41

thanks, seems so:

USB LS/FS OTG  controller  with  transceiver
USB LS/FS/HS OTG controller with transceiver

its unclear to me whether the teensy stack supports this kind of operation yet though, seems like quite a challenge for PJRC:

pjrc forum thread
…
some KS updates:

library still seems pretty raw - did you use it?

#42

Those links are a bit out of date I think. There were some updates as of this summer.

The library is working well for me in initial testing. Supports usb hubs as well.

Note - I did need to update Arduino and teensyduino to most recent releases to get the most current usbhost_t36 library.

2 Likes
#43

Great.
The SAMD21 is cheap enough to use it instead of a MAX3420. Depending on the amout of Flash you want you can get it for 1USD.
If you want to have a M4 core you can have a SAMD21 just for USB Host and the M4 for debugging + device + Audio with Floating Point support.
The M4F > SAMD51 can in this case remotely flash the SAMD21 with new firmware. I am currently working on a project where we use 10+ SAMD21 as IO Expanders for LEDs.

Still Teensy is probably easier to work with.

But doing a custom board with a SAMD21 for USB-Host & SAMD51 for Device wouldn’t be too much effort i think. I can work on that if you are interested.

About my post before. The FPGA would also be able todo USB… but thats nothing i have experience with. There is a Bootloader for the FPGA we are using todo USB - so far only device mode as i know: https://github.com/tinyfpga/TinyFPGA-Bootloader

2 Likes
#44

cool.

well for various reasons i kind of like the dual-component approach better. even if the teensy host lib is super solid and the prototyping cost is slightly lower, having the roles split makes it a little more flexible w/r/t component choice for other DIY versions or custom boards.

there just don’t seem to be many MCUs that have dual physical USB interfaces and they are gonna require specific custom libraries like the teensy.

that said, not a big deal to support the same API on both platforms.

for this application in particular, it even seems like 2x samd21 would be sufficient; i wouldn’t really feel the lack of an FPU.

with an m4 on the device role, it seems to naturally open the door to doing more processing / sequencing / synthesis, which begs for more I/O and a whole slew of functional decisions.

OTOH , m4 makes lua integration easier.

next week i’m picking up an assortment of the adafruit Feather boards and adapters so should be able to POC any combination of samd51/samd21. in the meantime i have been poking at a super-minimal eLua build for the M0 using integer math (just the VM and interpreter, no modules.) maybe the timing will line up just right.

i have a couple of teensy 3.6s, but in the wrong part of the country. maybe i will pick up another one.

hm, maybe for next step!

1 Like
#45

@zebra how are you doing with your experiments?

We did a first run of our SAMD51 + ICE40UP5K FPGA boards last week.
[https://github.com/dadamachines/doppler-software]
Could send you one if you want.
Trying to get more documentation on those out step by step.

50310010_601634950309812_240177474590212096_n
50310010_601634950309812_240177474590212096_n.jpg1512×1134 136 KB

5 Likes
#46

now this is the solution we’ve been looking for… :laughing:

3 Likes
#47

Hi !

I’m french and I have some difficulties to understand all your conversation.

Did you create a dongle for the monome grid that can enable the abiility to use it as a midi controller by itself ?

What can I do to have a device like this ?

(so tired of using a computer)

2 Likes