Installing Ubuntu on Parallels desktop (/dev/disk/uuid error)

I recently started to develop some software for the beaglebone, and since I do most of my stuff on my Mac, but developing for the beaglebone requires a "real" (sic!) Linux machine, because the openembedded build system used for managing your cross compiler etc., does not really run on Mac OS X, I installed a virtual ubuntu machine on my Mac.

Marcus from interactivematter gave me a nice link to get a minimal installation on a virtual machine, which can be found here:  http://nut-bolt.nl/2012/ubuntu-virtual-machine/

Only problem: it does not work, after installing you try to boot via the bootloader and the bootloader complains with something like

Alert: cannot find /dev/disk/uuid-SOMELARGENUMER

I banged my head against the wall a couple of times, and tried to google the problem, but most of the problems were very specific about update problems withing Ubuntu proper. I found a solution in the end, which I write down now for eternity:

1. Stop your virtual machine
2. Go into the virtual machine settings
3. Go to the harddisk settings
4. Change your Harddisk from SATA0 to SCSI 0 
5. Reboot, be happy.

 

AudioLab

Vor einiger Zeit hatten wir mal in der baustelle Hamburg Besuch von Soundpauli, einem kleinen Shop, der phantastische tragbare Lautsprechersysteme bastelt. Das hat mich einfach mal angeregt, mein eigenes Beachsoundsystem nochmal ein wenig weiterzuentwickeln, bzw. die Auftragsarbeit, die aus meiner damaligen Tupperwaredose entstanden ist, aufzugreifen. Diesmal mit einen kleinen 3,5 Watt Verstärkermodul von Kemo. Das Ding hat ganz schön Wumms, so dass der kleine Lautsprecher im Vordergrund etwas überlastet war. Aber der Lautsprecher vom Gitarrenverstärker im Hintergrund konnte prima mithalten.

Idiots Guide to AVR programming Interrupts

In todays part we do something a bit more interesting and write an interrupt handler, something you cannot easily do within the Arduino programming language.

Imagine you have have an external signal, such as a button which a user can press, or a signal which is send to you by some other machine, and you want to react to that signal. Instead of the button in the circuit you can also just use two cables and hold them together.

void setup() {

  pinMode(13, OUTPUT); // configure pin 13 as output

  pinMode(2, INPUT); // configure pin 2 as input

  digitalWrite(2, HIGH); // use internal pullup resistor

}

void loop() {

  if (digitalRead(2) == LOW) {

    toggleLed();

  }

  // do something else

}

void toggleLed() {

  digitalWrite(13, !digitalRead(13));

}

That kind of sequence is often very fine, but depending on the part of "do something else, e.g. when it takes a long time to execute, you might actually miss when someone presses the button. Or when "do something" is very short, and your grandmother presses the button, it will toggle all the time. So this code is actually very errorprone. It is just a simple example.

We define some requirements first:

The behaviour we would like is:

• whenever someone presses the button, the LED should be toggled (PIN2 goes low)
• the LED should toggle only once per button press. (PIN2 stays low)
• the LED shall not toggle when the button is released (PIN2 goes high again).
• No matter when someone presses the button, we want to react.

To meet these requirements, interrupts come to the rescue, and the Atmel chip which is used inside the Arduino has many kinds of Interrupts. Two very simple to programm ones are INT0 and INT1 which are associated with Pin2 and Pin3 (have a look at http://justjoheinz.posterous.com/idiots-guide-to-avr-programming-i for the pin mapping). These are hardware interrupts and the almighty wikipedia tells us, that 

A hardware interrupt causes the processor to save its state of execution and begin execution of an interrupt handler.

In English: when the interrupt occurs we can execute the interrupt handler at any time, and resume our execution anywhere where we had been before the interrupt started.

Atmel chips use a table which assigns a given interrupt a function which shall be executed. In reality it is slightly different, but never mind.

Do define the interrupt handler and assign it to the according entry in the table we write this:

ISR(INT0_vec) { // INT0_vec is the predefined vector which is assigned to INT0 aka pin 2, ISR sets this vector in the vector table

  digitalWrite(13, !digitalRead(13));

}

This methods replaces toggleLed() which we wrote before, and because toggleLed is now removed from our code, we can also delete everything in the loop() function. We can compile and execute our sketch now, but nothing will happen, because we have not told the processor yet that we want to deal with interrupts and we have not told it yet how we want to deal with interrupts.

To do this, the setup method has to be enriched with some AVR magic. Add the following to the end of your setup() function:

EICRA |= _BV(ISC01);

EIMSK |= _BV(INT0);

sei();

EICRA and EIMSK are again special registers and they are defined in the datasheet, have a look at the bottom of page 73. In the table you can see that for INT0 any time you want to trigger an interrupt on the falling edge of INT0 the Interrupt Sense Control bit 1 need to be set (EICRA |= _BV(ISC01);). Study the other possibilities as well.

Have a look at the next page for the explanation of register EIMSK and you see that we need to enable INT0 (EIMSK |= _BV(INT0);)

The call to sei() simply enables interrupt handling in general.

The finished sketch:

void setup() {

  pinMode(13, OUTPUT); // configure pin 13 as output

  pinMode(2, INPUT); // configure pin 2 as input

  digitalWrite(2, HIGH); // use internal pullup resistor

  EICRA |= _BV(ISC01);

  EIMSK |= _BV(INT0);

  sei();

}

void loop() {

 

}

ISR(INT0_vect) {

  digitalWrite(13, !digitalRead(13))

}

Oh, by the way: if your LED blinks a little erratic - it is because you have shaky hands or your button bounces. And one more really useful thing: instead of configuring pin 2 as an input pin, you can also use it as an output pin. Whenever you write something to this pin in your normal control flow, you are able to trigger the interrupt, depending on your ISC bits.

Idiots Guide to AVR programming reference

As I move along with the Idiots Guide to AVR programming, updates and references will be posted here:

Datasheets:
Atmel 328P datasheet: http://www.atmel.com/dyn/resources/prod_documents/doc8271.pdf

AVR-C:
Lib C Documentation: http://www.nongnu.org/avr-libc/user-manual/index.html

Idiots Guide to AVR programming I

So you have your Arduino and are curious to get to know "real" AVR-C
programming using all the cool tool chains, but do not quite know
where to start?
Ok, start your Arduino IDE, load the simple Blink sketch into your IDE
and upload it to your board to verify that all your connections are
working. After the upload you can observe the sketch size: mine is
1018 byte.

Now, when you program the Atmel chips all the pin assignments will be
slightly different. They are organized in ports and on the Arduino
site there is a nice overview where you find which pin on the Arduino
on the actual chip:

Looking for digital pin 13 (your blinking LED pin) gives us PB5. That
is Pin 5 on port B.
Now we change our sketch, and changes one line only: change
digitalWrite(13, HIGH);
to
PORTB |= _BV(PIN5);

Recompile, et voila: a blinking LED and a file size of 1012 bytes. 6
bytes were optimized! But what happened? PORTB is a register variable
which "contains" the on and off states of the pins which are
associated with this port. And we simply say that we want to set Pin5
to 1 leaving all other pins unchanged. To fully comprehend this, you
need to know about bit manipulation and boolean logic. Again there is
a good intro on the Arduino site:
http://www.arduino.cc/en/Reference/PortManipulation

Now it is time to change the other digitalWrite command, this time we
need to turn the LED off. We achieve this by rewriting the line with:

PORTB &= ~_BV(PIN5);

Recompile and sweet: because we got entirely rid of the digitalWrite
function, the size of the sketch was reduced to 830 bytes.

Now, we turn towards the setup routine. Here Pin 13 is declared as
output pin. Again there is a register for each port which controls
whether pins belong to this port are inputs or outputs. The register
is DDR (data direction) and we use the register DDRB for port B.
Let's replace the pinMode function by:

DDRB |= _BV(DD5);

And - whoopee: 658 bytes! We almost reduced the size of the sketch,
leaving us with much more space to do stuff.

Once again the complete source:
/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.

This example code is in the public domain.
*/

void setup() {
// initialize the digital pin as an output.
// Pin 13 has an LED connected on most Arduino boards:
DDRB |= _BV(DD5);
}

void loop() {
PORTB |= _BV(PIN5); // set the LED on
delay(1000); // wait for a second
PORTB &= ~_BV(PIN5); // set the LED off
delay(1000); // wait for a second
}

Back to index: http://justjoheinz.posterous.com/idiots-guide-to-avr-programming-index

Idiots Guide to AVR programming Index

Part1:

Pololu based stepper motor driver

If all goes well, I can hook up my new stepper driver today. It is
from Rob Giseburt (http://www.thingiverse.com/thing:4526) and offers a
smooth 1/16th stepping mode, connectors for end stops and utilizes the
pololu stepper boards. So if one blows, it is just a matter of plug
and play to get going again.

I assembled it today and connected it. It is really nice. Makes the
Makerbot very quiet (not that I would really care, but maybe the
neightbours).