Problems With The Sunfounder Starter Kit For Arduino

Recently, work had some Sunfounder Arduino kits delivered to the office for people to experiment with. I thought I'd borrow one of the Starter Learning Kits and work my way through the lessons.

As I encountered some problems getting started, I thought I'd document these here, both for my own reference and in case it's of use to anybody else.

Problem: Contents

According to the contents list, there's supposed to be 18 LEDs, comprised of 8 x Red, 5 x Yellow and 5 x Blue. The way they've been bagged up is in a group of 5, 3 and 10. There seems to be no way to determine what colour each is (they just look clear when not turned on) and as I haven't tried plugging them all in, I don't yet know whether they are in fact the right number of each colour or not.

There are also apparently supposed to be 30 male to female jumper wires, but there are actually only 10.

The contents lists 10 buttons, and there are actually 10 buttons…plus another 4 smaller ones that get no mention at all (though are used in the first lesson).

Problem: DVD Size

Rather than ship a full-size DVD with the kit, a mini-DVD is included. The problem with that is that these don't work in slot-loading drives. Luckily for me, I have a PC with a disc-tray type drive on it, so I was able to use that machine to copy the contents of the DVD off and then network share that with other machines.

Problem: Photo/Diagram Size

The booklet with all the lessons in is pretty small:

(Coin included for scale.) The text even more so. Whilst my eyesight is good enough to read the general copy (well, once I've put my glasses on, anyway), I struggle to read the text on some of the diagrams, making them quite hard to interpret.

Problem: Photos Don't Match pictures

Each lesson includes a schematic, a diagram and a photo. The problem is that the photo and the diagram often don't match exactly. Now, I realise that there are an almost infinite number of ways to wire-up the components into the same actual electrical circuit, but as a beginner, it would really help if the photo and diagram exactly replicated each other. I don't really have a grasp yet of how everything connects up and having this discrepancy makes it difficult to spot where I've gone wrong when things don't work.

Another aspect of the photos that don't quite tie up with the instructions is that, in the photo for lessons 1 and 2, the Arduino board is being powered via the DC input, and not via the USB connection. This is a smaller issue than some of the others, but can still be a bit off-putting when trying to follow something to the letter and there is a mis-match between what the text says to do (use the USB cable) and what the photo demonstrates.

Problem: No Explanation Of Breadboards

The lessons do include a "Principle" section providing some background to the current lesson, but one thing it doesn't do at any point is detail how the breadboard works. This caused me some problems as when something didn't work, I didn't have a clear enough understanding of what the underlying electrical circuit was as I didn't know how the holes on the breadboard were actually connected together inside. I ended up searching the internet and came across a good explanation here. I was quite proud of myself, once I'd read this to then be able to fix the problem I was having with lesson 3, Interactive LED Flowing Lights.

Problem: Booklet Lessons Don't Match Website

When I was encountering problems following the lessons in the booklet, I tried visiting the Sunfounder website. Unfortunately, the particular lesson I was having difficulties with (lesson 3, Interactive LED Flowing Lights) does not seem to actually exist there. It has a flowing lights lesson and it has a potentiometer lesson but not one that has the two together as exists in the booklet.

Problem: The Code

The lessons in the booklet are all about the hardware—wiring the components together. The only reference to code in each lesson is when you get to the second step:

Step 2: Program (Please refer to the example code in our CD)

It then goes on to the next step:

Step 3: Compile and debug the program
Step 4: Burn the program into SUNFOUNDER UNO board

This is far from the level of instructions necessary to achieve anything. If you look at the contents of the DVD, it contains a directory for each lesson and one more for "fritzing". At no point is it explained what Fritzing is or what it is for (it turns out that within each lesson directory is a circuit sub-directory that contains a .FZZ file that Fritzing can be used to open—it then displays the diagram that is shown in the booklet).

Also in the lesson directory is a code sub-directory that contains a single .INO file. Nowhere is it stated what the format of this file is (it's actually just a text file) or what application can be used to open it. After some more searching of the Internets, I discovered that .INO files are used to store Arduino sketches. These sketches can be compiled and uploaded to Arduino boards using the Arduino Development Environment. Instructions on how to get started can be found here, which links to getting started instructions for Windows, Linux and Mac.

Problem: Resistors

According to the contents, there are 5 x 10K resistors, 5 x 1K resistors and 8 220R resistors. The resistors are packaged in 3 groups of sizes 8, 5 and 5; thus it seems reasonable to assume that the group of 8 is the 220R resistors, but what about the two groups of five? There's no indication in the booklet about how to differentiate them. There are some coloured bands around them and the labels that the resistors are stuck to have a coloured band on, but nowhere does it state what any of these mean (I still have no idea what the coloured bands on the labels indicate).

There are various websites that explain how the colour-coding system on resistors works. My main problem though is telling which way round to read them. Since these resistors are 5-band and contain one on the bulge at each end and 3 in the mid-section it doesn't seem possible (to me at least) to work out which way round they should be read.

Inputting the band colours into the calculator here results in a rating of 10K for the green-labelled resistors if read with the green label on the left or 120 if read the other way around. Similarly, for the red-labelled resistors the values are 110 and 1K respectively. This would seem to indicate that the green-labelled resistors are 10K ones and the red-labelled ones are 1K ones. It is slightly worrying though that they have to be read opposite way rounds to each other in order to reach these numbers (i.e. the green-labelled ones should be read with the label on the left and the red-labelled ones should be read with the label on the right). Once removed from the labels it also becomes even harder to know which are which.

Conclusion

That just about sums up the problems I've encountered trying to complete the first 3 lessons in the booklet. Hopefully this will save someone else time in the future so they don't get as frustrated as I did. Enjoy, and good luck!

Here is a photo of my solution to the "Interactive LED Flowing Lights" lesson, complete with working speed control!

Amending A Previous (But Not The Most Recent) Git Commit

Sometimes I have a few local git commits that are yet to be pushed. Occasionally when this happens, I realise that one of those commits is broken (e.g. I forgot to include something in it). In such cases the following is a useful means of editing a previous commit.

WARNING: Attempting to do this for a commit that has been shared with others (e.g. by pushing to Github) may cause serious injury or death (ok, probably not, but it might cause a bit of upset).

If you have the changes to apply in your work area, stash them now.

Identify the commit before the one to be amended (you'll need its commit hash). Use a tool such as GitX (L) if you like (or you can just use git-log).

Run git-rebase: git rebase -i <commit-hash>

This will bring up an edit window (in vim on my machine). Each commit after the one identified by <commit-hash> will be listed and will be initially prefixed by pick. For the commit you want to amend, change pick to edit. Save and exit (i.e. :wq in vim).

Make the required amendments to the commit (e.g. git stash apply if those changes had been stashed).

git add -p to stage those changes.

git commit --amend to amend the commit.

git rebase --continue to apply any subsequent commits.

Et voila, your commit history has been updated!

Simples.

Autoresizing Masks in the Cocoa Framework

I've been struggling a bit to get my head around exactly how the different UIViewAutoresizing values work together. This post is an examination of trying out various combinations and documenting the effects.

The first thing to do is set up two views, one within the other. Then, the autoresizingMask of the inner view is set and the frame of the outer view changed.

This is what the two views look like before any resizing:

Below are the results of changing the size of the outer view's frame, using various values for the inner view's autoresizingMask property.

UIViewAutoresizingNone:

This causes the inner view's frame to remain unchanged.


UIViewAutoresizingFlexibleTopMargin:

This causes only the y coordinate of the inner view's frame to change.


UIViewAutoresizingFlexibleBottomMargin:

This causes the inner view's frame to remain unchanged.


UIViewAutoresizingFlexibleLeftMargin:

This causes only the x coordinate of the inner view's frame to change.


UIViewAutoresizingFlexibleRightMargin:

This causes the inner view's frame to remain unchanged.


UIViewAutoresizingFlexibleWidth:

This causes only the width of the inner view's frame to change.


UIViewAutoresizingFlexibleHeight:

This causes only the height of the inner view's frame to change.


UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleHeight:

This causes the y coordinate and height of the inner view's frame to change.


UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleWidth:

This causes the x coordinate and width of the inner view's frame to change.

MacPorts & Mono

Problem updating MacPorts and have Mono installed? Read on...

I was setting up my Mac Book Pro so that I could work on the RapidFTR project and I ran into some trouble. The instructions for installing and running RapidFTR on OSX specify that MacPorts should be installed. Having downloaded the installer for version 2.0.1, I ran the sudo port selfupdate command as suggested; here began my trouble:


---> Updating MacPorts base sources using rsync
MacPorts base version 2.0.1 installed,
MacPorts base version 2.0.3 downloaded.
---> MacPorts base is outdated, installing new version 2.0.3
Installing new MacPorts release in /opt/local as root:admin; permissions 0755; Tcl-Package in /Library/Tcl

Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command failed (see log for details)


This wasn't particularly helpful, though there was a vague statement about some log file (nothing so helpful as where this file might be located though!). Having no idea where to look for the log, I looked in /var/log. This contained a bunch of log files, though none of them looked specific to MacPorts. OK, I thought, perhaps it puts them in system.log.

Turns out it doesn't.

My next idea was to look in install.log, as an update is a kind of installation, right?

Turns out it doesn't put it in here either.

However, what I DID see in here was the output from running the original 2.0.1 installer package. It turns out that this had also tried to perform an update and it too had failed (not that it reported this when I ran it, mind). Amongst its output there was a suggestion of running the selfupdate command with the -d flag to get more specific output. Running this command produced the following output (only the key part is included):


In file included from entryobj.c:36:
/Library/Frameworks/Mono.framework/Versions/2.10.3/include/sqlite3.h:252: warning: ISO C90 does not support ‘long long’
/Library/Frameworks/Mono.framework/Versions/2.10.3/include/sqlite3.h:253: warning: ISO C90 does not support ‘long long’
/usr/bin/cc -dynamiclib -g -O2 -W -Wall -pedantic -I/Library/Frameworks/Mono.framework/Versions/2.10.3/include -Wl,-single_module registry.o util.o entry.o entryobj.o ../cregistry/cregistry.a -o registry.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5 -L/Library/Frameworks/Mono.framework/Versions/2.10.3/lib -lsqlite3
ld: warning: ignoring file /Library/Frameworks/Mono.framework/Versions/2.10.3/lib/libsqlite3.dylib, file was built for unsupported file format which is not the architecture being linked (x86_64)
Undefined symbols for architecture x86_64:
"_sqlite3_errmsg", referenced from:
_set_sqlite_result in util.o
_reg_sqlite_error in cregistry.a(registry.o)
_reg_detach in cregistry.a(registry.o)
_reg_close in cregistry.a(registry.o)
_reg_attach in cregistry.a(registry.o)
_reg_open in cregistry.a(registry.o)
"_sqlite3_mprintf", referenced from:
_set_object in util.o
_set_entry in util.o
_get_object in util.o
_reg_sqlite_error in cregistry.a(registry.o)
_reg_detach in cregistry.a(registry.o)
_reg_attach in cregistry.a(registry.o)
_reg_open in cregistry.a(registry.o)
...
<!--Bunch of other _sqlite* symbols-->
...
"_sqlite3_changes", referenced from:
_reg_entry_delete in cregistry.a(entry.o)
_reg_entry_deactivate in cregistry.a(entry.o)
_reg_entry_activate in cregistry.a(entry.o)
_reg_entry_unmap in cregistry.a(entry.o)
"_sqlite3_column_text", referenced from:
_reg_entry_files in cregistry.a(entry.o)
_reg_entry_imagefiles in cregistry.a(entry.o)
_reg_entry_propget in cregistry.a(entry.o)
"_sqlite3_value_text", referenced from:
_sql_regexp in cregistry.a(sql.o)
"_sqlite3_result_int", referenced from:
_sql_regexp in cregistry.a(sql.o)
"_sqlite3_result_error", referenced from:
_sql_regexp in cregistry.a(sql.o)
"_sqlite3_create_function", referenced from:
_init_db in cregistry.a(sql.o)
"_sqlite3_create_collation", referenced from:
_init_db in cregistry.a(sql.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [registry.dylib] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1
shell command "cd /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base && CC=/usr/bin/cc ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline && make && make install" returned error 2
DEBUG: Error installing new MacPorts base: shell command failed (see log for details)
while executing
"macports::selfupdate [array get global_options] base_updated"
Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command failed (see log for details)


This seemed to suggest that it might be something to do with the Mono installation I had…With this extra information in hand, I was finally able to perform a search that turned up a useful result (in fact it was the only result). Buried within this set of email threads was the key message:


> It appears the problem is MacPorts is grabbig SQLite from
>
> /Library/Frameworks/Mono.framework/Versions/2.10.3/include/sqlite3.h
>
> Obviously, part of the problem is that the version of SQlite being
> found/used is from the Mono SDK (installed from go-mono.com),
> installed at /Library/Frameworks/Mono.framework.

You nailed it: that's precisely the issue.

>
> The odd thing: As far as I can tell, MacPorts should be using the
> frameworks in /opt/local/Library/Frameworks:
> (from the configure script output:)
> checking for Frameworks installation directory...
> /opt/local/Library/Frameworks
>
> What do I need to do to get 'port selfupdate' to ignore the Mono framework
> in
> /Library/Frameworks
> And use the one(s) in
> /opt/local/Library/Frameworks?

In this instance, when MacPorts is checking that directory it is for
creating it and not using it. MacPorts will use the SQLite from:
/usr/include/sqlite3.h
or applicable Xcode SDKs.

As a workaround, I'd recommend you move the mono framework temporarily out
of /Library/Frameworks, selfupdate MacPorts, and then put your Mono
framework back.


So I tried doing this (sudo mv /Library/Frameworks/Mono.framework/ ), et voilà, retrying the MacPort selfupdate worked!