Page: 0 3 4 5 6 7 8 9 10 11 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85 ... 90 ... 95 ... 100
MC2 March Progress
Date: 1/4/2016
Tags: mc2
After when seems like forever I bring you an update on the MC2 project. The good news is that most of the hardware is now working, including MIDI Input/Output, the Neopixel chain, the I2C bus to the GPIO expander chips, which in turn connects to the buttons and encoders. In short I can now use it to change presets on the Axefx which is like the bare minimum functionality.

Some of the issues I've had to sort out:
  • Very slow compile times on the Raspberry Pi
    I'm only using a Pi B (version 1, rev 2) so it's got a single core running at 700MHz which frankly is molasses slow. So I decided that it was worth getting a cross compiler working on something with more grunt. It took days of mucking around, and 3 different builds, copying off almost the entire Pi's worth of headers and libraries, but it now works. More importantly it's fast. My main dev box (3.8ghz i5 /w 16GiB of ram) chews through the code very quickly, and then copies the binaries down to the Pi over the network.
  • PiTFT touch screen not working correctly
    The behaviour I was seeing was the cursor stuck in the top left, and the x & y axis' were swapped. I ended up building SDL from source and then inserting a pile of logging during the mouse driver setup only to discover that it was using the default mouse driver instead of the touch screen driver that I had configured in the environment. It turns out that as I'm running the code as root (sudo) the environment is different than my normal user account. Ok, so now I just set the right env vars in my C code before initializing SDL. Which forces it to do the right thing on any account.
  • I2C bus not working / unreliable
    This came down to adding 1000uF electrolytic over the 3.3v supply line, and also adding 0.15uF decoupling caps over the +V/GND pins of the GPIO expander chips. Also I had to change the pull up resistors connected to the SDA+SCL data lines from 4.7k to 10k.
  • Neopixel chain stopped working
    Eventually I found a cold solder joint on the ground pin output. Only after disassembling it completely, including the button harness and taking the plastic backing plane out.
  • MIDI input not working / garbled
    This has actually taken most of the week to sort out. The hardware for the input side seemed ok, and I even did see some incoming MIDI at one point. Initially it was garbled and I tweaked the baud rate with system settings. It seemed to work for a while then stopped again. I got very frustrated with not being able to see the logic signals in the circuit so I went and bought a Bus Pirate which can read both the UART and do logic analysis. I tested all the hardware I could in isolation. I went over the traces like 6 times. I tried the optical isolater chip in my MC1 and everything appeared to be good. I even pulled the diode out and tested it in isolation. I tested the Rx+Tx pins of the Pi by hooking it up to the Bus Pirate and had the Pi talking to the PC. Then I tried minicom and saw the incoming Tempo messages from the Axefx! Ah, so the hardware IS good, and thus I started looking at the software side again. It turns out that in more recently Linux kernels you can see custom baud rates in code. Most of the people getting MIDI working on the Pi are doing system config settings. But it's a hack. Using an API to set the speed to the exact right value is way better. Now the existing code snippets kinda get you there, but for me I had to merge the old code and new code to get something that works for me. This is the final result:
            int MidiHnd = open("/dev/ttyAMA0", O_RDWR | O_NOCTTY | O_NDELAY);
            if (MidiHnd > 0)
                struct termios2 tio;
                ioctl(MidiHnd, TCGETS2, &tio);
                tio.c_cflag = BOTHER | CS8 | CLOCAL | CREAD;
                tio.c_iflag = IGNPAR;
                tio.c_oflag = 0;
                tio.c_lflag = 0;
                tio.c_ispeed = 31250;
                tio.c_ospeed = 31250;
                ioctl(MidiHnd, TCSETS2, &tio);
    The MIDI output was an easy fix: just turn the 4011 logic chip the right way around. And boom: working! Hahaha... in my defense it has a little stamped circle at the other end of the chip. Which is sometimes used to mark the "1" pin. Grrrr.
Oh and here is some video showing it working:
(0) Comments | Add Comment

Got the NeoPixels working
Date: 3/3/2016
Tags: mc2

I've got around to working on the MC2 again. Last I got up to was getting the NeoPixels working and for some reason none of them would light up. To isolate the issue I used the bread board to step the data signal from 3.3v up to 5v. As you can see it works great. Now I know the NeoPixels themselves, and their connections are good I can get to work finding the issue on the peripheral board.
(0) Comments | Add Comment

Merry Christmas
Date: 24/12/2015
Tags: scribe linux
I think for the first time ever? There is a simultaneous release of Scribe on 3 different platforms: Windows, Mac AND Linux. The new v2.1.3 build is tri-platform. The Linux (x64) build is a GTK2 app and runs ok on Ubuntu and Arch. Well that's all I've tested at this point.

It also runs on a Raspberry Pi 2 although it's a little slow. I know because I got bored and tried building it while working on some MC2 stuff.

Links to the i.Scribe builds:
(0) Comments | Add Comment

Portable OpenSSL for Linux
Date: 21/12/2015
Tags: shared-object linux openssl scribe
A year ago I worked out how to make a portable build of OpenSSL for Mac. And now with the imminent release of the Linux build of Scribe I need to do the same with the Linux build of OpenSSL.

After downloading and unpacking OpenSSL I configured it with:
./config shared -DPURIFY
The reason for adding the -DPURIFY #define is to suppress valgrind errors related to uninitialized memory usage.

Once that is built I had a look at the shared object paths with ldd:
matthew@ubuntu:~/Downloads/openssl$ ldd ./ =>  (0x00007ffc0e197000) => /lib/x86_64-linux-gnu/ (0x00007f5c5ab6c000) => /lib/x86_64-linux-gnu/ (0x00007f5c5a7a7000) => /lib/x86_64-linux-gnu/ (0x00007f5c5a5a3000)
	/lib64/ (0x00007f5c5b1c1000)
So it's not portable yet. I initially tried using the chrpath command but it can only modify existing RPATH records. My binary doesn't have any RPATH yet. So that didn't work. The next thing I tried was the patchelf command from here:
After building and installing I issued this command in the OpenSSL folder:
patchelf --set-rpath '$ORIGIN' ./
Now to check if libssl pulls in the local libcrypto:
matthew@ubuntu:~/Downloads/openssl$ ldd ./ =>  (0x00007ffcdce86000) => /home/matthew/Code/Scribe/trunk/./ (0x00007f39b99d8000) => /lib/x86_64-linux-gnu/ (0x00007f39b9613000) => /lib/x86_64-linux-gnu/ (0x00007f39b940f000)
	/lib64/ (0x00007f39ba0a5000)
Yes! Now this build can be installed in the same folder as the Scribe binary and Scribe will use it without interfering with the system OpenSSL which is often out of date, or not built with -DPURIFY or missing.
(0) Comments | Add Comment

Scribe 2.1
Date: 27/10/2015
Tags: scribe
Well it's been most of a year since I said anything about Scribe v2.1, and the list of changes hasn't moved forward much in that time. There are a few reasons for the slow progress, but it mostly boils down to:
  • Working on various music projects, including a audio/video mix down of a band that shot a live set earlier in the year and a cover of New Day.
  • Working on the MC2 foot controller.
  • And the old RSI is back to haunt me.

Anyway there is some good news. The integration of Aspell is complete. Scribe v2.1 will come pre-loaded with a spell check and it will download and install dictionaries on the fly with no user intervention. Well you'll need an internet connection for that part, but once installed it'll work offline.

Secondly I'm in the middle of doing a fairly thorough rewrite of the Help files. Which includes fixing some things in the HTML rendering. Reviewing all the parts of the application that have "Help" buttons (or should have "Help" buttons) and making sure they work correctly. Updating all the pages with current information. It's actually a big slab of work. Lots of cross referencing things and checking the UI and source code so I accurately describe the functionality. I'm not much of a tech writer so it's tedious for me.

Anyway there is now a beta release online for v2.1. I look forward to getting feedback on what works and what doesn't.
(9) Comments | Add Comment

MC1 flash procedure update
Date: 19/10/2015
Tags: mc1
The original MC1 flash procedure involved having to use an actual parallel port. For this reason I have kept an old PC running XP around. Just to flash the firmware from time to time. As it didn't work so good on Windows 7 or pretty much any Mac. Then a few months ago someone was asking about the possibility of using a USB in circuit programmer like this. So seeing as they are dirt cheap on ebay, I bought one to try out.

Compiling the code into AVR instructions is accomplished with the WinAVR tool chain. I'm using the latest release. However there is one gotcha when installing. Do NOT install it into a folder with brackets in the name, like say:
C:\Program Files (x86)\WinAVR
This causes make.exe to crash. No I'm not kidding.

The next issue is the Avrdude binary that comes with the WinAVR compile is just a little too old to know about the usbasp programmer. So that needs to be updated to something recent. Just unpack that file into the bin folder of the WinAVR install, overwriting the existing avrdude files. Check that the version available on the command line is correct by running it without any arguments.

Next the usbasp needs a driver to work in Windows (7 in my case). You can get that here. I didn't have much luck with the installer, but if you go into the Device Manager, right click on the usbasp device and install drivers from that menu. Then select the folder where you unpacked the drivers. On my machine the device driver takes 10 seconds to connect so give it time before trying to flash the firmware.

Finally the actual command you use to flash the firmware is:
avrdude -c usbasp -p m128 -U flash:w:main.hex
Where 'main.hex' is the compiled binary. It's faster and easier than the old PonyProg2000 method, and scriptable. Just put it in the makefile. Less mucking around.

Now I'll have to find another excuse to have an old PC lying around. Maybe LAN games with the lad? :D
(0) Comments | Add Comment