Це відео не доступне.
Перепрошуємо.
EEVacademy #4 - I²C (I2C) Bit Banging
Вставка
- Опубліковано 20 лип 2017
- Bit-Banging an I²C port with David.
Git link: gitlab.com/Sep...
EEVblog Main Web Site: www.eevblog.com
The 2nd EEVblog Channel: / eevblog2
Support the EEVblog through Patreon!
/ eevblog
EEVblog Amazon Store (Dave gets a cut):
astore.amazon.c...
T-Shirts: teespring.com/s...
💗 Likecoin - Coins for Likes: likecoin.pro/@...
I highly doubt that a beginner in I2C was able to get enough usable data out of this.
Well then the beginner should ask questions for a followup or just re-watch the video a couple times and pause occasionally.
I'd rather watch a long video that explains things slowly than rewatch a short video that breezes through everything 5 or 6 times and still have to consult additional resources to fill in the gaps. Better to do things properly rather than quickly. It's more effective and less tedious. Think about it, what's more boring? Watching the same 10 minute video 5 or 6 times, or watching a 50 or 60 minute video once? If it's too slow you can always increase the playback speed anyways.
@@VoidHalo Yeah this wasn't much of a tutorial once he got to Visual Studio.
A nice intro but he did cruise through the code part. A github of the code repo would be useful.
That code won't work reliably on a fast processor- you need to enforce delays to meet the timing requirement for the bus speed you're implementing.
That code would be in the pin set and read (editted typo) functions. As it is different for each implementation (timing) it isn't in the platform agnostic implementation, a delay in a simulated version would serve no useful purpose unless a slave was also simulated with timing.
The introduction was nice, but then the code writing was really fast and would be helpful to actually talk to a real device. Also might be easier to understand with Arduino code, without all the C++ overhead. And maybe include just stdint.h, then you can use the standard types uint8_t etc., instead of aliasing byte. Last but not least, you didn't implement clock stretching. Most devices don't use it, but the more complex ones might do. This would be something you would see when testing with real hardware :-)
Sorry, looks like clock stretching and the extended address scheme is implemented in the code. But I think multi-master mode arbitration is missing, but I've never seen this in the wild.
Yeah, I might do it I don't know if I can be bothered haha. I didn't setup my library well for multi-master would need some refactoring.
Well done, David. Slow things down a bit if possible and maybe, in the code section, annotate already written code instead of making us watch you write it. While I, as a programmer, enjoy watching it, I can see you explaining the code rather than writing it working a lot better (most people will be lost watching you write it and not listen to what you are saying.)
Beyond that, you did a fantastic job. I actually learned something I wasn't aware of here (which I thought I knew!). Which I always enjoy.
Keep it up!
Yeah seems others agree with you thanks for the feedback, seems like a good idea.
Truth is I appreciate the pace. I appreciate the on screen notes to keep the pace up and minimize distractions. It is possible to slow down playback or replay videos. It's not like you're going to listen to this while driving to work.... Nice work David. Without the pace and confidence this would be "paint drying" level material.
Reminds me of the old-school GM VPW standard for single wire communication in cars. Very nice, intuitive, and robust way of doing things, and properly set up has extremely good noise immunity due to the low impedance of the comm. bus.
people complaining about the speed, should just learn to lower the speed of youtube, I'm a non native english speaker and found this very good, if he lowers the speed the native speakers will probably tell it's too slow.
Thanks for the refresh tutorial by the way, and indeed, no better way to bitbang to understand fully what a certain protocol is doing
Let's have next part with arbitrary control handling. As usually beginners have no problems figuring out how to get I2C working, but when it gets to multimaster operation they get stuck there ;)
Good explanation David,
An interesting thing to do is to hook an LED up to each data line and run the program single step in the debugger - then its quite clear what is going on.
Mike
OUTSTANDING! Clear illustrations. Perfect pace (for me).
Thank you.
Nice video! Well done David - earned your endingscreen :)
he needs a REAL one
This is the second of your videos I have watched and on both occasions I've asked myself the same question...who are they aimed at?
I would say this was way over the heads of anyone without any knowledge of the subject and therefore wouldn't really benefit from it, which is a shame. Its obvious you are very knowledgeable in your field and its fantastic that you are willing to share that knowledge, but at the moment it seems like you are sharing it with those already at a similar level of experience...its more of a friendly chat as you plough your way through your project along with others sitting around you ploughing through theirs. (Like-minded people that would have no need for a video like this.)
I like you Dave, you're an asset to the EEVEmpire, but as to these videos....I'm just not convinced they actually have a target audience.
I found David's explanation and diagrams of how I2C works on a low level very interesting, and I learnt a lot, even though it wont directly effect any of my current work or projects.
I am trying to change the format each time a slow pace video usually comes across super boring and a fast one is hard to understand so I'm still trying to get a decent balance. Thanks for feedback :)
Don't dumb or slow it down. These videos have awesome annotation and a refreshing brevity, especially compared to Dave.
If you are confused, go back a rewatch. Not everything can be taught in 10 minutes; don't skip the prerequisites.
Good approach. Increase that sample size. Looking forward to more videos of yours.
Electronic engineer here and I have used I2C among other networking protocols. I really can't fault this video, it was quick enough that I actually watched the entire thing (and learnt from it!). I use bit banging a lot for controlling devices, but beyond that I simply use function libraries to handle the hand shakes, so I learnt that from these videos. For a novice, I think it covers everything you need to know (theory and practice) because beyond this anything else is device specific. Keep up the good work!!
Hello David. Thank you for sharing your knowledge. We need more people like you on the internet. I arrived here looking to clear up some doubts and your video sort of helped me. Since I am a newbie I got lost on all the C code which is what I was more interested in, but I appreciate your effort. Hopefully you will continue to provide more content for all of us who need to know more about electronics and programming. Best regards.
One potential trap when bit-banging I2C (or implementing an I2C interface in an FPGA, for example): Because the rising edge of the clock/data lines will be very slow (due to the pull-up resistor), there's a lot of potential to read spurious transitions. If you're using a schmitt trigger input then you don't have to worry about this, but otherwise you have to implement slightly more intelligent logic for detecting a low-to-high transition (e.g. watch for the line to be high for a successive number of reads in a row, not just a single low then high)
The animated annotations work very well with the commentary. Nice.
I think most of the problems people are having with the speed of delivery could be addressed by leaving pauses between statements in post processing of the video. This would give us time to absorb what you have just said before having to listen to the next thing. Explaining any new terms during one of these pauses might also help the pace of delivery.
Your videos are improving I think.
So in essence: Please wait for our ACK :P (That is, if I got that bit right ^^')
I think, it would make more sense, to start the coding-example from the beginning and not to change an existing SPI one.
Changing the SPI one adds one additional thought-process, while following your example, that is more confusing than informative.
And I agree with some other commentators: I would help, if you would slow down your UPM ("utterances per minute") and IPM ("information per minute") a little bit ;)
DaveCAD is getting better over time
Thanks for the video. New to electronics, trying to learn as much as I can, The problem I am having with videos like this is, what is a I2C master and slave. Have some examples of what these are would be great. Being new to electronics and seeing that this part and that part are using I2C would be very helpful. Having real world examples and problems to show puts what you are showing into context.
Have a day
Good crack at it! I'm a serial newb and I learned something, so I'm glad I watched it. The real-time markings were a great visualization tool, the terminology was well explained, and the I2C behavior was well explained from start to stop. ;)
One strategy in teaching is to start with an objective, better yet a question, presented to the audience that you then work through: it helps the audience with context as they're otherwise focused on understanding each step. The big picture is the most important thing viewers can walk away with! (Hopefully it empowers them to find smaller details as needed.)
Similarly, as people are complaining about the pace of this video--I would say the underlying problem is scope. There's a lot of good stuff covered but what did you /really/ want to talk about? An exposition of I2C, a sample bit-bang, caveats/applications, etc. A better question is: what did you want the audience to take away from your lesson (the objective)? A good answer to that question will refine your curriculum and it will be much easier to explain without feeling rushed.
I had these same issues when I started education (I'd end every lesson panting) but if you thoughtfully keep at it I'm sure you'll improve, if that's your goal!
Great videos. Really nice to see the theory and then the actual code in practice. Love to see some more of these.
Don't listen to anyone's comments. You're doing great. Some people blame their own incompetence on the methods of the 'new host'.
Informative and enjoyable, plus that photo at the end concreted the passion you put forth.
Very nicely done, David.
You should let Dave^2 to do more videos like that.
Engineers love "cheats and shortcuts" if there is better way to do it.
For the people complaining about the speed, you could slow the video down?
When listing to the Amp hour and Embedded podcasts I ramp up the speed to 1.30 (enough fast for me as a foreigner) so I could have more spare time afterwords to check books, code and people on the shows.
IRL you cannot do this but in the digital world = YES WE CAN.
Good job Dave^2 and Dave, now do CAN protocol and do embedded tutorials for beginners.
The beginner stuff for embedded is always hard (from what MCU to use to in what and how to write it)
I would love to do that but I don't know how i can make it appeal to everyone (or even a large number of people), doesn't seem that I've got the hang of teaching these concepts to a broad audience yet.
I was hoping to do CAN, USB, Ethernet, WiFi, Bluetooth, BLE and UART. I might have to describe things at a higher level of abstraction to make it more broad appeal.
It should be noted that other I/Os can have resistors too, but they are not used for open-drain lines, but instead used for weak pull-up or pull-down. For example, a circuit may pull-down an enable pin so that they device may not be active on boot while the MCU or FPGA is being initialized.
i was always hesitant to implement i2c on my own, now ill give it a try. thank you
Fast mind, fast speech. Cheers Dave - really revise the protocol.
i really like these I2C birbanging tutorials
You don't have to mask the address before shifting it left. Maybe assert that the address is within the range but the mask is a no-op.
I actually think it was quite the correct speed. You introduced concepts rapidly and explained the core parts with easy to understand drawings. Good work.
I agree!
I also agree. Just for once, someone who moves along, and does not repeat himself over and over (like you-know-who). Perfect pace. Never had to nudge the scrubber forward.
1GB talk speed, very fast speaking system :), pls. slow down Dave . . .
Excellent. Really good overview of IC2. Thank you. Saved a good hour with my head in a book.
I was expecting different content with the video title (something like how to do i2c bit banging with an arduino.. ugh). However, I was positively suprised with the actual content, which is more of a broad and comprehensive video about i2c. I guess with a better title, you could get more audience :-)
EDIT: Extra Nice content from the middle. Whoa is that C++11 on Microcontroller? Finally someone is doing it :-)
I kind of preference you and Dave just hanging out and being creative trying to build or make something. These tutorial things would belong more on an electronic training course, whereas UA-cam works better as more creative and fun. There are so many projects you could show us as you design, develop, build and it wouldn't sound so forced.
32k gyro's are getting more common on mini-quads, the newer F4 processors pretty much all have them :)
I wrote my I2C routines in Z80 assembler. There's no minimum speed it will run at as I was able to single step through my code to check everything was working correctly.
Thank you for this informative video. I think you could slow down the pace a bit though.
I didn't have a problem with the pace (thanks to the illustrations) until you started coding. Didn't understand a thing there apart from the idea to make the code easily adaptable to any platform.
This was really well done. I do agree with the other commenters who think it was a bit fast. To add my constructive criticism , I think the pace was fine for someone who's more used to the information. +EEVblog the only big thing I would add with these types of videos is a sheet of notes or an outline with the slides in the description. I feel like the type of pace your colleague went at in the video was more akin to a university lecture ,but notes would be nice to go along with it.
I need to add, the bit bang section went by too quickly .
This is not targeted at the complete fresh meat, like everyone complaining expects..
If youre watching this you are expected to have tried and failed in some way.
Thanks for this example. Could please make a video for one wire bus- bit-banging ? Basically, I am looking for examples to read data from DS18B20 using BG22 in simplicity.
Great tutorial, good scope and detail. (Greetings from Forestville)
Good pace. Love the format.
excellent work !
I'm a electronic newb and I was able to perfecly follow. Great structure of the vid. mate.
Holy cow, thats what i call pure information. Very informative, and also too much for that amount of time. Need to flush everything into my brain
I enjoyed it. It more confirmed what I already new. Unfortunately lost me in the C++ example but that's my bad. Thanks David good job
This is excellent stuff, but... The code part is just impossible to follow. I would have to slow it down and play through several times. This is a great demonstration of your speed and knowledge but not good teaching. I have seen this so often with young guys teaching at Unis. I assume they just have a different perception of time but it's like having a conversation with someone on speed at a party. It becomes stressful and impossible to follow. I do love the idea of this thread but this speeding issue has been mentioned by others and I think it merits some consideration. Thank you anyway. I do really appreciate the effort taken here to educate.
Yes i think your right about the pace. I will be trying to improve, would appreciate continued feedback this type of comment is helpful to me.
Part of the problem with the code was how jumpy it was. Was the video here constantly clipped and stuck together?
What a great video!
WOW!!! , your good. . . . . . It is rapid fire and sketches are a very slightly tiny bit sketchy but "I WOULD NOT CHANGE A THING" , In general I don't have time to view the slowed down, drawn out, finely polished versions and if you were to take time to do those slowed down drawn out polished things you will then only produce 1/2 as many of the very very very educational/interesting mini tutorials , . . . . did I remember to say WOW!, did I say 'very'?
This would need to be written in AT&T assembler for the chip chosen otherwise it would take for ever as interpreted languages are very slow so AT&T assembler for the chip is a must.
Really nice description and video. Learned a lot. I don't get much from watching you write the code, but the explanation is nice. Perhaps consider skipping recording yourself typing.
I wonder if there are other protocols that send the address, send how many sets of 8 bits to expect, and then send the data.
Awesome! Could you please tell me which books deal with this topic? I happen to need to do a development with ESP8266 and I2C acting as multi-master
So now we have good evidence that only people named Dave may upload videos to this channel...
hey! that's my motherboard! but i have the micro atx version. 785g chipset
Gotta slow down the pace a little. I would have to watch this multiple times to get what I want out of it. Also I was hoping for a logic analyzer discussion like you had with the SPI Bit Banging short tutorial not just an Excel view of it.
Thanks for your explanation.
Could you make something similar to read 9 bits serial data in arduino mega 2560 ?
I am trying to read 9 bits serial data, but in the uart ports for arduino mega 2560, I have understood that we only can read 8 bits serial data.
I will appreciate your example and explanation.
Thanks in advance.
Regards
The Bit Bang Theory !
perfect video!
Good stuff and informative video. Thanks.
Thanks David, really helpful!
honestly I've found the "live" coding session really confusing. It's not that it's too fast... but the recorded audio doesn't follow what it is shown on video. Also it would be better to start off with a blank page instead of modiftying a code template.
Noted thankyou!
BTW I forgot to thank you for all these informative video lessons.
I can't realize what does double transitions on the same diagram mean? When SDA goes high and low at the same point and is high and low after it. 3:20
That is a way that indicates that the line could be either high or low, both states are valid.
Great video!! ... any chance you can make a few videos on your Dev environments and your setup and use of Visual Studio with programming embedded devices... also any troubleshooting/debugging tricks you may have?
Maybe on EEVBlog 2, wouldn't be on 1 though. Not a programming channel, I would also need sufficient interest.
I2C & SPI are about as simple as it gets. How about something more advanced now, like bit banging USB 1.1.
I've read the whole USB Standard book, big banging USB is on another level, there's a book keeping part in USB that will be complex to implement and to show on a 10min video.
rocketman221projects the 2 problems with USB is that it adds a lot of overhead to the data being transmitted and it uses some kind of weird differential analog signaling.
Just realized my programming skills are lacking.. I usually just use the provided libraries but this is very good
Thank youuu!!
The title somehow made me expect a dave2 banging his head on a breadboard to make lights blink...
Why BIT bang while almost every microcontroller has a hardware I2C interface?
Do you have an excel macro that outputs what you see at 10:21 based on the data? Or did you do that manually?
Dave, please turn down David's clock speed. The lad is too quick for me rotten aulde brain!
Lols like the end splash screen
Thanks David! Would you be able to do something on JTAG? I'd like to flash new firmware in to a device, but back up the existing firmware and settings first. Thanks!
Hey there, David! Could one use a constant current source as the pullup? Thanks.
Interesting idea, yes I suppose assuming it saturates at a sensible level.
Why?
People are used to watch 45 minutes videos of Dave. So don't make 10 minutes videos which has 25 minutes worth of materials just because you feel like they are boring. If someone wants to learn these concepts they will put the time in.
Well,it seems like a need to read a bit more.
Where was the MCLR again?
The code section goes really fast and you move around really fast. If it were slower it would be easier to follow.
I liked the Dave's approach better with the white board and always learned a lot even if the subject is new to me. But I cannot say the same for this one. The introduction of subject was too general and insufficient. There was no way of fallowing the code because everything happens too fast. The only thing I got from the video is, there are two pins, there are start and stop bits, and MC waits for the response of the other device...
public EEVacademy(script , fear , opinion){
if (script && fear == 1){
cout
class David {
int version;
public:
David();
David(int v);
int get_version() {return version};
} ;
David::David() {
version = 1;
}
David::David (int v) {
version = v;
}
int main () {
David Dave(2);
if(Dave.get_version() != 1)
cout
You sir! YES!
I tried playing it at half speed but Dave2 become Dalek2.
Maybe thats(Dalek speed) my normal speed :|
BITBANGING is the best banging
please don't show this my girlfriend
Thank you!
I want more:)
We saw on the spreadsheet that there wasn't an ACK received. So in this case, why did your code continue to send data?
I cannot remember but I think i made the ack function always return true (that doesn't affect the actual line value).
Bring the pace down a little. Concentrate on only the parts where it is really needed too much info.. to little time.
Manu Krishnan or you could just slow down this video through setting and set the play time down to 0.75
I tend to look at how people attempt to learn stuff and if they do something better, I try doing it their way. No video is going to match getting your hands dirty and doing things yourself. Take pointers and do it yourself. Don't ask people to slow down or simplify the content if you can't keep up, if you do so, they might stop enjoying teaching you.
Yeah, totally agree with Manu - please David slow down little bit! :)There are a lot information in this vid you could be more specific. Anyway, you deserve the thumbs up! Thanks!
Mohit Mohan but we all need a piece of pie right? And we all are lazy to go again the video again since there are many tantalizing suggestions by you tube. What I said was to slow down the pace a bit and concentrate on the bits which are interesting.. iho
Don't slow down. The point of a video is that you can watch it more than once and even pause it
good explanations but given way too fast... calm down a little bit and it will be much understandable ;-)
Very interesting
Ok I have heard about this want to know anything about this I am totally lost did not understand way to fast for me I will look for a noobs look at this subject
Dave2, which tools are you using (Software and hardware) to create this video ? Thanks !
Drawboard, Camtasia, Visual Studio 2017, Libre Calc :)
Thank you.
Nice tutorial, more of that please :-)
where have I seen that final image before.... hmmm
where is the other dave?
Much better than your first tutorial, but still too fast. Your code-explanations are out of sync with your actual code changes and while it is impressive to see such a fast coder as you are at work, it would be impossible to follow you there.
The explanation of the I2C bus itself was very good. Perhaps you should have concentrated more on this part alone. And while the 10bit addresses are a special case of little interest, things like clock stretching by a slow slave are perhaps more important - did you implement these in your code?
My GitCode includes provisions for clock stretching and 10bit addresses, should be linked on monday ( Work week start. ).
Funny screen. You counted from zero as Human, so it's 128 devices.
Address 0 is actually reserved for a general call.
There are actually a few reserved addresses but thats the most critical and most supported ( i think, no real evidence here ).
It appears so :) I've only used EEPROMs on I2C, where you only get to vary the last 3 bits.
Your looking younger Dave.
i was like, who is this, and then check the name, oh not dave
I2c Is CAN?
When your bit bashing this shit how do you get the timings right?
I'am alone who lost around 8:00 ? :)
Novice here, I think demonstrating this with an actual project would be better. Theory of operation is great and helpful but watching a expert tinker with something they've built or watching them hack an existing system is far better once you have the basic operation under your belt. The first part was exactly that, then we watched a bunch of SPI code get converted I2C (why show that?) and then interact with no device. Obviously, you understand bit banging to the degree that it is second nature to you but unfortunately, teaching the uninitiated is a more painstaking process and should not include sped up vid of coding that was not even initially setup for the purpose at hand. It just adds confusion to an already complex topic. Just my two cents.
'Oh' or zero?
Do LIN next! With the checksum! Pleeeeeeeeeeeeeaaaaaaaaassssssssssseeeeeeeeeee!