シャドーイング練習: Basics of I2C on Linux - Luca Ceresoli, Bootlin - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

549 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

Hello everybody, thank you for being here.

This is a basic introduction to using I2C on Linux.

I am Luca Ceresoli, Embedded Linux Engineer at Bootlin, and we provide consultancy on embedded

Linux systems on the Linux kernel, especially device drivers, boot loaders, build systems, and so on.

And we also provide trainings on all of those topics.

I live in Bergamo, Italy, and I'm speaking a bit fast because I have a lot to say.

I hope everything can be understood, but stop me if anything is not clear.

So let me introduce briefly what is Iceworthy.

Iceworthy is a communication protocol meant for communication between integrated circuits on a board,

on a PCB, typically, over short distance.

It is designed to be very simple to implement in hardware.

It has only two wires, and on two wires, many chips can communicate.

And it is not discoverable, no plug -in.

It doesn't have many advanced features, but it's very popular because it is very effective.

It is a pretty low speed, usually 100 or 400 kilohertz.

and you can also find it named with different acronyms depending on the vendor

so i2c iic twi and so on

but it's basically always the same thing you can find documentation on wikipedia

and also on in the kernel documentation there are mainly two roles in i2c

so a chip on the line can be either an adapter

or a client the adapter in red in picture is also called a master in the i2c specification

or the adapter is the name used in the linux kernel it's also called the controller

and sometimes a bit confusingly a bus it is the device

that starts all the transactions all the communication and there is usually one per bus but also multi -master is supported

the adapter has no address.

The other role is called the client within the Linux kernel.

The specification calls it slave.

It's also called device sometimes and it's the green boxes in the picture.

It's absolutely normal to have multiple per bus.

It is the kind of device that responds to transaction made by the adapter

and it has an address to be made by 7 bits even though there is a 10 -bit extension

and the address is set in hardware

it's not automatically assigned by the adapter like in usb it's really depending on the chip

and it's in its own hardware in its own silicon the two lines are called officially sda

and scl sda is the data line it is bidirectional

so depending on the protocol in some moments the adapter is driving it in some moments it's the

device the client depending on the protocol

and the scn line is usually called the clock line

if you expect that a clock is a line

that moves at a constant period it's not exactly the case in i2c

but it is still the line that tells when things should be done and so it is called usually the clock.

All the lines are open collector which is useful to have all of the chips in the same line.

This is how a communication works in I2C.

There is always initially a start condition which is the one here

and then it's always the adapter which sends the first byte.

All communication are 8 bits in in I2C, it sends the first eight bytes,

which contain the address of the client to contact,

and which is seven bit plus one direction bit, read or write.

And then the client sends an acknowledgement bit.

And then there is another byte, and since this is a read transaction, then this byte will be sent by the client,

and then the adapter will send the acknowledge.

And finally, there is a stop condition at the end.

And so this is an entire transaction that cannot be interrupted on the line.

Well, I2C defines this relatively simple structure.

So there are bytes going in one or the other direction.

And that's pretty much it.

So it doesn't define what you should put in those bytes.

But there is another protocol which is called SMBUS, which is actually designed for chip communication on a motherboard.

It is basically a subset of I2C,

but in addition, it defines a lot of common transaction types like to read or write a register,

for example, or to read, write, and buffer.

And this is very useful.

And many I2C devices actually use the same command structure as SMBus.

So basically, the two protocols are largely overlapping.

And typically, I2C and SMBus devices can coexist on the same bus.

And in the Linux kernel, for I2C devices,

it is recommended to use SMBus commands whenever the i2c chip uses the same uh let's say command structure

and so the two protocols are really uh very uh close to each other very much overlapping

um let's see how i2c hooks into the linux driver model

which well models whatever is a a device connected to the system.

So the device model is made by layers, which pretty much map the layer,

the structure of the devices in the hardware from the CPU to the peripherals.

So the driver for a 9 .2C connected chip is represented in green and so in this example,

we assume we're having an external GPIO controller connected over IS4C

and so it will have a driver and there will be a GPIO subsystem

that will send us commands via this set or get callbacks implemented by the GPIO chip driver.

And so we are receiving requests from the upper layer to do something

that is specific to the feature provided by the chip.

And in response to that, our I2C chip driver, GPIO in this example,

will prepare a transaction that it wants to do to the chip and ask the I2C subsystem to do this transaction,

which will actually be fed to the adapter driver.

The adapter will then do this transaction doing whatever action, like writing on the platform bus,

for example, to actually let the transaction start and after the end it will return back the result to the original caller.

So when the system starts, the various drivers are populated from bottom to the top.

So usually the platform will create the adapter driver, which in turn will inform the I2C subsystem that there is a new adapter,

so a new bus.

And then the I2C subsystem will instantiate the driver for all of the peripherals on the physical bus,

which in turn will create GPIO chips or RTC or audio codecs or whatever is connected there.

Once this is in place,

you can see in SysFS the devices that are present in the system,

well, the devices that are known by the kernel at least.

So in Sysbus I2C devices, you can see two families of objects.

In the bottom part, you can see the adapter of the buses actually.

Bus and adapter are really one to each other.

There is one bus per adapter.

So we have four buses in this case, which are numbered from zero to three.

And in the higher part of this list,

you can see the actual clients whose name is number of the adapter dash address of the i2c client

and so inside those directories there are more files where you can see some information about all of the devices

100

so it can be useful to at least to see

101

if the kernel knows your device is there

102

which is already the first thing to check and also some additional information that is specific to that device.

103

How things are populated into the kernel?

104

In embedded systems it's almost always done by device 3 so I will focus on that.

105

If you already know something about device 3 you are probably familiar with this kind of syntax

106

and basically there are you

107

almost always have already the Iceberg C adapter described inside your system on chip device 3 .5

108

and so you don't need to declare the adapter usually.

109

You need to reference it, so 100 % I2C4 here and to set some additional parameters,

110

some additional properties specific to your own board

111

so in this case for example we set the clock frequency

112

which is very common to a maximum rate of 400 kilohertz

113

and state is okay to enable the device and then for each client

114

that is connected on the on the bus of this adapter

115

we have a sub node the sub node needs to have

116

a compatible string as usual in device 3 to be able to probe the appropriate driver

117

and then the reg property which is the client address, sleeve address, as it's mentioned usually in the data sheets.

118

And so it's the only parameter that is always required by I2C to, well, this is always needed.

119

All of the other properties are specific to this device.

120

So this specific chip needs those interrupt, pin control, and so on.

121

It's not really I2C specific.

122

So the structure is very simple in Device 3 to describe your adapter and the clients connected to it.

123

And there are many more properties, optional properties, I'm not covering all of them,

124

but there is a link here to the documentation where you can see all the common properties, especially for I2C adapters.

125

okay so in your life you will possibly never have to write an adapter driver

126

because it's usually done by whoever implements the dbsp for the specific system on chip

127

but it's absolutely common that you will need to implement an i2c device drive client device driver

128

and because there are so many models around and

129

so that's what i'm going to cover let's see an example i found in the kernel one

130

that is the the simplest i was able to find

131

and it's a gpao controller actually

132

and i'm starting from the the end of the file because it's where actually is the entry point

133

of a driver so you have to populate a struct i2c driver which whose name is quite self -explaining

134

you give it a name

135

you have to give it two tables do you want to i will cover those two tables later

136

and then a probe function which i also will cover later

137

and finally you call the module i2c driver macro to inform the kernel

138

that there is a driver so it will be known to the kernel and used whenever needed.

139

So these are the two tables to populate.

140

The second one is particularly important because it's the one used for device 3

141

and the one that matches your compatible string with this specific drive.

142

So if you have this compatible string in your device 3 then this driver will be loaded and used

143

and there can be additional parameters for a specific version of the chip like here we support a 4 GPIO

144

and an 8 GPIO variant so we have some additional parameters for that.

145

The probe function is the function

146

that gets called by the kernel to ask the driver to initialize

147

and prepare everything about the device and make it ready to work.

148

So this is the typical structure.

149

It first allocates some memory for driver specific information,

150

so information that is specific of that chip and then it initializes internal structure.

151

In this case these are specific for the GPIO chip kind of device.

152

It would be different if it were an RTC and an IIO and an audio codec or whatever.

153

But it's important that in this example here, the GPIO subsystem will need to call these two functions,

154

get and set, to modify or read the status of GPIOs.

155

Then drivers usually also write to the device in this function to initialize it.

156

It's not the case in this driver because it's a simple chip.

157

And then you call I2C client data, which will take the device -specific pointer and put

158

that into the I2C client structure so that you can have it back later if needed.

159

And finally, there is pretty much always a call to the upper layer,

160

to the upper subsystem to inform it there is a new device.

161

In this case, there is a new GPIO chip device.

162

And so you are calling the GPIO chip add to add a new GPIO chip into the kernel.

163

It would be different if you are creating an ADC

164

or an RTC or whatever but basically you are populated in the upper layer block.

165

So this is really the minimal structure of the driver

166

and this is a recap of all the steps that I went through for reference.

167

Then you have to implement those callbacks for in this case the GPIO subsystem.

168

At some point the GPIO subsystem will call you telling please set this GPIO output

169

or please read those inputs

170

and this is a simplified version of the actual function in the kernel

171

so basically what it does it it obtains the pointer to the i2c client for from its own internal structures

172

then it prepares the buffer to send to the device

173

which in this case is just a byte because it's a simple device

174

and then it calls in this case it's i2c smbus write byte which sends a byte to the device

175

As you can see, we are using SMBUS call

176

because this device needs a sort of transaction that is identical to the one defined in SMBUS.

177

And so we are using the SMBUS calls.

178

So this is a very, very simple example of sending a transaction of a function in the driver to send the transaction to the device.

179

there are other functions to do transaction to the device.

180

There is this family where the write byte function that we have just seen is.

181

There is a corresponding read function and there are also functions to send a buffer, not only a byte, to send or receive a buffer.

182

But I think the most most widely used function is probably those two have register like access

183

because many devices really present a set of registers

184

that you can read and write via i2c and

185

so the calls are i2c smbus write by data

186

or read by data which take as a parameter the register number

187

and then of course the the value there are also variants of these to transfer more than one byte

188

but you can see all of them in the documentation especially in the SMBUS protocol there are many variants

189

so probably you will find one that will suit the needs of your specific chip you need to implement

190

but if you don't find any no problem there is i2c transfer

191

which i call the Swiss army knife or linux i2c

192

because it really allows you to implement any sort of transaction

193

or even better any sort of sequence of transactions

194

so it can do many transactions basically as many as you want

195

and by default it does repeated start between them to keep them connected together

196

and it's very customizable it has many flakes applicable to each transaction so an example of i2c transfer

197

He's from another driver.

198

So basically what you need to do is to create some I2C message structure, an array actually.

199

In this case, we need two transactions for this device.

200

And then populate those with the data to send or receive.

201

The first transaction has no flags, which means by default it's a write transaction.

202

So it will send data and so you have to pre -populate a buffer

203

and put that buffer and its length into the structure and you have to set the client address.

204

In the second transaction again you send the client address

205

which could be different between transactions it's not common but it's possible

206

and then you have a receive buffer and a flag indicating it is a read transaction.

207

So in the all you have to do after populating the array is call i2c transfer passing the array

208

and it will just do all the transaction

209

and get back to you with a return value indicating the overall result

210

and so this is the most powerful call to do the transaction you might need

211

so that's the overall picture of how to write a driver for an i2c connected device and now let's move

212

the top floor on on the higher floor so in user space so drivers work in the kernel but

213

let's see what you can do in user space

214

and the first rule about using i2c from user space is do not use i2c from user space uh yeah

215

you know i2c is a communication bus

216

which is meant to connect the cpu to some external chip

217

which in turn provides some functionality so that functionality will be an RTC, it will be an audio codec,

218

it will be whatever and so you should use that functionality, the higher level functionality and the kernel in turn will go to your I2C adapter

219

and whatever to bring you that functionality which has a standardized interface and so on.

220

But still there are valid use cases for using tools in user space and so let's have a look at them.

221

I2C tools is the name of a package containing multiple tools.

222

It's available in every distribution, every build system and so on and they are useful mostly for debugging,

223

testing, prototyping and such like activities which are probably useful for you when writing a driver actually.

224

This is not supposed to be used as the tool for your real usage.

225

Many of these tools assume that a device has registers, SMBus -like.

226

So they are not always, this is not always a correct assumption.

227

When you run these tools, they will produce this warning.

228

This problem can confuse your I2C bus, cause data loss and worse so you are warned because I2C does not standardize the type of transaction.

229

So if you do the wrong command, you might screw up something or produce explosions or whatever.

230

So be careful.

231

Learn your hardware before just running random commands.

232

So the first tool that I want to show you is I2C Detect, which can, well, it can list the buses but most important,

233

it can go on a bus and try to contact each client address and see if there is a response.

234

And so it will show you this nice table showing that at most addresses there is dash dash,

235

which means there was no response at this address.

236

There is a number here, 28, which means I got a response.

237

I got an acknowledge basically from when I tried to contact this address

238

so there is probably a chip there and then there is a uu

239

which means this address is already in use by the kernel

240

so there is already a driver for it

241

so you should not use the user -based tools on this chip or the driver would be probably get confused.

242

Other tools are i2cget and i2cset which allow to set and get the value of a register.

243

They can do multiple types of SMBUS and i2c transactions,

244

so it's pretty flexible and the only big limitation of these tools is they assume the register address is 8 bits.

245

For the rest they are very flexible, so it's pretty simple, just i2cget,

246

the bus number and then the register address and then you will get well no sorry the bus number,

247

the client address and the register address and you get the value and that's it.

248

So it's very simple to use and can be very useful.

249

i2cdunk is a sort of powerful version of i2c get

250

which iterates over the entire 8 -bit addressing space

251

so it will basically print the all of the value of all of the registers in your device

252

which is extremely useful in some cases to debug to understand

253

if your settings have been taken or not and so on

254

and then if none of those tools is enough for you there is again something called i2c transfer

255

which is the Swiss army knife of Linux I2C in user space.

256

So it can also do an arbitrary number of transactions.

257

It takes multiple parameters.

258

So for example, here we are saying, write one byte at this client address, and then this is the byte to send,

259

and then read one byte from the same address.

260

So basically with this line, I re -implemented the I2C get command

261

that we saw in a previous slide with I2C transfer so you can do more powerful things with this.

262

It could be just to test if you correctly understood the protocol of the device before implementing that in the driver.

263

You want to make sure you understood that correctly.

264

Okay, so this is a good set, a good toolkit of software tools, but it might not be enough.

265

You might need also hardware tools.

266

If something goes wrong, especially you will need them.

267

One of them is possibly an oscilloscope, which is able to show you whatever happens on each of the lines simultaneously.

268

it's very useful if you need to check the voltage levels, if there is any noise, any spikes, and so on that could produce unwanted effects.

269

And many oscilloscopes nowadays can also decode I2C very nicely.

270

So this is an example screenshot.

271

I don't know if it's very visible, but well, this is the data line and the clock line.

272

And in the bottom area, we have the decoding

273

so it says you are accessing client address 51

274

and there was no acknowledgement and this was a right transaction

275

but you can also see for example there are small spikes here

276

and it's useful to do the mostly hardware debugging that could cause strange problems in the software

277

this is another example with an entire register read actually

278

so the decoding also says you are access doing a write transaction to client

279

that is 52 and the data is 22 which is the register address

280

and then this is the read transaction which gets you back the data.

281

Another tool that you can use is a logic analyzer.

282

Actually there are software implementation of this.

283

I use Pulseview which is part of the SigVroc project.

284

It's an open source software, it's in your distribution and it can work with very cheap data acquisition devices.

285

I have this one that I paid like 15 euro and it's perfect for I2C.

286

So we can sample the lines and a logic analyzer does not show you the levels.

287

It has only high and low, that's it.

288

But for the rest, it's very powerful

289

because you can see very nicely the transactions here and PulseView decodes them in a very readable way.

290

There is the start condition,

291

then the address is 42 and then it's a write transaction and there is no acknowledgement and there is a stop condition.

292

So it's very easy to read and to see if anything is wrong.

293

So here we have the same transaction as before reading a register.

294

This is also pretty easy to read and there is the repeated start here

295

which is a start condition

296

that happens after another start condition without a stop condition in the middle and it's used to ensure that there is nothing,

297

for example, another master that starts another transaction in the middle.

298

So it's another thing you can see from this kind of tool.

299

Okay, and so probably the main goal of all of those tools is to do troubleshooting.

300

Of course, you will need troubleshooting at some point and especially

301

when with device drivers it could be in the gray area between software

302

and hardware so here is a brief overview of some troubles and how to investigate them and what can be the reason so one

303

but first the first rule

304

you have to keep in mind about troubleshooting is never ignore the return values from the functions

305

so you don't have to assume transaction have succeeded

306

because anything could happen if you have a wrong assumption

307

so always check the return value

308

so after you've done your homework look at the kernel logs they might contain some useful error message

309

and so a good point to investigate if it doesn't work you can use i2tools to check whether where,

310

for example, your register has really the correct value and so on.

311

And if those are not enough, you go onto the oscilloscope or logic analyzer.

312

So one typical problem with I2C is you don't get an ACK knowledge from your device.

313

So this is the error message from I2C tools, and this is the error code returned by the internal calls.

314

so the first tool to use to debug

315

I would recommend to use is i2t detect

316

you could just find a it could just find some response from a different address than the one

317

you expect like the the next address or similar and

318

so maybe you didn't configure correctly the address pins of the device

319

so it is responding to another address so you check the data sheet and

320

or check the schematics and maybe that device

321

can respond to different addresses

322

and based on the pins

323

it's configured for another address than you expect again with i2c detect you might just see

324

that there is no response from any address

325

or i mean from any unexpected address and so as

326

if the device were not there so maybe the device is just not power

327

or it is held in reset your reset polarity is wrong

328

or it is broken it is and also it has an unsoldier pin

329

so it can be all sort of things it's mostly a hardware debugging thing now then

330

if those fail you should take the oscilloscope or the logic analyzer

331

and for example you see no activity on the on the lines even though you are running i2c detect

332

or you are running your driver and

333

so the kernel says i've been doing transactions

334

but you don't see anything on the lines

335

so the first thing to check is the pin mooks maybe you have mooks your adapter onto the wrong pins

336

and so it is not driving those lines it's driving somewhere else

337

so check those

338

and then you should also check your device tree you might have put your your client under the wrong bus

339

so you are contacting the wrong bus and

340

so on again with an oscilloscope you could also see

341

that the lines are always low so

342

if there are always high it's the previous case the pull -ups keep the line high

343

and nobody drives them low on the opposite if they are always low

344

that is possibly due to missing pull -up resistor

345

so somebody's driving them low and nobody will ever pull them high

346

so again something to check on your hardware as they work around

347

you might use internal pull -ups in your system on chip if you cannot fix it quickly in hardware.

348

The same problem of a missing acknowledge, instead of being systematic, happening always, could be happening only once in a while, sporadically.

349

And so in this case, it's a bit more tricky.

350

But one possibility is that your clock

351

or data lines are returning to the high polarity too slowly it's a pull up it's an open collector line

352

so you might have a resistor that are just too weak you need stronger resistors

353

and so one workaround to move on before you can fix them is to reduce the clock frequency

354

so you you have more time for for the transaction

355

again if you see with an oscilloscope you see a noise on the lines that's extremely bad

356

because it could be interpreted as a clock pulse

357

or the data could be read incorrectly and

358

so this needs absolutely to be fixed in the hardware no bus can work if there is too much noise

359

another possibility is

360

that you have a mismatch between the timings wrong timings it's not very common in s2c

361

because it says low bus but

362

if it happens you could well you probably should improve your pcb design

363

but otherwise some adapters support the device tree properties to modify

364

the delays of one line with respect to the other so it might be helpful in some cases

365

or as a workaround you could again reduce the clock frequency until you have your hardware fixed.

366

A different set of problems is that, well it's something that actually caused me some headache,

367

when you have an unclean reboot like watchdog reset for example,

368

after that you are hung during the booting

369

or some device just does not respond during the boot as if it were not there.

370

And this is typically due to a driver that was in the middle of a transaction and then the CPU rebooted.

371

So if it did a clean reboot, hopefully the driver would put back the device in a clean situation, able to be reinitialized.

372

But since the CPU rebooted suddenly in the middle of a transaction, the device could be there,

373

stuck somewhere and not responding correctly or even keeping your bus hang which is extremely bad.

374

So one thing you should do is to reset your chips during boot,

375

possibly in hardware, but if it's not possible in the bootloader.

376

So in the bootloader

377

you should just set all of the reset pins of all of the devices on the bus

378

so that they are reset before the first I2C access and you are safe then in your reboots.

379

Okay, another situation is the bus busy situation.

380

It's actually quite easy to spot if you look at the kernel log because there is really a bus busy message, so it's very clear.

381

Bus busy means that the clock line is kept low by somebody, but not the adapter.

382

So the adapter has released it, waiting for the pull -up resistor to pull it up again, but this didn't happen and

383

so it might be for example a multi -master well no

384

well first thing is it could be a short circuit

385

if it's happening systematically so you should check the hardware

386

or maybe you have a mounting problem or maybe just some solder incorrectly done and so on so if that is

387

the systematic but if it's happening only sporadically it could be just a chip

388

that in some cases goes crazy and or gets badly configured

389

and so he keeps the line low for some reason

390

so you well you should fix that if possible

391

if it's a driver bug or maybe find a better chip

392

but the kernel has some self -defense mechanism there is a recovery procedure which is is actually also visible here.

393

So the kernel will try to recover the bus by moving the lines in such a way that

394

a client should interpret as, well, it should move the device from its status.

395

And it can also be, the recovery mechanism can also be provided to GPIO pins

396

that it will use to take over the bus instead of using the adapter

397

it will use the gpios to be able to drive the bus in every possible

398

waveform so to get your device unlocked so it's quite powerful

399

but still you should not rely on this

400

but rather fix your your investigate the problem and fix your hardware or drivers

401

or whatever is the cause another cause for this kind of

402

problem could be multi -master multi -master in in my experience it's not very common

403

but still if you have multi -master then you first have to make sure

404

that the other master is not keeping the the bus down because the other master is typically

405

not under the control of your linux system it's maybe a microcontroller whatever you have to check

406

that okay that is all i hope

407

that was interesting useful uh we have a few minutes for questions

408

if have any

409

yep sorry

410

I don't know that so there is a an error correction mechanism in S4C Yeah, called PEC.

411

Okay, no, I don't know that.

412

Probably it needs a client chip implementation.

413

Yeah, both to support this.

414

Yeah, okay.

415

Is it, I don't… It's simply a checksum over the… Yeah, yeah, yeah.

416

The additional pipe is a checksum over the entire message.

417

Okay, is it popular among chips?

418

I don't think so.

419

Some of them, for example, smart battery or battery gouges.

420

Okay.

421

I see, yeah.

422

Yeah, sorry, I don't know that.

423

Yep.

424

Just wondering, if you have multiple I2C devices, they share the same memory address, which can't be changed.

425

Is there a way of handling that device, please, if you multiply the I2C devices?

426

You mean two I2C devices that has the same address?

427

Yes.

428

Yeah, if you really cannot change their address and so on, there is...

429

Here, there are chips called I2C Switch or I2C Moxes, which...

430

Well, I think the picture represents pretty well what they do.

431

So basically, they connect your adapter to one or another line, or they can have four or eight lines.

432

So they, and you can change the switches based on I2C itself to the MOOCs chip or to using GPIO.

433

It depends really on the model.

434

And this is very useful to access, to use this situation.

435

You have like eight or 10

436

or 20 chips of the same model you probably cannot solve

437

that with using only the address pins and so this is quite useful.

438

It's well supported in the Linux kernel also.

439

And you said that you'd give the details amongst the device tree as a sort of check -select for each I2C device.

440

I'm sorry, I don't hear.

441

So how would you tell the device tree how to talk to each individual I2C client?

442

Yeah, in device tree you will have under the adapter node, you will have the mux node and under the MOOCs node,

443

one sub node for each of the downstream buses and the chip devices in there.

444

Yeah, yeah.

445

Yeah, I reckon.

446

Yep.

447

So considering the availability of RegMap and its usages and comparing with I2C operations of implementing the fly driver.

448

I'm sorry, I don't hear the...

449

Okay, so considering the regmap implementation of accessing the registers in let's say IAO driver or so,

450

how much is usable in terms of implementing a cloud driver straight away using the I2C operations?

451

When it will be useful, like when we choose regmap or when we choose I2C?

452

Yeah, sure.

453

I didn't mention that because there was no time available, but there is a system in Linux called regmap,

454

which allows to abstract register access and it can work with I2C, SPI and many others.

455

And you should use RegMap when, I would say, when it provides some useful features to you.

456

Like it can do caching if you frequently modify the SIM register.

457

It's definitely to be used pretty much mandatorily

458

if you have the same chip that can have an I2C connection or an SPI connection, which is quite common in audio codecs, for example.

459

or well other drivers still use regmap even though they don't have a strong requirement for it

460

but it it's

461

because it also provides some extra features like they can expose in debugfs I think all of the registers

462

and so on so it's actually it's up to you it's whatever you feel it's better

463

if you don't have a strong need.

464

It's really up to you.

465

Personally, I think it could be okay to use just the I2C calls, at least for simple drivers.

466

It's also easier as an entry point if you are not super experienced,

467

but RegMap can be quite useful, especially for larger situations.

468

Yep.

469

Stop.

470

One more question, okay.

471

Yep.

472

Do we have some other tools like I2C detect?

473

Because I have a situation where I get some wrong address with I2C detect?

474

You get the wrong address with I2C detect?

475

I mean, it's something different than what I'm expecting.

476

Okay.

477

So it can be that I2C detect is showing me something wrong.

478

I don't know any other tools similar to I2CDetect.

479

So the question is, I have some unexpected results from what I expect from the board.

480

I don't think there is any other tool, at least not that I know.

481

There probably are, but if they don't work,

482

maybe it should just be debugged and understood if I2CDetect is wrong or if your assumptions on the board are wrong,

483

which is, I would suggest using a logic analyzer would be better here

484

because it can sample a lot of data with respect to an oscilloscope.

485

So it could sample easily the entire run over all the addresses that I2C detect does.

486

And so you can inspect, why do you expect an hack here but you don't get it in I2C detect?

487

So you can see if on the line really the hack is not there

488

or if it is there and see if the problem is in your hardware or in the tool. and

489

if you find a bug in the tool it would be very good to send a patch to fix it but honestly

490

it's widely used so i would be surprised it's also quite a simple tool

491

it could be anyway a bug in the adapter driver maybe because it's also in the line between you and the device

492

Yeah, this is actually one quite common problem when working with I2C on Linux, the shifting.

493

Yeah, good point.

494

The addresses that you saw in all of my examples.

495

is here for example 28 is the seven bits using from the lowest bit

496

so it basically the highest address is 7fx

497

but in some data sheets in many data sheets actually they are represented in the other way

498

so using the seven highest bits so the the it will use only odd numbers or even numbers

499

So you have to take care of that and you might need to shift to take the number in the data sheet,

500

shift it down one bit and use that in Linux.

501

So Linux always uses the lower 7 bits, which is different from what you see on the bus actually.

502

So very good point.

503

One thing to say is that ITC detect uses a different command for certain address ranges.

504

There's a quick read and there's a read.

505

Yeah and some devices don't respond correctly.

506

Yes, exactly.

507

So yeah, the remark is i2cdetect uses different commands.

508

It can use one or a read or write command and some devices respond only on one or only on the other.

509

So you should check those.

510

Have a look at the help from i2cdetect

511

and keep in mind the general rule that those tools are abusing a protocol

512

so they are assuming some kind of responses

513

which is what most chips do but not all

514

so really understand what your device needs and make sure you do

515

that transaction if none of the tools does them out of the box you can use i2c transfer

516

and prepare your own transaction or just write that into the driver if you already have a driver skeleton.

517

Okay, I think we have to stop.

518

One more question from the virtual audience.

519

One question from the virtual conference.

520

Yes.

521

Why is the red value always dictated in the device name behind the app symbol?

522

I'm sorry, I didn't...

523

Why is the red value always dictated in the device name behind the app symbol?

524

In the device tree, you have the node, you write some name and then add 28.

525

And that is then duplicated in the reg.

526

Oh yeah, that's just device tree syntax.

527

Yeah, so here.

528

Yeah, you will find this everywhere, not only in I2C, the same address is here and there.

529

So basically the reg1 is the one that is used really by the kernel code and the at 28 here is,

530

I think it's only a convention.

531

It is nice when you read it in CSS, for example, or in the bug logging.

532

It's informative, but I don't think it really has any active role, but I'm not really a device tree expert.

533

It's required by the specification, by device tree.

534

It's mandatory by the specification?

535

The bus is numbered.

536

It's like register map.

537

It needs to have certain attributes.

538

It needs to match the first correct property.

539

Alright, so by the specification of device 3 it has to be like that, so it doesn't provide any feature but you have to do that.

540

What does the name unique?

541

What does the name unique?

542

Yeah, sure, of course.

543

Yeah, it also makes the name unique.

544

There are other techniques to do that, but this is one and it works.

545

Yeah, sure.

546

All right.

547

Yeah.

548

Thank you very much.

549

Have a good lunch.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

FOR YOU

このレッスンの語彙とスピーキングのポイント

このスピーキングレッスンは、動画「Basics of I2C on Linux - Luca Ceresoli, Bootlin」を教材にしています。繰り返し出てくる語は次のとおりです：device, driver, transaction, chip, address。この動画には、シャドーイング用の文が549文、単語が6920語あります。音声の長さは48:55です。話す速さは1分あたり約141語で安定しており、シャドーイングしやすいペースです。単語の82%は英語の頻出3,000語に含まれます。残りは練習の前に確認しておきましょう。

この動画の重要語彙

動画に出てくる覚えておきたい単語15語を、発音と意味つきで紹介します。

単語	発音	意味
transaction 名詞	/tɹænˈzækʃən/	処理
adapter 名詞	/əˈdæptəɹ/	アダプター
kernel 名詞	/ˈkɝ.nəl/	核心
hardware 名詞	/ˈhɑɹdˌwɛɹ/	ハードウェア, ハード
detect 動詞	/dɪˈtɛkt/	検出する, 見付ける
clock 名詞	/klɑk/	走行距離計
implement 動詞	/ˈɪmpləmənt/	実行する, 実現する
protocol 名詞	/ˈpɹoʊtəˌkɑl/	議定書
node 名詞	/noʊd/	結節
pin 名詞	/pɪn/	ピン, 鋲
parameter 名詞	/pəˈɹæm.ə.tɚ/	媒介変数, パラメーター
layer 名詞	/ˈleɪ̯ɚ/	層, 膜
sheet 名詞	/ʃit/	枚, シート
specification 名詞		仕様, スペック
functionality 名詞		機能性

動画に出てくる句動詞

単語	発音	意味
pull up 動詞	/ˌpʊl ˈʌp/	引き上げる
put back 動詞		もどす
run over 動詞		轢く
take over 動詞		引き受ける

繰り返し練習したい文

動画に出てくる短く完結した文です。日常会話でそのまま使えます。

I'm sorry, I don't hear.
I'm sorry, I don't hear the...
It's really up to you.
I mean, it's something different than what I'm expecting.
I think it's only a convention.

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
条件文 if + 節, will/would + 動詞 — 条件とその結果	If something goes wrong, especially you will need
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	can be understood · is designed · is also called
関係詞節 who / which + 節 — 人や物について情報を加える	collector which is · condition which is · protocol which is
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	have just seen · have been taken · have succeeded

注意したい発音

話し手はdon't, I'm, didn'tなど、短縮形や弱形を43回使っています。聞こえたとおりの短い形で発音しましょう。

「sh」と「zh」の音: transaction /tɹænˈzækʃən/, sheet /ʃit/, documentation /ˌdɑkjəmɛnˈteɪʃən/, implementation /ˌɪmplɪmənˈteɪʃən/, dash /ˈdæʃ/
長い単語（アクセントの位置に注意）: parameter /pəˈɹæm.ə.tɚ/, documentation /ˌdɑkjəmɛnˈteɪʃən/, implementation /ˌɪmplɪmənˈteɪʃən/, investigate /ɪnˈvɛs.tə.ɡeɪt/, mechanism /ˈmɛk.ə.nɪ.zəm/

日本語話者が苦手な音：

/r/ と /l/ の区別 — /l/ は舌先を歯茎につけ、/r/ はどこにもつけない: protocol /ˈpɹoʊtəˌkɑl/, correctly /kəˈɹɛk(t).li/, controller /kənˈtɹoʊlɚ/, virtual /ˈvɜɹt͡ʃuəl/, peripheral /pəˈɹɪf(ə)ɹ(ə)l/
/v/ — /b/ にならないように、上の歯を下唇に当てる: investigate /ɪnˈvɛs.tə.ɡeɪt/, visible /ˈvɪzɪb(ə)l/, virtual /ˈvɜɹt͡ʃuəl/, variant /ˈvæɹi.ənt/, overlap /ˌəʊvəˈlæp/
/f/ — 「フ」ではなく、上の歯と下唇で出す: buffer /ˈbʌfəɹ/, frequency /ˈfɹiːkwənsi/, define /dɪˈfaɪn/, inform /ɪnˈfɔɹm/, modify /ˈmɑ.dɪˌfaɪ/

この動画での練習方法

まず声を出さずに動画を最後まで聞き、知らない単語をメモします。
通常の速度で一文ずつシャドーイングし、話し手のリズムに合うまで繰り返します。
自分の声を録音して元の音声と比べます。transaction, adapter, kernelなどの単語に特に注意しましょう。

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: Basics of I2C on Linux - Luca Ceresoli, Bootlin - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

おすすめ動画

I2C Protocol Explained #engineering

LINUX isn't Hard Once You Understand This (File Directories)

PCB 101 Academy - Learn how printed circuit boards are assembled

Top 5 Redis Use Cases

ICT Mentorship 2022 Introduction

What is IMC (Intermetallic Compounds) part II? The different between IMC, alloy, eutectic

What is an interrupt and how is it handled in embedded C? #embeddedsystems #microcontroller

Distributed Systems 1.1: Introduction

BGP Overview

The Ultimate IoT Roadmap in 2026? | Embedded Systems & IoT Career Roadmap

Introduction to HPLC - Lecture 1: HPLC Basics

Making a 360° Controller Smaller than a Penny!

このレッスンの語彙とスピーキングのポイント

この動画の重要語彙

動画に出てくる句動詞

繰り返し練習したい文

この動画の文法

注意したい発音

この動画での練習方法

シャドーイングとは？英語上達に効果的な理由