GnuPoc 1.16 was released some days ago adding support for the Qt SDK so I thought I had to give it another try.
To build the Qt SDK we also need OpenC/C++, the latest version of GnuPoc supports version 1.6 of OpenC/C++ and, with my luck, version 1.7.5 of OpenC/C++ was released some days later making the previous 1.6 disappear from the face of the internet. Let’s see what we can do!

Before going any further you must have a working toolchain for your SDK, read the README file in gnupoc-package-1.16/tools if you don’t know how to do it. When you are set feel free to proceed!

Download OpenC/C++ SDK Plug-In 1.7.5: s60_open_c_cpp_plug_in_v1_7_en.zip

If we try to build the current version using the old script (install_openc_16_s60 in gnupoc-package-1.16/sdks) we get:

./install_openc_16_s60 ../../qt-symbian/s60_open_c_cpp_plug_in_v1_7_en.zip ../../symbian-sdks/s60_31
Archive:  ../../qt-symbian/s60_open_c_cpp_plug_in_v1_7_en.zip
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/data1.cab
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/data1.hdr
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/data2.cab
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/ISSetup.dll
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/layout.bin
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/Nokia_EULA.txt
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/NOKIA_lgpl.txt
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/README.txt
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/setup.exe
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/setup.ini
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/setup.inx
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/setup.isn
inflating: openc_temp/s60_open_c_cpp_plug_in_v1_7_en/_Setup.dll
Failed to open openc_temp/Installer/data1.cab as an InstallShield Cabinet File
Removing temporary files...

As you can see the script is trying to unshield the data1.cab but it is looking for it in the wrong place, that is:

openc_temp/Installer/data1.cab

instead of:

openc_temp/s60_open_c_cpp_plug_in_v1_7_en/data1.cab

so we need to correct this by editing lines 25,31,37,45 of install_openc_16_s60 replacing:

$TEMP/Installer/data1.cab

with:

$TEMP/s60_open_c_cpp_plug_in_v1_7_en/data1.cab

Now the script should successfully extract the needed files from the installer, but this is not enough, in fact it dies again with:

openc_temp/opencepoc32_3.1/epoc32: No such file or directory

Why? Well the script creates a temporary directory that is removed upon completion (or error) where all the files are extracted and is looking for the directory  openc_temp/opencepoc32_3.1/epoc32 but the real directory is located at openc_temp/opencepoc32_3.1/EPOC32. I think the script tries to rename all files to lowercase by calling the lowercase perl script on the path, but for some strange reason it isn’t doing the job right so we need to resort to the oldest of hacks: manual editing!
To do so we need to prevent the script from deleting the temporary directory when it fails so that we can correct the directory name and re-execute the installer script. To achieve this simply comment out line 17 of install_openc_16_s60:

from:

trap "echo Removing temporary files...; rm -rf $TEMP" EXIT

to:

#trap "echo Removing temporary files...; rm -rf $TEMP" EXIT

When you have done this execute the script and when it dies manually browse to the location specified and rename the EPOC32 directory to epoc32 and re-execute the script (if it asks if you want to replace existing files select [N]one).

The error should popup 2 or 3 times for different paths and you should repeat the same steps every time.

This should be enough to get OpenC/C++ 1.7.5 installed in your GnuPoc environment!

Now download Qt libraries 4.6.3 for Symbian (210 MB): qt-symbian-opensource-4.6.3.exe

Next you simply need to follow the instructions in READEME.qt (found in gnupoc-package-1.16/sdks) by running:

./install_qt qt-symbian-opensource-4.6.3.exe -qt ~/symbian-sdks/qt_4.6.3 -sdk ~/symbian-sdks/s60_31

For me it all went ok except that the script failed near the end (line 92:1) with a syntax error (maybe some issues with my sh version?) so I had to manually run:

../tools/compile_qt_cross_tools ~/symbian-sdks/qt_4.6.3

This are quick and dirty hacks indeed, but they seem to work at the moment.
Let’s hope for a GnuPoc bugfix soon!

I really don’t understand why Nokia doesn’t provide an official SDK  for linux. I know there are porting costs, but isn’t it always the case? I think this is even more absurd now that they released a Qt SDK for linux without an official toolchain! Do they seriously think that the remote compiler service can be a practical solution?
Once again, even if I appreciate the small steps toward the linux community, I’m left with the old impression that Nokia’s way of supporting development for their platform is messy and that it suffers from severe lack of organization.
I think they don’t understand (unlike Apple) that the success of their platform is heavily linked to the applications supporting it. They can do all the Ovi Store they want but without a proper set of development tools it will always be populated only by huge company developed apps (read Skype or Opera Mini), and I don’t know you, but I don’t think this is the real purpose of an app store.

No related posts.

I’ve recently introduced myself to the world of microcontrollers (μC for short, if you feel cool enough), I’ve always found the world of digital electronics quite fascinating, being very fond of the DIY way of thinking, but I only recently decided to get my hands dirt with it and bought some PICs from Microchip and a PICKit 3 Debug Express. As a musician, the microcontrollers’ world opened quite a number of interesting possibilities. If you consider my undying need for a good MIDI controller and add to that the enjoyment I get from embarking myself in projects way out of my league, the result is obvious: build a MIDI controller!

The internal AUSART

The purpose of this article is to explain how to use the PIC’s internal UART to send MIDI messages to a MIDI enabled device. Almost every recent PIC microcontroller has an internal AUSART (Addressable Universal Synchronous Asynchronous Receiver Transmitter) that makes the task of implementing the MIDI protocol quite trivial. Without getting into details (saving me the embarrassment of explicitly saying I don’t know them), an USART is a device that converts streams of serial data to parallel data (or vice versa) using either an asynchronous or synchronous communication. In case of an asynchronous communication, the two communicating devices must agree beforehand on the transmission speed and start and stop bits are required to mark any data transfer. The start bit must be a space (logical zero, low) and the stop bit a mark (logical one, high). In the attempt to preserve data integrity a parity bit can be sent before the stop bit. If the parity bit is present, the two devices must agree on the format before they start exchanging data: the parity bit can be set whether if the number of logical ones in the data’s bits is even or if it is odd. The communication speed is expressed in baud, that is a synonymous for symbols per second. In our case 1 symbol = 1 bit, so 1 baud = 1 bit/s. The data is sent from the least-significant bit to the most-significant one.

The MIDI protocol (a.k.a The Real Stuff)

By now, if you really read through this point without skipping (in which case, shame on you!), you’ll start to wonder what all this have to do with our MIDI controller, and the need to turn some knobs is probably starting to get uncontrollable, so hear this: the MIDI protocol exchanges data using serial communication, each packet is made of a start bit (a space) followed by eight data bits, least-significant bit first, and finally by a stop bit (a mark). The data transfer and reception happens asynchronously at 31250 baud, rings any bell?

All we have to do now is understand how to configure and use the internal AUSART of our PIC (in my case a 16F88) in the way I just described.

Reading the data sheet for the PIC16F88 (chapter 11.2.1 AUSART ASYNCHRONOUS TRANSMITTER), the steps for setting up the AUSART for asynchronous transmission are listed:

1. Setup the Baud Rate Generator (BRG)
2. Setup the asynchronous serial port by clearing bit SYNC and setting SPEN
3. Set bit TXIE to enable interrupts
4. Set bit TX9 for 9-bit transmission (generally used for the aforementioned parity check)
5. Set bit TXEN (that will set TXIF also) to enable the transmission
6. If TX9 is enabled, load the 9^th bit in TX9D
7. Load the 8-bit data in the TXREG register (this action starts the transmission)
8. Ensure the GIE and PEIE bits are set in the INTCON register if interrupts are used

This should all be pretty clear if you have some experience in developing on the PIC microcontroller. What remains to be further explained is the first step where a Baud Rate Generator is mentioned: the AUSART has an internal 8-bit timer that takes care of sending our data at the speed we need. To configure this timer we need to act upon the SPBRG register and the BRGH bit, but because of the 8-bit limitation of the BRG timer, and of the high values of the most common baud rates, setting up the BRG is not as straightforward as you may think. The data sheet informs us that the baud rate that will be used to transmit data is calculated using the following formula (Table 11-1):

Where:

• FOSC is the speed of the PIC’s oscillator
• SPBRG is the value of the 8-bit (0 – 255) register
• C is a constant and its value is defined by the following table:

So, doing some math (probably wrong!), if we know what’s the baud rate we want, we can calculate our SPBRG value using the following:

The MIDI protocol operates at 31250 baud so, assuming that we are using the internal oscillator set at 4Mhz and that we are not using an high baud rate (BRGH = 0), the SPBRG value we need would be:

So let’s recap:

This is all we need to get the internal AUSART to send MIDI data, just put the MIDI byte to send in the TXREG and busy wait (or if you want, use interrupts) for TXIF to clear and you are done!

TXIF will be set if the AUSART is busy sending data and can’t accept new data in the output buffer so you have to wait until it clears to proceed.

MIDI messages overview

If you don’t know how MIDI messages works I’ll give a brief explanation: most MIDI messages are composed of three bytes, the first byte is called the Status Byte and it is used to specify the kind of action you want to be performed. The Status Byte is OR-ed with the channel you want the message to be received on, so for each status byte you really have one nibble (4 bits) for the actual “action code” and the other nibble for the channel, leading to 16 (0xF) functions and 16 (0xF) channels (as you’ll probably already know!). The meaning of the following one or two bytes depends on the value of the most significant 4 bits of the Status Byte (what I called action code).

For example to send a Note On message for note C4 on channel 6 with a velocity of 80 you would send:

• Status Byte = 0×90 (Note On) OR 0×6 (Channel) = 0×96
• Byte 1 = 0×3C (60 is middle C or C4)
• Byte 2 = 0×50 (80, the velocity)

You can take a look at the following websites for further informations on the available MIDI messages:

• http://www.opl4.nl/aboutmidi.html
• http://www.midi.org/techspecs/midimessages.php
• http://www.oktopus.hu/imgs/MANAGED/Hangtechnikai_tudastar/The_MIDI_Specification.pdf

Or, if you don’t really know what to do with your money and/or you have an unusual fetish for printed documents, you can buy (yeah! BUY!) the official specification document from http://www.midi.org/store/docsales.php for only 60$ (or if you are here in Italy 88$)

If you have come so far, it is now time to test your hard work! To do so you should connect the 5^th pin of your female 5-pin DIN connector to the Tx pin of your PIC (on my PIC16F88 it is RB5, consult the Pin Diagram section of the data sheet for you PIC to find out what’s the correspondence with Tx for your model) and the 4^th pin on your +5v power source, both through 220 Ohm load resistors, and you are set to go!

What to do next, now that you are cool

Once you are able to send MIDI data with your microcontroller, the next step can be connecting a switch and mapping it to a specific MIDI message, or using the internal ADC converter of your PIC (if you are in luck, it has one) to send the value of a trimmer (or pot) using MIDI’s Controller Change messages.

Source code and Links

Anyone interested can download the little library I made to send basic MIDI messages with my PIC16F88 (but should work for others too) which I’m releasing under GPL. It was written for the CC5x compiler, if you don’t have it,  you can get a student version here that has no limitations on the size of the compiled code (only on the optimization level), it also directly outputs compiled code to ASM (MPASM), so if you don’t want to use the CC5x compiler, but you like my library (what? Why?), you can simply compile it to ASM and use it with your favorite one.

Well, this is it! Thanks for reading and if you are getting into DIY MIDI controllers check out this nice websites:

• http://www.audiomulch.com/midipic/Has lots of informations on how to use a Basic Stamp or PIC to send/receive MIDI data and interface different type of hardware to the microcontroller.
• http://www.ucapps.de/
  A fantastic, huge, project to build your MIDI controller/sequencer with a modular approach. It is also the home of the MIOS operating system for different type of microcontrollers, a robust operating system developed to be used on hardware MIDI applications.

No related posts.

This bash script attempts to setup a clean environment for your new project doing the following things:

1. SVN repository setup in /var/svn/repos (by default)
2. Trac environment setup /var/www/trac (by default)
3. Setup of a password-protected virtual host in Apache linked to location /trac

It uses zenity to graphically interact with the user (so GNOME only, sorry!). Every step in the setup process, except for the SVN repository setup, can be skipped at runtime and default paths can be changed by editing the script source.

I’m releasing this script under the MIT license, before downloading keep in mind that I made this for my personal use and so I haven’t tested it with other configurations except for mine, so don’t blame me if it blows up your environment!
If it did not, I’m glad it spared you some work!

To run open your favourite terminal application and chmod +x the script file, than type:

./setwspace.sh

Download:
Set Workspace Script (23)

The script in action

No related posts.

The BarrySoft website needed a big restyling, so I took the chance to add my personal noise to the information world with this blog, that I hope will allow me to share with you some of my works as well as keeping me motivated to carry on those that are not yet finished.

I also think, that exchanging opinions is one of the greatest use of the internet, so don’t hesitate to contact me if you feel to!

While you are here I may suggest you to:

• Take a look at my Ports, including my Marathon AlephOne port for the PSP
• Check out the little applications I made in the Software page

Enjoy your stay in this memetic-underdog blog!

No related posts.