But in computer science theres no "Happy little accidents" errors might cause a disaster.

"Happy little segmentation faults"

Dude, that's exactly what I thought of as he casually laid down his first blue wire, perfectly cut to length. "And... we'll just add some happy little wires here..." Mr. Eater, the amount of planning you must do to make it look so easy is formidable!

Some nice exceptions.

MrSumkinFedor I don't know... an out of frame switch seems like one of those 'happy accidents' to me ;) -Jake

if he made a cpu and a basic web server internet in the same year (2017-2018) that is super super freaky that is literally my 2 big projects i have been doing

Samuel Miller that would be super fascinating 😍

Next up: TCP/IP, routing, How to design a web-server in 8-bit assembly, and an embedded HTTP server entirely from logic gates and transistors!

Samuel Miller funny, I also worked on some pc and OSI model simulations 2 or 3 years back. To see Ben make videos about both really brings back memories. Its basically a practical implementation of the course I followed called Computer Architecture and Networks.

That's preparation for when the government starts to control this internet.

ZecoRho you can get kits with various lengths, he probably picks from those

@@QualityDoggo In other videos, the wires are also perfectly prebent.

and he did all that programming with only one goof up, missing a period :-)

It's called editing ;)

The errors he makes along the way are also prepared in advance, I'm guessing. The guy is very skilled, but he also goes in depth enough so that a newbie can get into the videos, understand them, and avoid common pitfalls. Really great vids.

Ah, I guess KZfaq doesn't do error checking either.

@GWigWam Explains the comment sections under some videos.

@@SugarBeetMC what do you mean??

how the hell did you do the three stripes!

@@--_9623 the comment section is not so grammar friendly

Opened the Logic Gates of Hell?

DOOM!

He is our own Tech Teddy.

Yes

I love the way he introduces a problem, calmly explains what to be expected, and how close everything is to reality (not just in an academic way). Then he presents us with a solution and an explanation on why/how it works. These videos are really educational and informative, and he's truly a great professor!

I also finally understand bit shifting and feel mindblowww. He is the best!

Actually keeping the compiler errors in the video is probably the closest thing to reality!

Now wrap your head around this one: en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code

which part of the video did bit shifting "shift" your sense?

XD

well , what would you use if not an led light , an led screen is too complex to set up to be used for this purpose

sort of, but if electrical engineering was a language, I think it would be C++, because electrical engineering is by no means a scripting language, so LEDs are more like: std::cout

@@maskedredstonerproz Buzzers are fun

😁

??

;

@@tdplay4135 ;

@@trubiso ;

@@someonethatlive8632 ;

Toncho 1 I could not have said it better.

It's not just you. Ben has a gift of conveying knowledge in a really accessible and engaging manner. Even though I know much of the stuff he's talking about I still find his videos very interesting.

Completely agree. It's not just the content. His delivery of the subject matter makes the difference. I've been an Electronics Technician since 1974 and have seen only a VERY small number of tutorials that match the quality seen here.

It's actually not that hard. The extra processing required (in the loop) on the receiving can arbitrarily take too much time, whereby the receiver is getting only part of the signal, therefore the bits are a little off, and then you get jumbled characters.

@@codetutor6593 I love stuff like this. I've watched some more videos and all of this is making much more sense. I was initially making fun of the garbled characters, but i think i understand why that happens now.

@@foxroulette8016 Good for you. When you see the theory put into practice it's mind blowing. Happy creating!

@@codetutor6593 indeed! Thanks, you too!

woah same, I'm just an experienced software engineer and haven't really messed much with hardware but I somehow knew where and why stuff will break :^)

same here :)

I was expecting to see some phase locking of the timers each time the NRZ state changed, or some oversampling or some other asyncronous tricks. But nope, just a clock line.

@@jnevercast It's a basics video looking at the fundamentals. There has to be some limit to the scope!

No sh*it!! xD

Marriage.

OMG I'm DYING

Omg😂😂😂

ha ha ha. genius !!

DasIllu woah that's really interesting. How old were you when you figured out to do that. Way to think outside of the box

Perfectly cut and bent jumper wires*

You write "Hello World"... while Ben builds an HTTP server out of logic gates. xD

Patryk 2005 They definitely need reinventing, certainly at present they are an amalgamation of patches and add-ons to stuff that is donkeys' years old

Wait so to get the hardware you already own to work fully you need a key?

Using the method shown in the video is good for illustration purposes, but, you'll be much better off using SPI/I2C protocols. It's much easier to use and a lot more reliable. Not trying to discourage you from building your own transmission protocol from scratch, it's a pretty awesome thing to do. It's just that your comment "they wouldn't work as I wanted to" made me feel like you tried using the inbuilt functionality and failed, and now think that they are not capable of proper reliable transmission. That's not the case. SPI and I2C are specifically made for communication between multiple devices. Thousands of engineers have worked on building those protocols so there is not much that they can't do in their domain of functions. So yeah, building your own communication system is cool and good for understanding the basics, but, at the end you are much better off using the already in use protocols.

Oh, I didn't try to use the shiftIn/Out functions, I just looked the code of what they actually do and it's kind of what I want but not exactly. My idea was to 'create' my own protocol, I don't have the idea completely structured yet, that's why I try to avoid (in a certain way) SPI (or other serial protocols). Maybe it's the idea of having complete control over what I do bit by bit? I don't know, I'll probably end up copycating it or something :d

Just use the UART - you can combine multiple serial data sources into one with a simple AND gate. So long as only one ever transmits at a time, you will need a protocol to avoid or handle collisions.

For multinode networks, use CAN !

Use I2C if you need to communicate with multiple Arduinos with the least among of wires required, since the serial protocol is build into it. Define the addresses of the slave Arduinos, and use your master Arduino as the main one to communicate with them.

Its not quadratic, only two times the length of the message. And the code is more readable for people not familiar with pointers

@@b4l1x the condition is re-evaluating every time, including computing the length, which is in the order of the length of the string if the compiler didn't optimise (which many do for strlen)

Ben, this is a great video. I did something similar when I taught a data communications class as a clinical/adjunct professor. Your demonstration is better than what I did. I was looking for this thread; I spotted this issue when I watched this morning. Ted, you are completely correct. As written, this code fragment is O(n^2) in the length of the message. However, might I suggest for pedagogical purposes (many viewers don't have our experience): msg_len = strlen(message); /* Could be written as: for(int byte_idx = 0, msg_len = strlen(message); byte_idx .... ) */ for(int byte_idx = 0; byte_idx < msg_len; byte_idx++) { char tx_byte = message[byte_idx]; } Balazs Oczot, unless the compiler did the above optimization, this fragment is, indeed, O(n^2). C _guarantees_ that the conditional in a 'for' loop will be evaluated every iteration. strlen() determines the length by marching along the string searching for the null character, '\0', that marks the end of a C string. So, finding the length of the string is O(n). Because the for loop is executed n times and at each iteration the length of the string is calculated, this fragment is, as Ted stated, O(n^2). Your point regarding pedagogy is well taken. Simon, you are absolutely correct. I worked for a large, well known company, as an industrial mathematician doing queueing theory and performance engineering. A large project was nearly cancelled because it didn't meet performance requirements. None of the software engineers could find the problem. I never knew the exact details, but I guess perhaps 50 staff-years of work ready to be flushed down the toilet. One of my colleagues and I were given the task of finding the problem, else the project would be scrapped. It turned out that this exact problem, buried at the bottom of several nested loops, was the culprit. After fixing this, just as above, and recompiling, the project went from failing abysmally, about sixty times slower than required, to exceeding the performance requirements by about 50%. I often wonder how many projects are saved today simply by throwing more or faster silicon at it, rather than finding the root cause. Be well & Best regards, Gottfried

Just XOR the clock and data!

Apparently all he had to do was interrupt their thinking process.

With the clock, this design will be error free up to rates well above the speed of an Arduino. That is, if I removed the delays altogether, you'd just see the correct message appear "instantly" (at least to the eye) on the other side. The "natural" errors I mentioned start to show up in wireless communication (where there's more interference) and at very high bitrates (multiple millions or billions of bits per second).

Ben Eater Makes sense, excited for the next video!

You could also introduce errors by adding noise to the transmission line. This could be done by a white noise generator and a restive adder circuit. By adding noise and messing with different coding schemes, you can attempt to get close to the Shannon limit of the channel.

I ran into errors at around 2KB/s with a raspberry pi