Finishing up on the topic of CMOS bus logic I am going to show a couple of families with unique properties that may come in handy one day.
High Voltage Tolerant Family: AHC/AHCT
Note the missing diode to VDD
First up is a CMOS logic family AHC/AHCT that has one of the protection diodes on the input removed. This allows a 5V input voltage to be applied to a device powered by 3.3V so that I don’t have to add a gate just for the translation. Any time I can translate and do it without any additional gate delays I am a happy engineer.
Of course the example above works in a single direction and bidirectional does start to get more complicated. Using a bidirectional buffer such as a 74AHCT245 will work for TTL translation when going from 3.3V back to 5V providing there is a direction control signal present.
Every year, more than 30,000 people are killed in motor vehicle accidents in the US, and many many more are injured. Humans, in general, aren’t great drivers. Until dependable self-driving cars make their way into garages and driveways across the country, there is still a great amount of work that can be done to improve the safety of automobiles, and the best hope on the horizon is Vehicle to Vehicle communications (V2V). We keep hearing this technology mentioned in news stories, but the underlying technology is almost never discussed. So I decided to take a look at what hardware we can expect in early V2V, and the features you can expect to see when your car begins to build a social network with the others around it.
With the summer’s big security conferences over, now is a good time to take a look back on automotive security. With talks about attacks on Chrysler, GM and Tesla, and a whole new Car Hacking village at DEF CON, it’s becoming clear that autosec is a theme that isn’t going away.
Up until this year, the main theme of autosec has been the in-vehicle network. This is the connection between the controllers that run your engine, pulse your anti-lock brakes, fire your airbags, and play your tunes. In most vehicles, they communicate over a protocol called Controller Area Network (CAN).
An early paper on this research [PDF] was published back in 2010 by The Center for Automotive Embedded Systems Security,a joint research effort between University of California San Diego and the University of Washington. They showed a number of vulnerabilities that could be exploited with physical access to a vehicle’s networks.
A number of talks were given on in-vehicle network security, which revealed a common theme: access to the internal network gives control of the vehicle. We even had a series about it here on Hackaday.
The response from the automotive industry was a collective “yeah, we already knew that.” These networks were never designed to be secure, but focused on providing reliable, real-time data transfer between controllers. With data transfer as the main design goal, it was inevitable there would be a few interesting exploits.
For many hardware enthusiasts, it’s hard to stop imagining the possibilities of an almighty fablab in our garage — a glorious suite of machines that can make the widgets of our dreams. Over the years, many of us start to build just that, assembling marvelous workbenches for the rest of us to drool over. The question is: “how do we get there?”
Ok, let’s say we’ve got a blank garage. We might be able to pick up a couple of tools and just “roll with it,” teaching ourselves the basics as we go and learning from our mistakes. With enough endurance, we’ll wake up ten years later and realize that, among the CNC mill, lathe, o-scope, logic analyzer, and the graveyard of projects on the shelves–we’ve made it!
Image Credit: [Rupunzell] on EEVBlog
“Just rolling with it,” though, can squeeze the last bits of change out of our wallets–not to mention ten years being a long journey while flying solo the whole time. Hardware costs money. Aimless experimentation, without understanding the space of “what expectations are realistic,” can cost lots of money when things break.
These days, the internet might do a great job of bringing people together with the same interest. But how does it fare in exchanging the technical know-how that’s tied directly to tools of the trade? Can we get the same experience from a chatroom as we might from a few minutes with the local ‘CNC Whisperer’ who can tell us the ins-and-outs about tuning the machine’s PID controllers?
I’d say that we just can’t. “Getting started” in any subject often seems daunting, but we’re at a compounded disadvantage in that the gurus on the forum have some shared implicit knowledge and jargon on the subject that we wont have if we truly are taking our first steps. (Not to fear, though; none of us were born with this stuff!)
Ruling out forums for taking our first baby steps, where can we find the “seasoned gurus” to give us that founding knowledge? It’s unlikely that any coffee shop would house the local hardware guru sippin’ a joe and taking questions. Fear not, though; there are places for hackers to get their sustenance.
When you are a hardware guy and you live in a time of crisis, sooner or later you find yourself working for some casino equipment company. You become an insider and learn a lot about their tricks. I’ve been in touch with that business for about 30 years. I made a lot of projects for gambling machines which are currently in use, and I had a lot of contact with casino people, both owners and gamblers.
Now I’m sure you expect of me to tell you about the tricks they use to make you spend your money. And I will: there are no technical tricks. This isn’t because they are honest people, but because they don’t need it. Mathematics and Psychology do all the work.
Does the risk of gambling pay off? Mathematically speaking, no – but it’s up to you to decide for yourself. One thing is for certain – whether you decide to gamble or not, it’s good to know how those casino machines work. Know thy enemy.
Working with embedded systems usually involves writing code which will interface with hardware. This often means working on the register level. It doesn’t matter if we’re talking about a UART, an analog to digital converter, an LCD controller, or some other gizmo. Sooner or later, you’re going to have to break out the datasheets and figure out how to talk to an external device. To succeed at this you must become a master of bit manipulation.
Hardware designers don’t like wasting space, so modes, settings and other small pieces of information are often stored as packed bits. Our processors usually access things a byte (or a word) at a time, so what is the best way to handle this? Like so many other topics in software engineering, there are multiple ways to skin this cat. In C (and its derivatives) there are two major options: shift and mask, and bit fields.
Generative design is a method of creating something by feeding seed data into an algorithm. It might be hard at first to figure out how someone would build a business around this, but that’s exactly what Nervous System has been doing with great success. The secret is not only in the algorithm, but in how they’re bringing it to life.
![Image Credit: [Rupunzell] on EEVBlog](https://hackaday.com/wp-content/uploads/2015/08/eevblogrupunzel.jpg)
