All posts by Grant
FollowNeoPixel Arcade Buttons
Custom Arcade Control Panels
I’ve started building custom arcade controls for using with classic arcade game emulators. All Open Source and Open Hardware of course, with the source code up on GitHub.
OpenSCAD:Arcade is an arcade panel modeling too written in OpenSCAD. It designs the arcade panel layout and produces lasercutter output and frame dimensions.
STM32F3-Discovery-Arcade is a prototype USB HID device for arcade controls. It currently supports GPIO joysticks and buttons, quadrature trackballs/spinners, and will drive up to 4 channels of NeoPixel RGB LED strings. The project has both custom STM32 firmware and a custom adaptor PCB designed with KiCad.
Please go take a look.
Debugging 96Boards I2C
I was originally just going to post this to one of the 96boards mailing list, but it got sufficiently interesting that I thought I’d make it a blog post instead. I’ve been working on making i2c on the 96Boards sensors adapter work properly and I’ve made some progress. The problem that user have run into is that the Grove RGB LCD module won’t work when connected to one of the baseboard’s I2C busses. I pulled out the oscilloscope today to investigate.
The LCD module is particularly useful for testing because it actually has 2 i2c devices embedded in it; an LCD controller at address 0x3e, and an RGB controller at 0x62. The two devices operate independently with different electrical properties.
On Hikey+sensors (TXS0108 level shifter), the RGB device will work, but only after pulling the ribbon cable apart to reduce crosstalk due to insufficient pullups. However, the LCD causes the entire bus to lock up, and no further transactions will work.
On Hikey+pca9306 the LCD isn’t detected and the RGB works correctly (undetermined if there are crosstalk issues)
The traces below show both sides of the level shifter. Green and blue on the top for the data line. Orange and purple on the bottom with the clock.
First, what I saw on using Hikey+pca9306+RGB:
And with the LCD:
In both traces you can see the start condition (data goes low while clock is high), the 7 bits of address (7 rising clock edges), the R/W bit (1 rising clock), and then the acknowledgement bit driven by the device. If the controller doesn’t see the device drive the data line low on the 9th clock, then it decides the device isn’t there and it terminates the transaction. It is easy to recognize the ack bit because the device has a different drive strength and the voltage level is different.
The RGB controller is a happy little device and it jumps at the chance to drive the data line low. It goes down pretty close to 0V. The LCD on the other hand is sulky and doesn’t drive the line quite as low as the controller can. About to 1V. 1V is recognized fine as logic low on a 5V device, but with 1.8V it is not even less than half. The way the pca9306 level shifter works is there are pull-up resistors on either side of the device that draws each side up to its respective high level. In this case, 1.8V and 5V. When either side gets driven low, the level shifter begins to conduct and the other side also gets drawn down to the same voltage, but it can only go as low as the voltage it is driven to. If it only gets driven down to 1V, then it will never get low enough for a 1.8V controller to recognize it as a low state.
It may be that with weaker pull-ups the LCD will be able to drive to a lower voltage level. I’ll need to experiment more, but in the mean time let’s move onto the Sensors board. Back to the traces:
First, here is a transaction to address 0x63 with no device present:
Looks perfectly normal so far. Next, the RGB device at address 0x62:
Also behaving the same way as it did with the pca9306. Finally, an LCD transaction:
Again we see the start condition, the 7 data bits and 1 r/w bit, but the ack bit looks weird. The LCD successfully drives the data bit low enough to be recognized, but then something weird happens. The data line stays low and the clock stops running. I don’t know actually know what is happening here, but I’ve got my suspicions. The LCD is continuing to drive the data line low, (you can tell by the slightly different voltage level) but keeping data low should not stop the clock. I suspect the txs0108 is getting confused and driving the clock line high. I’ve come across reports from others having trouble with the txs010x series on i2c. It has ‘one-shot’ accelerators to reduce rise time by driving the line high. I don’t know for sure though.
On the plus side, I now know that the Hikey I2C busses are working correctly. Now I need to decide what to do next. Aside from the i2c problem, Rev B of the sensors board ready for manufacturing. I either need to make the txs part work, or rework the design to use a pair of pca9306s. I think I’ll try weaker pull-ups on the pca9306 breakout board first and see how that goes. Sadly, I blew up the i2c drives on my Hikey board while experimenting today, so I need to do the same experiments with my Dragonboard 410c.
Dear lazyweb, do you have any other suggestions on things to try?
Why ACPI on ARM?
Why are we doing ACPI on ARM? That question has been asked many times, but we haven’t yet had a good summary of the most important reasons for wanting ACPI on ARM. This article is an attempt to state the rationale clearly.
git.secretlab.ca is down
For anyone who has been using git.secretlab.ca, the server is currently down and I don’t know when it will be back up. I’ve moved my Linux kernel tree over to kernel.org. The new tree can be found here:
https://git.kernel.org/cgit/linux/kernel/git/glikely/linux.git
The other trees will be back when git.secretlab.ca returns to life.
Don’t fear ACPI on ARM
Before everyone freaks out about Matthew Garrett’s post regarding ACPI on ARM, here are a few things to keep in mind:
First, when we’re talking about Linux and ACPI on ARM, we’re talking about general purpose servers. In the general purpose server market, Linux is already the dominant OS, regardless of the CPU architecture. Servers are designed, built and sold to run Linux. It is already the situation that x86 server vendors build their ACPI tables to work with Linux. Supporting Linux on ARM servers is merely an extension of what vendors are already doing to support Linux on x86. Despite Matthew’s concern, I don’t think we’re entering new territory in this regard.
Second, many of us have bad memories of getting ACPI to work with Linux. However, it is worth remembering that most of our problems have been with machines where the vendor really doesn’t care about Linux – usually desktop or laptop PCs. It’s not surprising that we have problems with these machines since they’ve only been tested with Windows! Server vendors, on the other hand, have a vested interest in ensuring that Linux runs well on their hardware and so they regularly test with Linux. The negative lessons learned in the laptop and desktop markets don’t carry over to machines built to run Linux.
Third, the ACPI world has changed in the last 2 years. It used to be that the ACPI spec was governed in a closed process by 5 companies: HP, Intel, Microsoft, Phoenix, and Toshiba, with nary a Linux person to be seen. Last year ACPI governance was transferred to the UEFI Forum and we’ve got plenty of Linux engineers sitting at the table. In light of that, it is no longer true that ACPI only caters to the needs of Windows, and we have the ability to propose changes to the spec. In fact, if you look at the revision history in version 5.1 of the spec, you’ll find changes that were proposed by Linux engineers to make ARMv8 work.
That said, the issues raised by Matthew are important. There is a big question about how Linux should declare itself to the platform. Claiming to be compatible with “Windows 8” in the ACPI _OSI (Operating System Interface) method obviously isn’t appropriate on ARM. There is some talk about removing _OSI entirely on ARM since the way Linux uses it isn’t actually useful, and the _OSC (Operating System Capability) method has been proposed as a better way to declare what the OS supports. There is also a need to make sure vendors are testing with linux-next and mainline kernels so that we know when breakage happens and we can either do something about it, or work with vendors to fix their firmware.
Both of these are important issues and I think we need to propose solutions before merging ARM ACPI support into the kernel. Some of this work has already started: Linaro is running Canonical’s Firmware Test Suite (FWTS), the ACPI API tests, and the ACPI ASL tests on ARM, and we’re porting the Linux UEFI Verification (LUV) project which packages all the test suites into an easy to use distribution.
While I agree with Matthew that getting the interface between firmware and the OS is hard, I do not see the nightmare scenario he is describing. It certainly hasn’t played out that way on x86 servers where Linux is already the preferred OS. Besides, I really cannot agree with the premise that Linux being the dominant OS is a bad thing! We have a lot more influence than we give ourselves credit for.
On Setting the Standard for ARM Virtual Machines
Christoffer Dall lead a session today at Linaro Connect discussing standards for portable ARM virtual machines (video). About a week ago, Christoffer posted a draft specification to the linux-arm-kernel, kvm and xen mailing lists which attracted lots of useful feedback. Today we went over the major points of issue and Christopher is going to take the feedback to prepare a new draft.
Continue reading On Setting the Standard for ARM Virtual Machines
Inside a knockoff Wii Nunchuk
As part of the Lightsaber project, I’ve been looking for a low pin count way to add control since the ATTiny85 that I’m using only has 6 IO pins. For the prototype I connected a button and a potentiometer to a pin each. I’d like to have an accelerometer and another button or two, but that uses up pins pretty quickly. However, if I hang all the controls off an i2c bus, then I only need to use two IO pins.
