in a good way!

To me.

just in case, hehe. I actually really want a crows, but cant justify it right know

16n could act as an i2c translator for you (taking usbmidi from norns and spitting out i2c).

norns -> 16n -> ER-301

yes.

still, getting any of those are a bit to much just to send i2c to the 301.

But maybe it would feel unfair to the ones who got an prebuilt norns to add i2c to the diy version, forcing the ones who paid the most to pay even more for i2c

I wouldn’t write off implementing i2c communication as a trivial or simple task. You’re probably unlikely to get a diy norns only function developed unless you pick it up yourself.

On the other hand, there are some folks actively working on getting communication set up between crow and the er-301. As far as latency goes, I’m not sure that would be an issue to worry about at this point (we will know soon enough).

1 Like

ye, it seems very hard from my perspective. But i want to push a “less adapters” philosophy

i would advocate for the creation/use of a very tiny/simple usb-i2c converter, so it could be used with any usb host (ie even computers with macos/etc)

in fact, there’s probably a linux driver for this: https://www.adafruit.com/product/2264

add a 3.5mm stereo jack— and then some matron/lua code.

7 Likes

There is indeed. I don’t know enough to say more, but “Virtual Com Port” drivers appear to be already in the kernel (“All FTDI devices now supported in Ubuntu 11.10, kernel 3.0.0-19”).

rad.

one advantage of this is being able to use a long USB cable which has “balanced” data lines, so “immune” to noise, whereas the i2c cable length should be kept very short. (quotes because this is a semi-accurate simplification)

1 Like

This issue should also be resolved.
Sounds like a great idea!

I wouldn’t assume they use the same driver, would be good to check device IDs.

Also it seems there’s a USB to header stick from FTDI themselves called C232HM (but 3,5mm is a bit nicer)

Yeah, and D2XX drivers are also available for Linux if you want to go that way.

Well - I was linking to the drivers for the specific chip on the board.

Ethernet enabled! This looks like fun. Been looking for a double Norns without the price of two of those beautiful enclosures.

1 Like

It seems to be a bit more complex, no driver in the kernel, no sources, not sure about the license
https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ftdichip.com/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf&ved=2ahUKEwiPmuPyzpPlAhXGZlAKHSPlAd8QFjABegQIBhAG&usg=AOvVaw1ku_rsZX-B4pt06TtyIft6&cshid=1570776686973

Also it has the same vendor and device ID as the UART FTDI devices meaning it collides and will need udev rules which might or might not work depending on if there’s another unique identifier present.

Tbh it’s not very clear to me from all the docs if/why we need the d2xx driver or if the UART one will also work.

Maybe something like this is a better choice https://github.com/harbaum/I2C-Tiny-USB/blob/master/digispark/README.md support for that is available in the kernel.

1 Like

understood, I thought I’d missed something.

something custom based on digispark is highly doable: simple, cheap, supported.

1 Like

Oooh… I think I have a handful of Digisparks. Will investigate.

My only concern, skimming that, is that the digispark and micronucleus boards want to run everything at 5V, rather than 3.3V. Is that going to be an issue for 3.3V I2C devices further down the line?

Other than that, it isn’t so hard to make a digispark based device, with a USB socket (rather than male tabs) - for the suggested “long USB cable, short I2C cable” strategy, and then a 3.5mm stereo jack at the other end conforming to the tip-SDA, ring-SCL spec I seem to be perpetuating).

oh, look, a level-shifting I2C datasheet.

2 Likes

i believe most i2c devices should be 5v resistant?

(also, should we start a new thread for this prospective i2c utility device?)

3 Likes

yes please, I was thinking of doing that earlier.

1 Like