#101

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

#102

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

1 Like
#103

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

understood, I thought Iā€™d missed something.

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

1 Like
#105

Ooohā€¦ I think I have a handful of Digisparks. Will investigate.

#106

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).

#107

oh, look, a level-shifting I2C datasheet.

2 Likes
#108

i believe most i2c devices should be 5v resistant?

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

3 Likes
#109

yes please, I was thinking of doing that earlier.

1 Like
#110

Any chance this could handle MIDI too?

#111

There are USB ports on the Raspberry Pis, so you can plug in any USB to MIDI adapter thatā€™s class compliant.

#112

I believe that query was in regards to the ā€œprospective i2c utility deviceā€

If thatā€™s the case, there is a small midi/i2c swiss army knife device that @scanner_darkly and I are working on, but realistically itā€™ll be the new year before I can get back to the hardware design on this specific project.

4 Likes
#113

Check this Post and this one

#114

Thatā€™s what Iā€™m looking for :wink:

#115

@simonvanderveldt - what raspbian distro do you plan to use for norns shield?

Monome Norns, I believe is based on Stretch.
This means that some software is not available on the raspbian distro. e.g. Pure Data is stuck on 0.47

Fates is based on Buster, which means latest libs and apps, which is very useful.

DIY shield - ?

this descrepancy however has caused me issues releasing Orac (which uses PD 49 features),
its fine on Fates but on the monome norns we dont have the right versions of libs/pd

I could get around the libs issue by building on stretch, and I could build PD 49 on stretch (this is basically what I did for the organelle) ā€¦ but its a bit of a pain, and may potentially cause issues for monome.
(e.g. if monome decide they want to push PD to norns at a later date)

anyway, I wondered if with the DIY shield you plan to take the opportunity to move to Buster, and then Iā€™d assume move the Monome Norns at the same/similar time?

I guess also the rPI4 is an important factor ā€¦ is stretch supporting the rPI4? I assume not?
and I believe the diy shield will support the rPI4?

#116

[ actually i shouldnā€™t speak specifically for the linux folks, i donā€™t know exactly what iā€™m looking at.]

but IIUC the plan is to support rpi4 with a custom buildroot image. we build supercollider &c from source in BR packages and can do the same for PD.

alternatively, i suppose packaging monome-snd driver for buster is not too big a deal.

in the immediate near term seems like building latest PD on stretch is not a problem.

1 Like
#117

Like @zebra already mentioned weā€™re probably going to switch to a buildroot based image

1 Like
#118

Do you have a (very) rough timeline for this?
Eg are we talking a few weeks, or a few months?

#119

Not sure to be honest. We still have several things to figure out and need to make some decisions as well. Itā€™ll also depend on when the final revision of the board is ready, if the buildroot image isnā€™t done by then we might have to fall back to using a raspbian based image.

#120

kā€¦ so worth moving forward then in the meantimeā€¦

whilst pd is trivial to build, its actually released as a number of package on raspbian,

I was on the hunt, for the debian source package files for itā€¦
whilst doing this, I found that debian already manage ā€˜backportsā€™ for stretch for rPI.
(so newer packages that are not in stretch, but taken from future debian releases e.g. buster)

so we could basically download from there, by adding backports to the source list.

deb http://httpredir.debian.org/debian stretch-backports main contrib non-free

full details on how to here

this worked for meā€¦

but perhaps a (better?) alternative is for monome to grab these packages, and place them into the existing monome package repo - this would then be seamless to monome owners, since the source is already present and been using for supercollider etcā€¦
it would also mean the version of pure data that is put on the norns is under monome ā€˜controlā€™, not sure if thats important, if images are going to be moved to build rootā€¦ this might be all ā€˜temporaryā€™.

thoughts?

EDIT:
this is the script I have planned if going the backports direction

#/bin/bash

#need dirmngr for keys
sudo apt-get install dirmngr

#keys for authentication
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E0B11894F66AEC98
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7638D0442B90D010
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8B48AD6246925553

#add stretch-backport source
echo 'deb http://httpredir.debian.org/debian stretch-backports main contrib non-free' | sudo tee -a /etc/apt/sources.list.d/debian-backports.list

#build new package list
sudo apt-get update


#finally install  latest puredata and sub-packages 
sudo apt-get -t stretch-backports install puredata

id then also recompile my other apps with the older version of libcairo.
that should resolve the issues for my use-case.