EEVblog #1306 (5 of 5): Spooky Action - Hardware Testing

Spooky action at a distance!
Something doesn't go quite right with testing the programmed Padauk 3 cent micro.
5th and final part in the Padauk 3 cent micro Free PDK video series.

#Spooky #Hardware #Testing

Support the EEVblog through Patreon!

Buy anything through that link and Dave gets a commission at no cost to you.

Donate With Bitcoin & Other Crypto Currencies!

[kstxevolution]

regarding the format: I love the idea of play along with Dave. It does more to expose the traps for young and old players and as a teaching tool, it's nice to be able to see you fumbling around and fiddling with stuff and maybe chase the odd red herring or two. it does wonders to expose your thought process and it helps me figure out if I'm thinking about something from the wrong angle

[efa]

Ben Eater: Gotta make sure all my wires are neat so my breadboard looks nice on camera

Dave: haha electricity go

[Herby-]

This series is a "Learn with Dave" and is VERY instructive. Everyone lears from mistakes, and learning from others mistakes is good too, so we won't repeat them. Maybe episode 6 of 5 will show the final "Hello World" ASCII version someday. If this works out, we will learn from the problems encountered in doing "real world" stuff. Excellent series!!

[TheHuesSciTech]

At 10:00: the -Dwhatever option typically (and I checked, is indeed the case for the SDCC compiler) defines preprocessor macros. So, it only has any effect if the C source code (or includes thereof) has #ifdef lines specifically checking for it. I would bet some money that the generated IHX file was completely unmodified by adding the -Dwhatever option. Also, observing that the compiler "accepted" the option is yet another red herring, because it would completely transparently accept -DTROLOLOLOL or anything else. I think this is worth annotating the video with, as if someone else "tries" doing the same thing, it's just a complete red herring (unless the specific source code file has the appropriate #ifdef lines, of course). Also, it would have been good practice to use md5sum or just about anything to check that your IHX file was actually any different from the first, before programming the second chip with exactly the same code.

[sarbog]

I prefer the long format for a project. It shows how "the devil is in the details", your thought processes and the amount of work that others on the forum performed to to make this possible. Very Cool!!!!

[trcostan]

Congratulations on the worlds least expensive Theremin!

[johnnyprimavera]

Thanks Dave! This series is priceless, seeing the fails and successes from programmer assembly to blinky. I appreciate the effort. How many times I have hoped before that someone has done the same setup for a new brand/kind of micro and not falling apart on an unresolved error. Gold, even I'm not interested in PDK I enjoyed it.

[larsandersen]

Hey Dave. You are not finish. You have to make part 6. We want to see Hello world 😅

[MrGoatflakes]

6:36 I knew Dave had the PMS, but didn't think he'd admit it xD

[RubixBy]

The sheer amount of education behind the train of thought at 5:30 that led to the discovery at 6:27 is ABSOLUTELY PRICELESS. Though it may be commonsense in hindsight (it often is), that error would likely be a hard-stop for some time...perhaps indefinitely, for myself and other beginners.

Thank you so much Dave, for the work behind this series. As a CE student, I've realized that debugging something often relies on the hours of frustration you've spent debugging similar issues in the past where you learned some lesson about various modes of failure. Combining intimate hardware knowledge with the details of the code implementation to even know where to begin. I salute you!

[vejymonsta]

Loved this series. I like how it shows that even someone with experience like Dave Jones isn't infallible. Too often the industry devalues individuals for not being perfect. I think this format is great for people getting into engineering, because it shows that it's all about overcoming hurdles. Sometimes... you may not be able to get over that hurdle, and it's not because you are incompetent. We are only ever as good as our tools, and the lessons we learn from one project can be forgotten easily.

[SimonCoates]

Time to release EEVBlog perfume range - '3 Scent'

[Tawnos_]

I think the idea you expressed @19:00 would make this awesome - a live "here's where I got stuck along the way" walkthrough of the process with a trimmed "here's how to get started and avoid the same pitfalls I hit" at the end.

[TheDefpom]

I think doing a final condensed version of a how to would be good as a reference for people in future.

[DanielLopez-upos]

The whole series is pure awesomeness man, ive loved to see you figure stuff out and point out places that if i were to try id fail at aswell.

[StreuB]

This series is rolled gold, I'm tellin ya. This was fantastic. I know you might not think it will do well or is doing well but I will tell you like I did the other day, this is valuable stuff. Can you add all 5 videos as a published playlist by chance?

[fyfoh]

Good content. This gives a more accurate picture of how engineering projects usually transpire- problems at every turn. If you've only done Arduino projects where all the hard work has already been done for you, this experience would be quite the wakeup. Also, wtf Keysight, include serial. Siglent ftw.

[GoldSrc_]

I like this format, it reminds me about how I had a lot of things go wrong years ago, just trying to get an image to show on an OLED screen using arduino lol.

[meowcula]

the "follow along as things go wrong" is the most educational I find. You end up bumping into all the dead ends and red herrings and such. Ends up being instructive beyond the current project as well.

[joopterwijn]

Dave, love the longer (even multi-part) concept. It is probably more to real live to the majority of your viewers. Also including (and promoting) your Eev-forum is good idea.