EEVacademy #4 - I2C Bit Banging

[EEVblog]

Bit-Banging an I²C port with David.

[pknoe3lh]

Very very nice done 
I really like it!

The speed is right for me. I didn't want to change to another video (it happens a lot if I get bored)

The only think I'm missing is the timing in your code. 

[Brumby]

That pace was much better than the SPI talk.  For some stuff I was following pretty well and for other I had to really pay attention.  The coding fast forward was a bit of a blur, but I would probably watch that again with some stop-frame viewing along the way.  Some people will still find it a bit on the pacey side.

All in all - a very useful video ... and a confirmation of a value contributor to the EEVblog video library!

[Kjelt]

Very nice till the coding part. Watching someone add spaghetti code on screen is less watchable than first explain the needed functions and parts, you don't need an editor for that only more of the interactive animations.

[Brumby]

Good point about the code.

Watching somebody build it is a bit of a distraction.  There's a lot that goes on that doesn't add to the result - and can cause confusion.

All you really need is the finished source - and then be taken on a tour of it, followed by something demonstrating the testing.

[b_force]

I still think the pace is to fast, I doubt if non-native speakers can follow it.
Feels like you're on a hurry. The viewer barely has time to think about what you just said.

Didn't enjoy it, sorry.
Watched only a couple of minutes of it.

[Brumby]

I still think the pace is to fast, I doubt if non-native speakers can follow it.
Feels like you're on a hurry. The viewer barely has time to think about what you just said.

This is a very good point.

I'm a well-versed native speaker that has no issue with the pronunciation - and I was not given much time to absorb what was said.  I have little doubt that many non-native speakers would be overly challenged.

Also, I refer to a comment I made on the SPI video - that pauses are useful ... and necessary.  There was an improvement in this video, which was great - but there might be some room for a bit more.



All this needs to be taken with a grain of salt ... you are never going to please everyone.

[b_force]

All this needs to be taken with a grain of salt ... you are never going to please everyone.

This is true, but than what is the audience?

For me personally it didn't sound like an explanation/class in something.
It sounded like someone with knowledge, sharing information to someone else with enough knowledge.
And still, I have been in the field long enough, but I still prefer to keep things as simple as possible.
_{(That was also one of Einsteins strengths, keep things simple)}

[Craftplorer]

Hi,
great video and very nice visualization.
I would like to see how you implemented the timings on an actual platform.
Can you post/upload the CCS code from the "Bit Banging SPI" video?

[jpanhalt]

To be absolutely truthful, the first time I saw the title of this thread, I read it as "EE Vasectomy" and wondered "what"?

The video is not bad, but perhaps a less confusing name for us dyslexic types might be better.  On the other hand, my mis-reading was the only reason I opened the thread, so leave it as is.

John

[kire9999]

Thank you so much Dave2    , I really enjoyed your video. BTW, any chance you can share your C++ project of this example?, I'm currently trying to learn C++ and would like to have an example like yours.

Thanks!

[sleemanj]

I still think the pace is to fast, I doubt if non-native speakers can follow it.
Feels like you're on a hurry. The viewer barely has time to think about what you just said.

Didn't enjoy it, sorry.
Watched only a couple of minutes of it.

I have not watched this, but generally speaking,  for a couple of other youtube channels I find the youtube speed  control very useful.  One i play at a faster speed because he has a v.e.r.y s.l.o.w natural speaking cadence with lots of long gaps, speeding up by half or even double speed makes it much more comfortable, one I play slower than normal because the concepts are often hard and she is sometimes just going way too fast for me to keep up, slowing down makes it easier to follow.

[FrankBuss]

Thank you so much Dave2    , I really enjoyed your video. BTW, any chance you can share your C++ project of this example?, I'm currently trying to learn C++ and would like to have an example like yours.

The link is in the video description:

https://gitlab.com/Sepps/generic-bitbang-library-v1

But looks a bit over-engineered to me. Would be easier for many viewers, if it were a simple Arduino script without all the C++ overhead and without the extra pin class etc., just the bit-banging part, which could be implemented with a few functions in one script. Also in the I2C class the implementation should not be in the header file, but in the cpp file, the Pin class is better. And it should be really demonstrated with real hardware, again, very easy with an Arduino, because then the viewer can reproduce it faster, without needing to learn the intricacies of an IDE (and Visual Studio is a big and complicated IDE, too).

[b_force]

I still think the pace is to fast, I doubt if non-native speakers can follow it.
Feels like you're on a hurry. The viewer barely has time to think about what you just said.

Didn't enjoy it, sorry.
Watched only a couple of minutes of it.

I have not watched this, but generally speaking,  for a couple of other youtube channels I find the youtube speed  control very useful.  One i play at a faster speed because he has a v.e.r.y s.l.o.w natural speaking cadence with lots of long gaps, speeding up by half or even double speed makes it much more comfortable, one I play slower than normal because the concepts are often hard and she is sometimes just going way too fast for me to keep up, slowing down makes it easier to follow.

The speed control doesn't change the pace.
By that I mean pauses etc that the speaker implements to give the audience time to think about the things just said or to emphasize certain parts.
For that reason you can't expect the audience to do THAT by themselves, simply because they are the ones looking for information.

Second minor thing is that it feels very odd to slow down or speed up.

[nctnico]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

[pknoe3lh]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

Oh nice i didn't know this existed ^^

[FrankBuss]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

A source code comment says it does support it. But it doesn't support multi-master mode.

[Fungus]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

Oh nice i didn't know this existed ^^

It's an essential part of the protocol. Not all slaves will respond instantly in hardware, some are software driven. There has to be a mechanism in the protocol to force the master to wait until slaves are ready.

eg. Atmel chips like the Tiny85 don't have full I2C in hardware but they do have a little hardware unit that can detect an I2C START and hold SCL low. This allows the chip to wake up from sleep mode or whatever else it needs to do before responding.

nb. In theory any clock pulse can be stretched by slaves, not just START.

[Mike Warren]

Is it normal to call this buss "I two C"?

I've called it "I squared C" for the last 100 years. (okay, slight exaggeration).

I do work in a vacuum (no other engineers around me) so I can conceive I might have got it wrong for all these years.

[Bud]

Did not like the format and overly fast pace, could only handle the first 3 min, then turned off....will not be watching in this format.

[nctnico]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

A source code comment says it does support it. But it doesn't support multi-master mode.

I found the code and it seems to support clock stretching indeed. What I hate about it is that the all the code is in the header file and the cpp file is empty  IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back 

[enz]

I found the code and it seems to support clock stretching indeed. What I hate about it is that the all the code is in the header file and the cpp file is empty  IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back 

You know the difference between C source code and a C++ class regarding this issue?

[Fungus]

What I hate about it is that the all the code is in the header file and the cpp file is empty  IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back 

In 2017 we prefer all the code in the .h file and no .cpp file at all.

Some IDEs even insist on it.

[madires]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

A source code comment says it does support it. But it doesn't support multi-master mode.

AFAIK, there are two clock stretching variants, i.e. inter-bit and inter-byte.

[coppice]

Is it normal to call this buss "I two C"?

I've called it "I squared C" for the last 100 years. (okay, slight exaggeration).

I do work in a vacuum (no other engineers around me) so I can conceive I might have got it wrong for all these years.

In a vacuum nobody can hear what you call it. Outside a vacuum, "I squared C" was the original official Philips naming, and its still what the great majority of people say.

[nctnico]

I found the code and it seems to support clock stretching indeed. What I hate about it is that the all the code is in the header file and the cpp file is empty  IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back 

You know the difference between C source code and a C++ class regarding this issue?

What is the use of having a cpp file if it is empty? Also the cpp file is the one that gets compiled which is why you should put code into the cpp file and the definition in the .h(pp) file. If you look at how the compilation process works then you'd see that a .h file gets concatenated with the .c(pp) file before the c(pp) file gets compiled. Ergo every piece of code inside a .h file gets compiled for each file it is included in. That isn't very efficient!

Another point is that a .h file with a class definition and code combined doesn't make it easy to read which members the class has.

[Fungus]

Does the proposed code support clock stretching? From what I've seen from the video it doesn't seem to do so. To support clock stretching you'll need to wait until SCL actually goes high on the I/O pin.

A source code comment says it does support it. But it doesn't support multi-master mode.

AFAIK, there are two clock stretching variants, i.e. inter-bit and inter-byte.

It's all the same.

Any time the master releases the clock line a slave is allowed to hold it low and the master must wait for it go high before continuing.

[niekvs]

What I hate about it is that the all the code is in the header file and the cpp file is empty  IMHO that is very bad coding style. The header file should describe the interface and not contain any code! Where did David learn to program? He should ask his money back 

In 2017 we prefer all the code in the .h file and no .cpp file at all.

Some IDEs even insist on it.

Define "we"? And could you give your reasoning behind this, and why "in 2017" this is preferred, according to you? Which IDE's insist on this? Defining functions in the .h file implicitly inlines them, meaning your object code - should your compiler comply with this hint - gets copies of your functions wherever they are called. Now, this doesn't seem like a very good strategy, particularly in embedded development where space is generally at a premium. It can be done for very short functions, where the overhead of the call is larger than copying the function, or if you're working on some performance-critical part. But in general, function definitions should go in the .cpp file. Also in 2017.

In case you're joking and talking about the Arduino IDE: at least this isn't advertised as "C++", and note that viewers of something called "EEVacademy" may miss your sarcasm and actually implement your 'advice'.

[Fungus]

Define "we"? And could you give your reasoning behind this, and why "in 2017" this is preferred, according to you?

a) Within a compilation unit, I know at least two IDEs that are very unhappy if you include anything that doesn't have a ".h" extension. Apple Xcode and Android Studio. Visual studio also frowns upon it - the autocomplete doesn't suggest anything that doesn't have a ".h" extension if you start typing #include.

b) If there's more than one compilation unit in your project then code like that should be wrapped/abstracted, it shouldn't be exposed everywhere. This means the code will be #included within a compilation unit's ".cpp" file and therefore should be in a header file.

In case you're joking and talking about the Arduino IDE: at least this isn't advertised as "C++", and note that viewers of something called "EEVacademy" may miss your sarcasm and actually implement your 'advice'.

If you're going to use "No True Scotsman" as a preemptive strike then there doesn't seem much point in taking this further.

[niekvs]

a) Within a compilation unit, I know at least two IDEs that are very unhappy if you include anything that doesn't have a ".h" extension. Apple Xcode and Android Studio. Visual studio also frowns upon it - the autocomplete doesn't suggest anything that doesn't have a ".h" extension if you start typing #include.

b) If there's more than one compilation unit in your project then code like that should be wrapped/abstracted, it shouldn't be exposed everywhere. This means the code will be #included within a compilation unit's ".cpp" file and therefore should be in a header file.

You said "In 2017 we prefer all the code in the .h file and no .cpp file at all.". Your above points say something very different, regarding some IDEs being unhappy about including files with extensions other than '.h'. Sure, you generally #include header files (.h), not source files (.cpp). Are you saying that because you cannot include '.cpp' files, you have to put your function definitions in the '.h' file? I'm afraid I'm not following. Do you have experience with C++?

To expand on why you include .h files and not .cpp files, it relates to defining and declaring: you can define (non-static) functions or variables only once, but you can declare them more than once. So, you put the definitions in the .cpp file, and the declarations in the .h file. So that, when you include header files (possibly more than once), you don't break this rule.

[jm_araujo]

David in the 'SPI.h' on the repository left only the declarations, the definitions are in 'SPI.cpp'.
At least it could be agreed that there's no coding style consistency.

[nctnico]

a) Within a compilation unit, I know at least two IDEs that are very unhappy if you include anything that doesn't have a ".h" extension. Apple Xcode and Android Studio. Visual studio also frowns upon it - the autocomplete doesn't suggest anything that doesn't have a ".h" extension if you start typing #include.

b) If there's more than one compilation unit in your project then code like that should be wrapped/abstracted, it shouldn't be exposed everywhere. This means the code will be #included within a compilation unit's ".cpp" file and therefore should be in a header file.

I think you got a few things mixed up here! IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.

[hwj-d]

Saw this:
"// yes, yes, yes, this is windows specific and silly"

  

(remember YT comment?) 

[Fungus]

I think you got a few things mixed up here!

Nope.

IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.

For libraries like this one it's much easier to copy a .h file over and #include it in the main file than it is to copy two files over and start messing around with the linker. This is especially true when you need to work on multiple platforms and would need to mess around with the linker multiple times.

Leave the "separate interface and implementation" for big, long-term development, not little projects where you just want to pull a few libraries together as fast as possible. I'll take a big #include ".h" file over "download 50 files along with an out-of-date makefile and try to turn then into a working .lib file" any day of the week.

[niekvs]

I think you got a few things mixed up here!

Nope.

IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.

For libraries like this one it's much easier to copy a .h file over and #include it in the main file than it is to copy two files over and start messing around with the linker. This is especially true when you need to work on multiple platforms and would need to mess around with the linker multiple times.

Leave the "separate interface and implementation" for big, long-term development, not little projects where you just want to pull a few libraries together as fast as possible. I'll take a big #include ".h" file over "download 50 files along with an out-of-date makefile and try to turn then into a working .lib file" any day of the week.

Hmm.. well, if the act of copying files is the main bottleneck in your project, you may have a point. But as soon as you have to use these files, it will quickly become a problem. For one, as I already mentioned before, your embedded project will quickly need an MCU with a bigger flash size as the implicit inlining can copy your functions wherever they are called from. Also, in case you need to include these files from multiple locations, you may alternatively run into multiple definition linker errors depending on if said .h file has any definitions outside of the class body.

Basically, giving up good coding practices for the sake of 'easy copying' is a really bad idea. What if your project evolves into something bigger: you want to then split up and rewrite all those .h files and add .cpp files? Maybe for hacking some throw-away stuff together it could be ok, but that's about it.

And your main statement about "In 2017 we prefer all the code in the .h file and no .cpp file at all." is just plain wrong, sorry. If you change 'we' to 'I', then it's fine of course

[nctnico]

I think you got a few things mixed up here!

Nope.

IDE's not wanting to include anything else than .h files doesn't mean code should be in .h files. If you want to use code from a.c in b.c you should link a.o and b.o into a_and_b_linked.bin and not try to include a.c into b.c. I know some programmers do the latter but it is very bad coding practise.

For libraries like this one it's much easier to copy a .h file over and #include it in the main file than it is to copy two files over and start messing around with the linker. This is especially true when you need to work on multiple platforms and would need to mess around with the linker multiple times.

Leave the "separate interface and implementation" for big, long-term development, not little projects where you just want to pull a few libraries together as fast as possible. I'll take a big #include ".h" file over "download 50 files along with an out-of-date makefile and try to turn then into a working .lib file" any day of the week.

See, you are mixing things up! You can copy the .c files from the 'library' into your project and include the toplevel.h file into your own toplevel.h to make it work.

[Fungus]

See, you are mixing things up! You can copy the .c files from the 'library' into your project and include the toplevel.h file into your own toplevel.h to make it work.

It's much easier to not even have a toplevel.h for this sort of work. Just put the 'modules' in .h files and #include them all in main.cpp.

[nctnico]

See, you are mixing things up! You can copy the .c files from the 'library' into your project and include the toplevel.h file into your own toplevel.h to make it work.

It's much easier to not even have a toplevel.h for this sort of work. Just put the 'modules' in .h files and #include them all in main.cpp.

It is not easier but you just aren't at the point where you see this way of working is asking for major problems if your projects get bigger. It also shows a severe lack of insight in how a C compiler works and how to leverage the power an IDE provides. You don't need to concatenate/include everything in one file to make life easy. The way you work the compiler has to compile all the code if you make one change. When working on a big project this can take a while.

[Brumby]

When I first started programming in a commercial environment, it was using IBM assembler on a mainframe.  (Don't worry Dave, I'm not about to claim you can write applications faster in assembler than you can in higher level languages.  You can't.  You can write tight code, fast code in the smallest possible executable - if you are good enough - but you can't write it more quickly.)

What I will say is that, back then, you HAD to be disciplined to have any chance of a practical solution.  The first company I worked for was a national concern with branches across the country - and their entire company database was held on a single disk pack of 70MB capacity.

These days - you have microprocessors that are insanely cheap and can run rings around what was available back then.  Space is not nearly as much of an issue - and efficiency of code is not as essential as it once was.

The bottom line is - for many applications, you don''t HAVE to be disciplined or efficient ... and in those cases, a less than Fortune 500 "one-up compile" approach is quite adequate.

Where you will get into trouble with a less disciplined approach is where you have a complex system of multiple functional units that get used in varying combinations and/or cross platform.  In environments such as that, a structured, disciplined approach is essential.  Could you imagine version control without it?