pleriche
Posts: 90
Joined: Mon Oct 14, 2013 8:44 am

Co-existing devices on i2c bus

Mon Nov 19, 2018 12:27 pm

About 5 years ago I built a Pi midi interface around a PIC microcontroller, using I2C to communicate with a user-space Python program on the Pi, running Wheezy. This was working fine until a month or two ago.

Last Summer I built a Mk II version using a PIC with more pins to allow me to include functionality for an intelligent Pi power button. I also added a socket for a DS1307 RTC on the same I2C bus.

I can still play midi files, but if I try to record a performance the midi packets as received by the Python program are scrambled after the first few.

I get exactly the same with 2 different midi instruments, with both the Mk I and Mk II midi interfaces and with several different Raspberry Pis, and I've tried a privious version of the Python program. Unfortunately I'm not sure exactly when it broke or the sequence of things I've tried otherwise I might have the answer.

I did have a short to ground in the midi-in plug on the MK II. Midi is a robust current source so unlikely I could have blown the midi out port on both instruments. But on one of the instruments I set local echo off and plugged in a midi loopback cable which worked, so eliminating that as a possibility.

But I'm wondering if the RTC is to blame, maybe not playing well with my Python program using the same I2C bus, as getting the RTC to work under Wheezy was probably the last thing I did. It doesn't seem likely as I still get the fault with a Wheezy system that has never had an RTC configured and hasn't actually been updated for a long time, as well as with a Jessie system.

Any constructive ideas welcome.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 8444
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Co-existing devices on i2c bus

Tue Nov 20, 2018 1:32 pm

An RTC should only be polled fairly infrequently unless you are consciously updating/reading it, and unless it happened to be at a particularly critical moment in your MIDI stream then you probably won't notice.
I2C runs at 100kHz or higher (the peripheral supports 400kHz happily, and potentially 1MHz). MIDI runs at 31250baud. The RTC transaction would typically be 7 bytes at 10bits/transaction + address, so 0.7ms.

What is more likely tripping you up is the I2C access patterns. Between Wheezy and Jessie (IIRC) the I2C kernel driver switched from being the downstream i2c-bcm2708 driver to the mainline i2c-bcm2835 driver. They behave slightly differently with regard repeated starts and combining transactions, both of which hit write/read transactions but not write only.
You can try reverting to the old driver by adding "dtoverlay=i2c1-bcm2708,combine=1" to /boot/config.txt. If that fixes it then have a search and read through the various discussions on repeated starts. Ideally you'd want to update your PIC code rather requiring dropping back to the old kernel driver.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

pleriche
Posts: 90
Joined: Mon Oct 14, 2013 8:44 am

Re: Co-existing devices on i2c bus

Tue Nov 20, 2018 8:50 pm

Thank you 6by9 - I'll bear that in mind when I get around to upgrading to Stretch.

As always, when you've proved the fault can't exist and yet it's mocking you to your face, the thing to do is to go back to the start and recheck everything. I went back to my Mk I version running under an ancient Wheezy build, reseated the PIC and opt-isolator in their sockets and that now works. It also works with the very slightly more up to date Wheezy system I've always used it on. So now I have a working baseline - a big step forward. But the Mk II still doesn't, in spite of reseating the ICs, buzzing through the circuit for faults, and trying several old versions of the firmware. Very strange indeed that Mk I and II seemed to show the same symptoms if Mk I was just a bad contact - unless it's all down to the phases of the moon.

I'll report back when I've sorted it for the sake of anyone who's following this, but if you don't hear from me please send get-well cards c/o the nearest lunatic asylum.

pleriche
Posts: 90
Joined: Mon Oct 14, 2013 8:44 am

Re: Co-existing devices on i2c bus

Fri Nov 23, 2018 10:42 am

A software problem.

My Systems Architect (me) didn't appreciate the complexity of his proposed solution and failed to properly specify the implementation. My Project Manager (me) was hassling my Principal Programmer over missed milestones. My Principal Programmer (me) frankly wasn't up to the job and really ought to stop pretending he's any good at coding. Meanwhile, my QA Department (me) was totally asleep at the wheel and followed a totally inadequate test plan. I now have to send in my Red Team (me) assisted by my Special Troubleshooter (my cat) to track down the bug and sort out this whole mess.

I rebuilt the Mk I firmware for the PIC (with more pins) used in Mk II and it worked fine. It looks like regularly polling the intelligent Pi power button state machine (a reimplementation of an ATTiny version) is somehow interfering with the midi sequencer record function. I would have saved a LOT of time if I'd simply added an ATTiny to the original solution to handle the extra functionality.

User avatar
davidcoton
Posts: 4778
Joined: Mon Sep 01, 2014 2:37 pm
Location: Cambridge, UK
Contact: Website

Re: Co-existing devices on i2c bus

Fri Nov 23, 2018 5:01 pm

pleriche wrote:
Fri Nov 23, 2018 10:42 am
assisted by my Special Troubleshooter (my cat) to track down the bug
In my experience the only bug that cats can help with is The Case of the Missing Mouse.
And then only if the said cat is not a crinminal mastermind who trades in second hand mice. :roll: :lol:
Signature retired

pleriche
Posts: 90
Joined: Mon Oct 14, 2013 8:44 am

Re: Co-existing devices on i2c bus

Mon Dec 10, 2018 10:50 pm

For the sake of anyone stumbling across this thread in the future, the problem was a very stupid bug (aren't they all?) in my PIC assembly code, the sort you can stare at for hours and not see. (Well, that's my excuse, anyway.)

Return to “Advanced users”