MIPI, I3C - Page 1
Forum section: electronics / general

author: Electro Fan
author_rank: Super Contributor
timestamp: July 01, 2016, 04:33:22 am
content: http://mipi.org/momentumhttp://www.rtcmagazine.com/articles/view/115288

author: tszaboo
author_rank: Super Contributor
timestamp: July 01, 2016, 11:09:49 am
content: QuoteWe are not supposed top know even what is the physical layer. So you know what? I would not be surprised if none will ever give a damn about this bus.

author: mark03
author_rank: Frequent Contributor
timestamp: July 01, 2016, 10:16:14 pm
content: A quick google suggests this has been in the works for a few years already. Either it will gain acceptance, and become de-facto open, or it will remain closed, and thus largely unused. Seems to me they'd want to publish the full details far and wide, for free, if their goal was rapid adoption. Maybe they can get slightly more $$ out of it by hindering adoption while they milk the early adopters, then open it up later? Apparently it takes an MBA to understand these thingsIn any case, it seems to have nice attributes. I hope they kept complexity as low as possible; preserving backwards compatibility with I2C may have been a mistake in that regard.

author: Lukas
author_rank: Frequent Contributor
timestamp: July 01, 2016, 10:39:26 pm
content: Quote from: NANDBlog on July 01, 2016, 11:09:49 amThe ones who need to know probably know already. MIPI isn't for mere mortals like us. Just take a look at today's smartphones: You won't find public datasheets for any of the key components.

author: andyturk
author_rank: Frequent Contributor
timestamp: July 04, 2016, 03:09:37 am
content: QuoteYeah, like I2C wasn't complicated enough.

author: mark03
author_rank: Frequent Contributor
timestamp: July 05, 2016, 04:14:10 pm
content: Quote from: blueskull on July 04, 2016, 03:15:14 amMIPI is an entire family of standards. The subject of this thread is the MIPI "I3C" sensor interface, not the display or camera interfaces, which are better known. I did a Baidu search but didn't get any hits for that.

author: antti
author_rank: Contributor
timestamp: August 01, 2016, 03:32:11 pm
content: I3C is really very weird, weird that NOTHING has leaked out... most every other MIPI standard has more information in public channels than I3C

author: exmadscientist
author_rank: Frequent Contributor
timestamp: August 02, 2016, 04:49:21 am
content: From everything I can see, it looks like the standard isn't quite finalized yet. No surprise that there's not much out there on a half-baked standard; give it a few months yet and then there'll probably be a lot more.

author: filssavi
author_rank: Frequent Contributor
timestamp: August 02, 2016, 07:51:00 am
content: Even if the standard was finalized and leaked i strongly suspect that it would be utterly useless to us mere mortals (i'm not talking only makers/hobbist but also any EE out of smartphone/tablet/laptop field) since any IC using i3c will be in CSP/BGA 0.3/0.4 ball pitch kind of Package which is a major PITA even with professional soldering (mainly the PCB with such small features tend to be insanely expensive)

author: hans
author_rank: Super Contributor
timestamp: August 02, 2016, 08:26:00 am
content: And thisSo it looks like an I2C interface that is extended to support bus interrupts, so you don't need 8 interrupt inputs for half a dozen MEMS.My assumptions to make that happen would be:- Multi-master bus so slave chips can send interrupt codes to the host when bus is idle- Much higher bitrate (I read 10Mbps throughput) on the bus, so transfer take less time and reduces interrupt code latency to acceptable levels- Possibly replaced pull-up resistors with tri-state transceivers following the protocol, similar to how I2C repeaters operateI think such a standard will only be a success if it is widely adopted, and not specific to NXP parts. Luckily they allowed licensing on the I2C system, although I think Atmel never licensed it and just called it Two-Wire compatible bus instead.

author: technix
author_rank: Super Contributor
timestamp: August 06, 2016, 11:48:55 am
content: Quote from: filssavi on August 02, 2016, 07:51:00 amAnd it would still be PITA to parse through the text. I have tried to understand the SCSI SES-2 I2C protocol and was intended to implement it using an ATmega328P but damn that text is complicated and difficult to understand.

author: MT
author_rank: Super Contributor
timestamp: August 06, 2016, 02:35:59 pm
content: Why is certain things so "deliberately" difficult? Engineers want to show off their ego to other engineers? Look at me, my penis is 3km longwhat about that?.. well my is 4km long, etc! With the mentality of if you dont understand our fantastic solution you dont posses enough intelligence.In my previous life as R/D dude i saw this a lot and worst was freshmen.I was once for a short period involved in a global standards commission, it was my worst engineering experiences of all time, hundredsof people involved from all the big elephants went on and on for years, more and more documentation added for no apparent reason,tons of business political issues. What a drag!

author: antti
author_rank: Contributor
timestamp: August 06, 2016, 02:52:28 pm
content: so True, big ones making big standards so bad that ouch!its much more fun to make standards without the big commitees, doing some at atm.DDRSPI : spi using both clock edges, data on rising edge and "sideband" on falling edgevery easy and simple to implement in any modern FPGA or CPLDRGPIO: Remote GPIO, based on DDRSPI "reflection or mirroring of GPIO input and outputs between two programmable devices"32 parallel bits can easily be updated at more than 1 MHz update rate between two programmable devices, using 3 wires. The logic utilization is really really minimal.

author: filssavi
author_rank: Frequent Contributor
timestamp: August 06, 2016, 03:10:31 pm
content: Quote from: MT on August 06, 2016, 02:35:59 pmI don't know for shure, but the standards are made so deliberately difficult so that only members of the consortium (which have insider's knowledge) can implement them (and sell their implementazione to others)...

author: Kilrah
author_rank: Unknown
timestamp: August 06, 2016, 03:51:32 pm
content: Quote from: MT on August 06, 2016, 02:35:59 pm$.

author: MT
author_rank: Super Contributor
timestamp: August 07, 2016, 11:30:27 am
content: $ in an internal project is not the issue, well yes if there is not a management with sense to stop anyone waste money just because the subject want to bling in front of fellow engineers! $ alone for global standards i doubt is the solely goal, part yes, but if would the completion of the standard close to impossible unless one of the combatants monopolize it (Microsoft).

author: Kilrah
author_rank: Unknown
timestamp: August 07, 2016, 12:12:01 pm
content: $ as in membership and licensing fees, consulting and custom development services to have external "experts" who made the standards make you "save time" you'd otherwise lose trying to understand them yourself by doing implementation work for you, etc.

author: MT
author_rank: Super Contributor
timestamp: August 07, 2016, 01:26:13 pm
content: Yes, but which standards requires absolute "external help" to implement? We bought a IP PCI block for an ASIC we once did , it was so badwe had to write our own in the end, we saved a lot of money and time doing so and we would have saved even more not buying it at all.RS232/MIDI, SPI etc barely require "external help",standards that actually creates money for you.Perhaps a shift to "Open standards" is better rather then "deliberately difficult global standards".But my initial question was not entirely directed to standards rather more of a "general question".

author: filssavi
author_rank: Frequent Contributor
timestamp: August 07, 2016, 02:56:06 pm
content: Quote from: MT on August 07, 2016, 01:26:13 pmthe external help we are talking about is exactly IP blocks, you might have been burned by a bad IP block but the fact that there are several big companies that make(a big part or even all) their living thanks to IP blocks (synopsys and cadence for starters but also ARM) stands to show that IP blocks are not an absolute evil in all situations...the protocols you have mentioned are so old, simple and well understood that there is almost no need for a copy of the standard text to implement one, other standards like USB 3.0 , HDMI ecc will be far less pleasent to work with...

author: Kilrah
author_rank: Unknown
timestamp: August 07, 2016, 05:03:55 pm
content: Quote from: MT on August 07, 2016, 01:26:13 pmThey're old and "mature" if not obsolete, they were also proprietary at some point, they were easily understood and reverse-engineered once good enough test equipment became available - but still, when they came out they also provided revenue and were probably considered painful to implement (think the RS232 levels when the MAX chips didn't yet exist and you had to make the negative voltages yourself in an otherwise 5V-powered computer, i2c when your 80's era micro didn't have an integrated peripheral and you had to choose between bit-banging the thing when you were already short of CPU power or buying a dedicated i2c interface component with the added BOM and board costs)...It's just the way it goes. Standards start closed so they can be milked commercially as much as possible with early adopters, then over a few years as they become more widespread, equipment catches up to understand them, standard components (either hardware or IP blocks) implementing them start appearing the commercial value goes down and accessibliity increases. And it starts over.The latest and greatest is developed for by big businesses for big businesses, starts right there at the top then trickles down with time. I.e open standards would be public straight away, closed standards will end up public anyway but you can make big bucks with them first. What would you choose if you were to develop one and knew you had the power to push others to use it?

author: MT
author_rank: Super Contributor
timestamp: August 08, 2016, 12:26:27 am
content: Quote from: Kilrah on August 07, 2016, 05:03:55 pmNone of that is applicable to MIDI. I vaguely recall SPI was Motorola SPI no idea if SPI was under license or not.QuoteBack in the ol' days we used two tiny chips i cant remember the name of before MAX232 appeared.QuoteI would never be in that position to begin with. Hypothetically if i was? Well i would not enter uncle scrooge mode instead make it open standardin the format what happened to MIDI!QuoteQuote

author: technix
author_rank: Super Contributor
timestamp: September 12, 2016, 04:43:37 pm
content: From time to time people just end up gave up on implementing the protocol from the standard text, and instead sample ready-made chips to reverse engineer the protocol from a black box perspective.And it is very common to find those black-box reimplementations much easier to understand and use.

author: vraifluss
author_rank: Newbie
timestamp: April 30, 2017, 06:33:23 am
content: I have read the early I3C specification of 2016. it still was very difficult for implementation.For now, I could not access it anymore. interested in I3C Implementation on FPGA in hobbies projects.Any open projects?

author: abraxa
author_rank: Frequent Contributor
timestamp: April 30, 2017, 02:22:35 pm
content: Quote from: MT on August 07, 2016, 01:26:13 pmYou're overlooking one MAJOR aspect: liability. If I buy IP from you, you are the one I can point to in case something goes wrong. If I buy the standard papers from you and implement the IP in-house, I'm responsible if something goes wrong. Case in point: CAN FD. Lots of automotive suppliers license the IP from [insert company name here where CAN was invented originally]. It's not that they couldn't do it themselves - it's so that they can blame someone, being able to pass the buck and not having to pay $$$. Now imagine people had died because of a bug in that IP. Would you prefer to be the proud engineer who wrote it, being directly responsible for people dying? Or would you prefer being able to point at someone else?