Radio Controlled Pacemakers Are Easily Hacked

Doctors use RF signals to adjust pacemakers so that instead of slicing a patient open, they can change the pacemakers parameters which in turn avoids unnecessary surgery. A study on security weaknesses of pacemakers (highlights) or full Report (PDF) has found that pacemakers from the main manufacturers contain security vulnerabilities that make it possible for the devices to be adjusted by anyone with a programmer and proximity. Of course, it shouldn’t be possible for anyone other than medical professionals to acquire a pacemaker programmer. The authors bought their examples on eBay.

They discovered over 8,000 known vulnerabilities in third-party libraries across four different pacemaker programmers from four manufacturers.  This highlights an industry-wide problem when it comes to security. None of the pacemaker programmers required passwords, and none of the pacemakers authenticated with the programmers. Some home pacemaker monitoring systems even included USB connections in which opens up the possibilities of introducing malware through an infected pendrive.

The programmers’ firmware update procedures were also flawed, with hard-coded credentials being very common. This allows an attacker to setup their own authentication server and upload their own firmware to the home monitoring kit. Due to the nature of the hack, the researchers are not disclosing to the public which manufacturers or devices are at fault and have redacted some information until these medical device companies can get their house in order and fix these problems.

This article only scratches the surface for an in-depth look read the full report. Let’s just hope that these medical companies take action as soon as possible and resolve these issue’s as soon as possible. This is not the first time pacemakers have been shown to be flawed.

Posted in Medical hacks, news, pacemaker, penetration testing, security, unencrypted, vulnerability | Leave a comment

Hackaday Prize Entry: MakerNet

One of the biggest trends in whatever market ‘Maker’ stuff belongs to is the Legofication of electronics. Building electronics is hard, if you haven’t noticed. Anything that turns transmission lines, current loops, and RF wizardry into something a five-year-old can use has obvious applications to education. For his Hackaday Prize entry, [Jeremy Gilbert] is building a fast, intuitive, modular way to explore electronics. It’s easier to use than the 100-in-1 Radio Shack spring clip kits, and you can actually make useful projects with this system.

MakerNet is [Jeremy]’s solution to the problem of complicated electronics, Arduinos connected to breadboards with DuPont cables, and apparently, to actual electronic Lego sets. The core of this system is built around the Atmel SAM D21 microcontroller, an ARM Cortex-M0+ chip that has more than enough processing power for anything deserving of the ‘maker’ label. This mainboard connects to devices through what is basically an I2C bus. Each module in the system has an in and out header. A small SAM D11 (available for $1 USD) on each module handles all the communications.

Right now, [Jeremy] is experimenting with a dozen or so modules including a captouch board, an LED matrix, OLED display, rotary encoders, and lots of blinky LEDs. It’s just a prototype, but that’s exactly what we’re looking for at this stage of the Hackaday Prize. After looking at the video [Jeremy] produced (below), there’s a lot of promise here.

Posted in 2017 Hackaday Prize, i2c, SAM11, The Hackaday Prize | Leave a comment

Use the Force to Turn On This Lamp

Holocrons are holographic data storage devices used in the Star Wars universe by both Jedi and Sith as teaching devices or for storing valuable information. After the fall of the Jedi, they became rare and closely guarded artifacts. [DaveClarke] built one to light the room.

[DaveClarke] built the lamp around a Particle Photon – a STM32 ARM-M0 based microcontroller with a Cypress wifi chip. All [Dave] needed for the workings were an IR proximity sensor, a servo and a bunch of super-bright white LEDs. When the sensor detects something, it starts up the system. The servo rotates a gear which raises the lamp and fades in the LEDs. The next time the sensor detects something, the servo lowers the lamp and the lights begin to fade out. And since the Photon is connected to the cloud, the system can be accessed with a web interface as well.

Okay, so it’s just an IR sensor detecting reflected infrared light and not the Force that’s used to turn it on, but it’s still pretty cool. There are plenty of pictures and videos at [DaveClarke]’s site, along with a schematic, 3D printer designs, and the source code. The whole thing was designed using Autodesk Fusion 360 and 3D printed in about 30 hours and press-fits together. A very simple yet clever design. There have been some other great lamps on the site, like this blossoming flower lamp or this laser cut lamp with which also has a unique switch.

Posted in 3d Printer hacks, Holocron, ir sensor, jedi, led light, Microcontrollers, particle photon, servo | Leave a comment

The Internet of Cigars

We know, we know. They are bad for you. You shouldn’t start, but some people do love a cigar. And a fine cigar is pretty particular about drying out. That’s why tobacconists and cigar aficionados store their smokes in a humidor. This is anything from a small box to a large closet that maintains a constant humidity. Of course, who could want such a thing these days without having it connected to the Internet?

This fine-looking humidor uses a Raspberry Pi. When the humidity is low, an ultrasonic humidifier adds moisture to the air. If it gets too high, a fan circulates the air until it balances out. Who knew cigar smoking could be so high-tech? The humidity sensor is an AM2302. There’s also a smart USB hub that can accept commands to turn the fan and humidifier on and off.

The wooden cabinet was an existing humidor, apparently. [Atticakes] says he spent about $100 total but that a commercial equivalent would have been at least $250. You can find his source code on GitHub.

If you are vehemently anti-cigar, we should point out that there are other uses for such a device. Because of Denver’s low humidity, for example, the Colorado Rockies baseball team store game balls in a large humidor.

For the record, a zip lock bag can do in a pinch. Without something, the experts say the cigar starts to change negatively in two or three days.

First networkable humidor we’ve seen? Hardly. If you need something to light that stogie, we suggest a laser.

Posted in AM2302, cigar, humidity, humidor, Raspberry Pi | Leave a comment

Sense Hat Comes Alive

Remember the Raspberry Pi Sense Hat? Originally designed for a mission to the International Space Station, the board has quite a few sensors onboard as well as an 8×8 RGB LED matrix. What can you do with an 8×8 screen? You might be surprised if you use [Ethan’s] Python Sense Hat animation library. You can get the full visual effect in the video below.

The code uses an array to represent the screen, which isn’t a big deal since there are only 64 elements. Turning on a particular element to animate, say, a pong puck, isn’t hard with or without the library. Here’s some code to do it with the library:

for x in range(0,7): ect.cell(image,[0,x],[randint(0,255), randint(0,255), randint(0,255)],0.1) ect.cell(image,[0,x],e,0.1)
for x in range(7,0, -1): ect.cell(image,[0,x],[randint(0,255), randint(0,255), randint(0,255)],0.1) ect.cell(image,[0,x],e,0.1)

Each loop draws a box with a random color and then erases it before going to the next position. The second for loop makes the puck move in the opposite direction. You can probably deduce that the first argument is the screen array, the second is the position. The third argument sets the color, and the final argument sets an animation timer. Looking at the code, though, it does look like the timer blocks which is probably not going to work for some applications.

If that’s all there was, this wouldn’t be worth too much, but you can also draw triangles, circles, and squares. For example:,(4,4), 3, [randint(0,255), randint(0,255), randint(0,255)], 0.1)

We covered the Sense Hat awhile back. Of course, it does a lot more than just light up LEDs as you can see from this weather dashboard.

Posted in animation, Raspberry Pi, RGB LED, sense hat | Leave a comment

Energy Harvesting Wristwatch Uses a Versatile Photodiode

There’s some interesting technology bundled into this energy harvesting wristwatch. While energy harvesting timepieces (called automatic watches) have been around for nearly 240 years, [bobricius] has used parts and methods that are more easily transferable to other projects.

Unlike early mechanical systems, this design uses the versatile BPW34 PIN photodiode (PDF warning). PIN photodiodes differ from ordinary PN diodes in that there’s a layer of undoped ‘intrinsic’ silicon separating the P and N doped layers. This reduces the utility of the diode as a rectifier, while allowing for higher quantum efficiency and switching speed.

They are typically used in the telecommunications industry, but have a number of interesting ‘off label’ applications. For example, the BPW34 can be used as a solid-state particle detector (although for detecting alpha particles you’re better off with something in a TO-5 package such as the Hamamatsu S1223-01). The fast response speed means you can send data with lasers or ambient light at high frequencies – a fun use for an LED lighting system or scrap DVD-RW laser.

Some common solar panels are essentially large PIN photodiodes. These are the brownish panels that you’ll find in a solar-powered calculator, or one of those eternally waving golden plastic neko shrines. They specifically offer excellent low-light performance, which is the basis of the energy harvesting used in this project.

What is very interesting is that energy harvesting IoT sensors use a similar method to function without batteries or mains power: amorphous silicon solar cells combined with a high-efficiency supercapacitor charging circuit. This is immensely useful for wireless transmitters on rooftops and industrial or agricultural sites where mains power would be impractical. Also since there’s no need to replace batteries, weatherproofing your sensor is only an epoxy tube away.

Does it function well as a watch though? With a standby time of at least 7 days, a viewing time of maximum 20 minutes, and a USB port for fast charging, it’s not entirely impractical unless you obsessively check the time. As a comparison, automatic mechanical watches offer unlimited viewing time, but typically runs out of stored energy if unworn for a day or two, and we imagine a USB port is a more dignified way of winding a watch than flailing your arms wildly.

See it in action in the video below:

Posted in atmega328, bpw34, clock hacks, DIY wrist watch, solar hacks, supercapacitor, wearable hacks | Leave a comment

Hackaday Prize Entry: LiFePO4wered/Pi+

For some of you the title might seem familiar, as [Patrick Van Oosterwijck] LiFePO4wered/Pi project is a quite successful project. Now he’s designing from scratch the plus version to fill in some gaps and solve some of the challenges that affected the initial project. So what exactly is LiFePO4wered/Pi+ and what can it do?

In a nutshell, it’s a smart UPS for the Raspberry Pi. The standard version allows a Model A+ and Pi Zero to run on battery for over 2 hours, and the B+, B2 and B3 to run for at least an hour (it maybe less, depending on the system load, of course). It implements two-way communications between the power system and the Raspberry Pi (running the open-source daemon) over the I2C bus. This allows for continuous measurement of the battery voltage and load voltage, with user programmable thresholds for boot, clean shutdown and hard power down. There’s a touch pad that provides clean boot/shutdown capability even in a headless setup, a wake timer allowing the Raspberry Pi to be off for low duty cycle applications and an auto-boot feature to maximize uptime by making the Raspberry Pi run whenever there is sufficient battery power.

That’s the standard version, which we covered last year… what else could the plus version have?

Well, to start, it brings more current to run complete systems with LCD screen and hard drives, the previous version was limited when it came to current. It will provide the option for a wider range of input power sources, such as solar panels, which is pretty nice. The on/off button and the power led will no longer be soldered on the main board so they can ‘relocated’ elsewhere, for example, when making a custom enclosure. Detection of input power to trigger automatic boot and shutdown will be added and last, but not least, a real-time clock with absolute time wake up.

So there it is, the new LiFePO4wered/Pi+ version, with all bells and whistles for the Raspberry Pi enthusiast.

Posted in 2017 Hackaday Prize, LiFePO4wered, raspberry, Raspberry Pi, The Hackaday Prize, ups | Leave a comment

The Tri Rotor Drone: Why Has It Been Overlooked?

A DJI Phantom 3. Zimin.V.G. [CC BY-SA 4.0]If you are a watcher of the world of drones, or multirotors, you may have a fixed idea of what one of these aircraft looks like in your mind. There will be a central pod containing batteries and avionics, with a set of arms radiating from it, each of which will have a motor and a propeller on its end. You are almost certainly picturing a four-rotor design, such as the extremely popular DJI Phantom series of craft.

Of course, four-rotor designs are just one of many possible configurations of a multirotor. You will commonly see octocopters, but sometimes we’ve brought you craft that really put the “multi” in “multirotor”. If the computer can physically control a given even number of motors, within reason, it can be flown.

There is one type of multirotor you don’t see very often though, the trirotor. Three propellers on a drone is a rare sight, and it’s something we find surprising because it’s a configuration that can have some surprising benefits. To think about why, it’s worth taking a look at some of the characteristics of a three-rotor machine’s flight.

A Chinook helicopter in service. UNC - CFC - USFK [CC BY 2.0].A Chinook helicopter in service. UNC – CFC – USFK [CC BY 2.0].If you think for a moment about a typical small helicopter, it will have a tail rotor. The tail rotor is there to provide a sideways force to counteract the natural tendency for the fuselage to spin in reaction to the rotation of the main rotor. With a twin-rotor helicopter such as the famous Chinook military aircraft, the tail rotor is superfluous because the tendency to rotate imparted by the front rotor is counteracted by an equal but opposite force from the contra-rotating rear rotor. If you take the counteracting forces in a Chinook as analogous to those on a multirotor, you will then understand that equal numbers of contra-rotating propellers cancel any tendency for the craft to rotate, and allow the craft to be flown .

Now imagine the same interplay of forces in a trirotor, and you will instantly appreciate that it has an odd number of propellers, and thus it will have an excess of rotational force that is not counteracted by another motor. A simple three-rotor design will therefore naturally spin in flight, and be next-to-useless as an aircraft without some means of counteracting that rotation. In the simplest of flyable trirotor designs one of the rotors is simply mounted at an angle to vector some of the force sideways in an analogous manner to the tail rotor on a small helicopter. This has the desired effect of creating a flyable machine but offers no advantages, and a few disadvantages, over a four-rotor design.

The layout of a trirotor, showing the yaw servo axis in green. Toglefritz [CC BY-NC-SA]The layout of a trirotor, showing the yaw servo axis in green. Toglefritz [CC BY-NC-SA]Where three-rotor craft come into their own though is when instead of being mounted at a fixed angle, one propeller is mounted at a variable angle. When the force counteracting the rotation is under variable control, this ability for the rear propeller to yaw gives the craft some of the characteristics a fixed wing aircraft gains from its tailplane. The result is that tri-rotor craft can deliver a more stable and more agile flight than their multi-rotor cousins, at the expense of an extra servo with its control circuitry and software. The additional benefits of the layout are that with fewer drive motors it can be more energy-efficient, and with a larger gap between rotors it can have larger propellers and provide a more unobstructed view for a camera.

So given these advantages, why do we rarely see a trirotor? There are probably several factors behind the proliferation of quadrotors as the most common configuration. The first is simply market inertia: fashion, if you will. The majority of customers now expect a quadrotor, so the manufacturers make the machines they want. Then there is the cost of fitting that yaw servo. It’s a slightly complex mechanism which probably requires a few precision parts, so if you are a factory in China making millions of them you are likely to pick a design that saves you a few cents. If the extra motor on a quadrotor is cheaper than a servo and linkage, then you’ll make quadrotors. And finally, there is a reliability angle. If you crash a quadrotor, as you inevitably will, all its arms are equally strong. The yaw servo is an expensive weak point on a trirotor, so in the event of a crash there is a good chance that it will be first to go.

All is not lost for the trirotor though. If you fancy owning one then you can build one yourself by following this Instructable. We’d suggest becoming proficient at flying a quadrotor first though, otherwise the shop selling yaw servos is going to like you a lot.

Thanks [Jared] for the impetus for this piece.

Header image: Toglefritz [CC BY-NC-SA]

Posted in aircraft, drone, drone hacks, Featured, multirotor, trirotor | Leave a comment

Nintoaster: The Next Generation

The original Nintendo Entertainment System is affectionately called “the toaster” due to the way the cartridge is inserted. [MrBananaHump] decided to take things a bit literally and installed a NES inside an actual toaster. This isn’t [MrBananaHump’s] design, the Nintoaster comes to us from [vomitsaw], who also built the SuperNintoaster. Since [vomitsaw] was kind enough to document his original build, [MrBananaHump] was able to build upon it.

The target toaster for this build was a plastic Sunbeam model found at a thrift store for $5. [MrBananaHump] gutted the toaster and cleaned out years of toast crumbs. The Nintendo mainboard would fit perfectly inside a toaster, except for two things – the RF Modulator and the expansion port. The expansion port was never used in the US version of the NES so it can be desoldered and removed. The RF also needs to be desoldered and relocated.

By far the biggest job in this casemod is hand-wiring each of the 72 pins for the cartridge port. It’s a tedious job, and it probably won’t look pretty. Keep your wires short, and things will probably work thanks to the relatively low clock speed of the NES.

The cartridge goes in one toast slot. [MrBananaHump] mounted his controller ports, power and reset buttons in the second slot. A bit of expanded metal grid completes the slot. Sure, it’s not exactly pretty inside, but with the case on, this becomes a rather nice looking build.

We’ve seen numerous Nintendo casemods over the years, just one other example is this N64 in an N64 controller.

Posted in classic hacks, gaming, nes, nintendo, retrogaming, toaster | Leave a comment

Embed With Elliot: LIN is for Hackers

A car is a rolling pile of hundreds of microcontrollers these days — just ask any greybeard mechanic and he’ll start his “carburetor” rant. All of these systems and sub-systems need to talk to each other in an electrically hostile environment, and it’s not an exaggeration to say that miscommunication, or even delayed communication, can have serious consequences. In-car networking is serious business. Mass production of cars makes many of the relevant transceiver ICs cheap for the non-automotive hardware hacker. So why don’t we see more hacker projects that leverage this tremendous resource base?

The backbone of a car’s network is the Controller Area Network (CAN). Hackaday’s own [Eric Evenchick] is a car-hacker extraordinaire, and wrote up most everything you’d want to know about the CAN bus in a multipart series that you’ll definitely want to bookmark for reading later. The engine, brakes, doors, and all instrumentation data goes over (differential) CAN. It’s fast and high reliability. It’s also complicated and a bit expensive to implement.

In the late 1990, many manufacturers had their own proprietary bus protocols running alongside CAN for the non-critical parts of the automotive network: how a door-mounted console speaks to the door-lock driver and window motors, for instance. It isn’t worth cluttering up the main CAN bus with non-critical and local communications like that, so sub-networks were spun off the main CAN. These didn’t need the speed or reliability guarantees of the main network, and for cost reasons they had to be simple to implement. The smallest microcontroller should suffice to roll a window up and down, right?

In the early 2000s, the Local Interconnect Network (LIN) specification standardized one approach to these sub-networks, focusing on low cost of implementation, medium speed, reconfigurability, and predictable behavior for communication between one master microcontroller and a small number of slaves in a cluster. Cheap, simple, implementable on small microcontrollers, and just right for medium-scale projects? A hacker’s dream! Why are you not using LIN in your multiple-micro projects? Let’s dig in and you can see if any of this is useful for you.

The LIN Protocol

A LIN “cluster”, which is what the local mini-network is called in the jargon, consists of a single master microcontroller and a number of slaves. LIN starts off as standard 8N1 UART serial, usually at 19,200 Baud, and does away with one wire. Next, it adds a protocol that allows this single wire to be used as a bus, shared among multiple slaves. If you tried to roll your own network protocol for simple UART serial communications, you’d end up with something like LIN. Go fetch a copy of the specification (PDF) and read along!

Every LIN transaction is fundamentally the same: the master sends a header that includes a protected identifier (PID), which specifies the task to be carried out. Tasks can be something like “report temperature sensor 2” or “set servo 3 position”. Depending on the task, between one and eight bytes of data follow, with a two-byte checksum. The slaves have to know which tasks to respond to, and how to respond. So if “set servo 3 position” is sent, the servo 3 slave needs to listen for the next bytes and react accordingly. All slaves that don’t respond to the command can ignore data until the next preamble.

In the case of “report temperature sensor 2”, the slave with the temperature sensor sends its data immediately after receiving the command. Since the byte length is known in advance, and only sensor 2 is allowed to respond to this task, the master knows to listen for exactly, say, four bytes in response and knows how long that should take.

This polling system with the master sending headers and the slaves sending responses guarantees that none of the devices will access the bus at the same time, so LIN gets by with just a single RX/TX line. The preamble includes a sync byte (0x55) that helps the slaves lock on to the master clock, so the slaves can run on cheaper RC clock sources and auto-bauding is possible.

Since the length of messages is known ahead of time, the timing for the master’s polling routine can be written down in a schedule. The master polls the network at defined intervals, and if the slave doesn’t respond within 1.4 times the required time for the transaction, it’s presumed to be missing in action. Either way, the master is on to the next item in its schedule, and won’t retry the potentially defective slave until its turn comes around again. This guarantees a known update rate for all of the devices, which makes life a lot simpler for programming the master.

Those are the basics. The master sends PIDs, and a series of data bytes follows. Everything’s comfy old UART, call and response, adapted as simply as possible to create a small network.


GUI LIN configuration app from an instructive video.

Keeping the network that simple requires that the master and slaves all agree on the command set and valid response lengths. That’s a lot of information needed for the LIN cluster to function, in principle. Helping matters out somewhat, there’s a standard format for notating all of this laid out in the LIN spec.

There’s also a standard API for C that both the master and slave microcontrollers can use to make dealing with coding up behavior in a LIN cluster. Combined, this makes a standard workflow for specifying and implementing LIN busses — very handy for the automakers, and not useless for the hacker either.

There is also a sleep state and behavior that’s defined for the bus, with associated sleep and wakeup signals. All of the slaves should respond to the sleep signal, and any of them should automatically go to sleep after a timeout of four seconds if they haven’t heard from the master. Any node, slave or master, can send the wakeup command, and after that the master should go back to its normal polling schedule.

LIN version 2.0 included a number of optional frame types that make the network more flexible. In particular, “sporadic frames” make the slave’s response optional if it hasn’t gotten any new data since the last update. “Event triggered frames” are like sporadic frames, except they can be additionally responded to by any slave node that has new data.

This introduces the possibility of a collision on the bus, in which case hopefully the checksum doesn’t add up and the master falls back to slave-specific frames as before. These two modes speed up the bus when data updates are infrequent, but add some indeterminacy to the schedule and conditional complexity to the code. Use them only if you need them.

The master can also have multiple schedules, and switch among them. The slaves don’t care — they just listen for the tasks that are relevant to them anyway. There’s no reason for the master to send servo position data every period if it hasn’t changed, for instance, even if it makes things conceptually simpler. Your call.

There is even an optional transport layer spec that is compatible with CAN bus and makes it easier to integrate the local LIN cluster with the bigger network. In short, LIN is a very thoroughly thought through UART bus protocol with decent industry adoption. You’ll find good tutorials from every vendor of LIN transceiver hardware. (Here’s a great intro from National Instruments.)

Hardware — The Physical Layer

Topping all of this protocol niceness off is a wide variety of LIN transceiver chips ranging from $0.25 to $0.50 for plain transceivers, on up to around a buck or two for “system basis” chips with integrated voltage regulators. These are especially slick, because the transceiver can take care of the sleep/wake logic and turn the power supply to your microcontroller on and off. This makes integrating a slave node that operates at 3.3 V very simple.

Little chip buys you a lot.

Since the LIN bus is designed for automotive, it’s often specced for 12 V because that’s what courses through the veins of your car’s wiring harness. LIN transceiver hardware needs to be able to accommodate even higher voltages, because car electrical systems can be spiky environments. They also have to cope with bus contention, when the transceiver chip may be trying to pull the LIN line down while someone else is trying to pull it up, so there’s overheating protection built in as well. LIN transceivers are robust little beasties.

In contrast to I2C lines, which are pulled up with puny resistors, an automotive LIN bus is pulled up to 12 V with a 1 kΩ resistor. To pull this line down fast enough, LIN transceivers need to be able to conduct tens of milliamps, so they have slightly beefy (for ICs) transistors built in. The combination of a high voltage and relatively high line current means that an automotive-spec LIN bus is good for 40 meters, rather than the couple meters that I2C gives you without resorting to drivers. If you need the distance or the noise immunity, LIN is there for you.

But nothing forces you to run your bus at 12 V, even the transceiver hardware. The Microchip transceivers that I’ve seen run down to 5.5 V, while the ones from NXP and Melexis run down at an Arduino-compatible 5 V.

And nothing forces you to use transceiver hardware at all! You could simply connect a PNP transistor (or P-channel MOSFET) to the bus line and drive that with the UART TX, sampling the bus with the RX line. This has the disadvantage of local echo, but that could be handled in software. Or, with only a few more parts, there’s this solution that we’ve seen before. I couldn’t find any hacker projects implementing LIN transceivers from scratch, though. Maybe that’s because the industrial ones are just so cheap.

Strengths and Weaknesses

No bus is perfect for all occasions, and LIN is no exception. LIN is not particularly fast, being designed around 19,200 baud UART. Updates come fairly infrequently, from a microcontroller’s perspective. A full-length transaction, with timeout, takes around ten milliseconds. If the master polls sixteen devices, that’s an update rate of around seven hertz worst-case. Of course, the master need not poll every device every time, and many times the messages will be half that length, but you’re not going to get more than 200 Hz. On the other hand, the update rate is constant because of the ability to implement tight timeouts for flaky devices, which is great for reliability and simplicity, and it’s not that much slower than I2C.

There are two main versions of LIN that you’ll see in the wild, 1.x and 2.x. In addition to the optional frame types mentioned above, the two versions have different checksum formulas — and the one in 2.x is truly bizarre — necessitating a web-based calculator to make sure you’re doing it right. Instead of addition mod-256, they subtract 255 from any value 256 or greater. It’s like an 8-bit overflow that wraps around to 1 instead of 0. Does this make sense to any of you?

LIN devices aren’t as prevalent outside the automotive industry as I2C or SPI, by a long shot, so you’ve probably never been forced to deal with the protocol. But if you want to network up a small number of microcontroller-based modules, as easily and cheaply as possible, using just one wire (plus ground), it’s hard to imagine anything easier. Writing I2C slave code is certainly no picnic. Writing code to listen for a particular byte on a UART line and then react couldn’t be simpler.

Want to turn your plain-vanilla UART into a bus? Take a page or two out of the LIN book! Have you done so already? Show us!

Posted in bus, embed with elliot, Engineering, Hackaday Columns, LIN, Microcontrollers | Leave a comment