It took me a really long time to do this second part of my Pi-based Logic Analyzer project, mostly because of two things; the first one being that at one point (after I had pretty much all the case design, extra hardware and software tweaking done for my RPi1) I decided to switch to a Raspberry Pi 3, which of course meant discarding a lot of work and starting again but with the RPi3 in mind.
Why? Because I figured that my device was getting needlessly bulky (the case required extra room for a small fan (for the overclocking), extra width for the full-size SD card, and extra thickness due to the back-facing P5 connector, etc), and it would have been almost impossible for others to replicate this project (because I was using the old Pi1 Rev.B board, which is discontinued) so using a more modern Pi made sense. The physical layout of the Pi has stayed the same since the latest revision of Pi1 I believe, and -sans the position of the status LED- both the Pi2 and Pi3 are identical and completely interchangeable for the purposes of this project.
The second reason for the delay was that in an spectacular display of stupidity, I managed to fry my Waveshare TFT screen when I was done with the whole setup and designs for the Pi3, so I had to order another one online, and wait until it arrived, which took a long time. Read More
For a few months now (and after successfully using a cheap USB analyzer with my Pocket C.H.I.P) I’ve wanted to make a sort of standalone Logic Analyzer / mini linux machine that I could have on my bench. I originally wanted to use one of my C.H.I.P boards, but I soon stumbled upon a bit of a difficulty: It’s not that easy to use readily-available touch-screen / LCDs with the C.H.I.P.
Because of this I decided to switch to an old RaspberryPi1 Model B that I had laying around instead. I don’t need anything faster than that, and finding TFT/LCD screens for Raspberry Pi is ridiculously easy. As a matter of fact, I already had a small 480×320 LCD that I tested before and worked really well. I may eventually switch to a small HDMI screen, but for the time being I’ll use this one:
*SPOILERS* The RPI with the LCD after everything was configured.
Nothing like a Text-based UI
A recent discussion on the Pocket C.H.I.P forums made me dig up memories of my time with DJGPP (a wonderful DOS port of GCC), and its quite functional text-based IDE; RHIDE.
I thought that it would be great to have RHIDE running on my Pocket CHIP for doing simple C/C++ development on the go, as TUIs (Text-based User Interfaces) were pretty simple and could work in really low resolutions, but unfortunately CHIP’s ARM architecture was completely foreign to RHIDE’s build scripts, and it refused to compile.
I’m definitely no Linux guru, but I reckoned that adding the architecture to the build script wasn’t going to be easy, especially since it apparently had several architecture-dependent libraries, modules, etc, so I embarked on a quest to find another text-based IDE for Linux, and that’s how I found Motor.
Sure, the project is 12 years old (last “build” is 3.4.0 from February 2005, and still more recent than RHIDE), but I thought that perhaps it could still work on a relatively modern Linux distribution, and to my surprise, it did (with a few gotchas, though).
Pocket C.H.I.P + USB Analyzer
So a time ago I purchased a cheap USB Logic Analyzer from eBay that works great with a PC, and it’s been really helpful to debug several projects to date. It uses the Logic software from Saleae as hinted by the label on it, although I am not sure if the device is supposed to be a cheap knockoff of one of the (pricier) genuine Saleae analyzers, or it was just designed to be “Saleae-compatible” and use their software. Read More
So recently I had to design a relatively convoluted system with a database that communicates with a hardware controller board and a RFID reader. Among other things, the system has to respond to several commands issued from a web frontend over HTTP, and report the status of each sub-system, sensor, etc hopefully in JSON or similar web-friendly format.
For this task I picked a Raspberry Pi as the platform, and made a program in C that talks directly to the hardware and handles everything including the HTTP requests. Now, this is definitely not the first time that I need to write a program that has to listen for requests and reply with simple data over HTTP, so I thought that perhaps it would be useful to encapsulate this functionality in a small module that I could later re-use in other projects.
So I ended up doing exactly that, and uploaded the code to my GIT-Hub Repository, so you’ll find the result from that here: https://github.com/battlecoder/httpdpi.
Before you dive into the code, please bear in mind that it’s an extremely simple service that will only respond to GET requests, but has all it needs to reply with different status codes, text, and binary data. It only uses sockets and POSIX threads, so it’s very fast, doesn’t depend on a huge framework, and can run in parallel with your code. It’s also really easy to expand if you want to support other types of requests.
Since it doesn’t have obscure dependencies, it should also compile on most linux boxes including other small computers like C.H.I.P, Beaglebone, etc.
So I’m writing a program in C that needs to interact with a custom HID device I built. This program will be running on a Raspberry Pi. This isn’t a massively complicated task but it can be daunting when there’s not a single “barebone” example or tutorial out there on how to do this. So I decided to write this sort of guide in case it may come in handy for anyone (including myself, in a future).
Libhid is an open source library designed on top of libusb to deal with HID devices, so the first step is compiling libhid. I’d say this is relatively straight-forward except for the fact that “as-is”, the library fails to build in the Pi. Luckily the problem is a single line of code in one of the examples (yes, and that prevents the whole library from being compiled and installed).