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.
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.
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.
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)
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.
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 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.
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
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!
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.
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.
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 ;)
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
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
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 ;)
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!
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.
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.
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.
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 .
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 TH-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.
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?
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!
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.
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!!
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.
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.
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.
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
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 :-)
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.
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'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.
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.
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.
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.
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 is giving me flashbacks of my school days. The parts when we had to listen to the other kids do presentations. At the end I usually learned nothing about the subject.
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 ).
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
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...
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.
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?
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
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
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.
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.
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.
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)
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.
Nice video! Well done David - earned your endingscreen :)
he needs a REAL one
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.
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
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.
OUTSTANDING! Clear illustrations. Perfect pace (for me).
Thank you.
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.
i was always hesitant to implement i2c on my own, now ill give it a try. thank you
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.
Fast mind, fast speech. Cheers Dave - really revise the protocol.
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 ;)
Great videos. Really nice to see the theory and then the actual code in practice. Love to see some more of these.
Informative and enjoyable, plus that photo at the end concreted the passion you put forth.
Very nicely done, David.
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
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.
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
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 ;)
Excellent. Really good overview of IC2. Thank you. Saved a good hour with my head in a book.
i really like these I2C birbanging tutorials
Do you have an excel macro that outputs what you see at 10:21 based on the data? Or did you do that manually?
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!
Good pace. Love the format.
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.
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 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.
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.
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 .
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 TH-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.
Great tutorial, good scope and detail. (Greetings from Forestville)
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.
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
I'm a electronic newb and I was able to perfecly follow. Great structure of the vid. mate.
Thank you for this informative video. I think you could slow down the pace a bit though.
Don't listen to anyone's comments. You're doing great. Some people blame their own incompetence on the methods of the 'new host'.
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!
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
1GB talk speed, very fast speaking system :), pls. slow down Dave . . .
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!!
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.
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).
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.
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
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?
Dave2, which tools are you using (Software and hardware) to create this video ? Thanks !
Drawboard, Camtasia, Visual Studio 2017, Libre Calc :)
Thank you.
32k gyro's are getting more common on mini-quads, the newer F4 processors pretty much all have them :)
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.
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.
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
excellent work !
So now we have good evidence that only people named Dave may upload videos to this channel...
Just realized my programming skills are lacking.. I usually just use the provided libraries but this is very good
Why BIT bang while almost every microcontroller has a hardware I2C interface?
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 :-)
What a great video!
Well,it seems like a need to read a bit more.
Where was the MCLR again?
Thanks David, really helpful!
The title somehow made me expect a dave2 banging his head on a breadboard to make lights blink...
Good stuff and informative video. Thanks.
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?
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.
The Bit Bang Theory !
where have I seen that final image before.... hmmm
hey! that's my motherboard! but i have the micro atx version. 785g chipset
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.
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.
where is the other dave?
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.
perfect video!
Thank you!
I want more:)
I'am alone who lost around 8:00 ? :)
The code section goes really fast and you move around really fast. If it were slower it would be easier to follow.
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.
When your bit bashing this shit how do you get the timings right?
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 is giving me flashbacks of my school days. The parts when we had to listen to the other kids do presentations. At the end I usually learned nothing about the subject.
I could barely stand Dave's voice but this guy is the total opposite, almost monotone.
I was slowly getting used to Dave.
I tried playing it at half speed but Dave2 become Dalek2.
Maybe thats(Dalek speed) my normal speed :|
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.
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
I2c Is CAN?
Nice tutorial, more of that please :-)
Dave, please turn down David's clock speed. The lad is too quick for me rotten aulde brain!
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...
Thank youuu!!
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.
BITBANGING is the best banging
please don't show this my girlfriend
Lols like the end splash screen
good explanations but given way too fast... calm down a little bit and it will be much understandable ;-)
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. ).
i was like, who is this, and then check the name, oh not dave
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!
'Oh' or zero?
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
Your looking younger Dave.
Less coffee, perhaps?
Very interesting