I2C on the SSP

note: this was enabled on the latest SSP update.

IMPORTANT NOTE - proceed totally at your OWN RISK.

connecting I2C can EASILY damage your SSP beyond repair ! the pins can only take 3.3v, if you put in 4v you will FRY it.

using I2C would not be covered by warranty... ( and it'll be pretty obvious that the damage was caused this way)

I have spoken to Bert/Percussa about this... in no uncertain terms, I was told, connecting to any pins directly on the SSP is at your own risk, outside of warranty etc.

IMPORTANT NOTE 2: I take no responsibility for this info - it's your OWN RISK

Im just a user... and also take no responsibility for this info.

one reason Ive not posted anything about this, is I've not tried it yet... due to complications mentioned below.. again, its at your own risk... don't involve me ;)

sorry, for glaring warnings... but the SSP is an expensive instrument to damage. you need to really think hard about if you want to take the risk... and you need to be (very) experienced to even consider it.

---

using I2C3

again before we proceed, Ive not actually used this i2c link yet... I just know the details, and can see its enabled.

you can see its enabled here:

i2cdetect  -l

you will see it.. i2c3 (!) (do not use other i2c channels they are used 'internally')

Bert previously posted the pinouts here

Connection

VOLTAGE: you need to use 3.3v ONLY be very careful, MANY i2c buses are 5 volt this will damage your SSP.

MASTER/SLAVE: the SSP is an I2C master technically it should be able to be used in a multi master setup but Id need to confirm/play with this... and your other I2C devices also need to 'handle' this... if my reading of the specs is correct.

VOLTAGE SUPPLY: whilst there is VDDA for 3.3v , it is NOT designed to have a large current draw... so dont start powering off of it.

SCL/SDL: I am not sure there is a pull-up resistor on these lines, so you will likely need to add one. (untested / unverified)

general note: this is a low level interface, it is NOT designed for 'users' to mess with, rather developers of modules. the I2C pins interface directly to the SoC/CPU... without protection, so its easy to cause damage.

Software

there is currently no 'support' for I2C in software, this means you would need to write a 'module' to access the I2C data, and decide what it should do - this should not be too tricky (assuming you are a developer).

whilst it'd be possible to have a generic i2c module for something simple (e.g controllers). but for many, more complex modules that you'd connect via i2c would need specific code, that would code the 'protocol' the module uses over i2c.

below are just some of my thoughts about using i2c. how i might approach it, and also complications.

Complications

aka why have I (@thetechnobear) not tried it yet ;)

k, I should state one reason Ive not tried - is I don't really have a module that would make use of i2c currently.also given complications below, its kind of 'off putting' to make that 'investment'.

i.e. if I had an ER301, id probably try, but buying one at $$$$, then risking damage to both it and the SSP is kind of not compelling.

(however, I do have some other possibly use-cases... just need to decide if they are 'worth the risk')

a) direction connection as mentioned above, there is 'no protection'.. so get it wrong = black smoke of death.

b) the 3.3v lines are a concern... the issue is i2c does not standardise this, and ive seen many eurorack modules using 5v. so you will have to deal with these voltage levels correctly. it's not 'hard', but get it wrong and you will damage your SSP. given how much I use the SSP this is a large concern for me!

c) master / slave

the SSP is a MASTER on an i2c bus. traditionally, you can only have ONE master on an i2c bus. and you'll find many SoC based modules expect to be the master.

there are various ways around this. but if you already have a master its not going to be plug n' play.

you could either use a master-slave bridge, e.g. I considered a teensy or see if you can get multi master to work but thats added complication.

Approach to solving issues

Teensy I2C bridge module

I (TheTechnobear) have thought about this quite hard... as there are tremendous opportunities, even with risks involved.

If I was to do this, what I would likely do is create a new eurorack module, that would connect 'behind the panel' to the SSP. it'd likely use somthing like a teensy, to interface to the SSP, so the SSP was NOT directly connected to the I2C bus... rather it would be on a 'private bus' to the teensy... so if things when wrong on the main i2c bus, the teensy would blow... not the SSP ;) (of course, the assumption here, is my module IS properly designed !)

so basically :

SSP <-> TeensyI2Cmodule <-> other I2C modules (ER301/Teletype etc)

this also has the advantage that the 'i2c teensy module' would draw power directly from the eurorack 5v line. (or a stepdown from 12v)

then on the software side....

a) write teensy firwmare needs to 'proxy' the SSP private bus to the main eurorack i2c bus. not to tricky but need to be a bit careful of timing.

Advantages of this approach....

a) it protects the SSP the SSP would be connected by a single ribbon cable to the bridge module. and it is ONLY even connected to the bridge module, nothing else directly connects to SSP. so get it right, and there is 'minimal danger'

this is also fairly easy to test, before connecting to a real SSP. (e.g. just check voltages the bridge module is putting on SDA/SCL)

b) power source since its a separate module, we dont need to pull power from SSP... we have the racks power available.

c) bridge panel some have been using TRS jacks to interface i2c modules/units on the front panel, rather than using back panel pins. so this module could provide this option.

d) other opportunities since we are writing the firmware for the teensy... we have quite a lot of 'customisation' options.... e.g. an 'internal' protocol between SSP/teensy bridge, which may provide opportunities.

examples, you could add midi to the bridge module, which could be sent high speed over i2c. add additional, IO (e.g. cv outputs), basically DAC/ADC -> I2C

Create a module... I'd buy it ;)

so yeah, module is REALLY appealing... if it was just software, Id create it today....

but whilst I can do a bit of module building / diy electronics. its not something I have professional experience of, so the risks are very 'concerning'.

I may well create a DIY module for my own use, but Id be reluctant to share this. due to a few simple facts...

there would be a VERY small market ... a small subset of SSP users! this means there is no money to fund it... and it'll take a large amount of time , not only hardware but software (see above) (also Id have costs including buying some I2C eurorack modules)

then even if only ONE SSP was damaged... even by a 'user error'. I'd be held liable for a $2000 module, which is way more than I could ever make selling such a bridge module. ... basically, Id be out of pocket financially, and also all the time investment into the project.

so whilst I may build it, and share SOME details... its unlikely to be a public project.

really the above info is all you need to make your own... and im not sure Id want to go much further. in case, someone had an issue, and decided that Id somehow 'endorsed' this.

again, I repeat...

ALL of the above is YOUR responsiblity to double check and confirm. I take NO RESPONSIBILITY. similarly, I know Percussa also will take no responsibility for any of this.... IT IS ALL AT YOUR OWN RISK