Open Source Development in Malawi

Open Source Development in Malawi on Prezi

Posted via email from snim2's posterous

Experiments: why and how

Experiments: why and how on Prezi

Posted via email from Pass your final year project

Top 5 writing mistakes made by project students

A large part of any final year thesis project is the write-up, but every stage of the project will involve some form of writing. Whether you are writing a proposal, an interim report, a draft report, documentation or the final thesis, a very large part of your time will be spent composing text. These are the top ten mistakes we see from students year on year, avoid them and you can save yourself a lot of time (and earn a lot of marks)...

 

1. Unsubstantiated claims

As a general rule, any statement of fact or opinion about your work, or your topic of study should be substantiated in some way. You don't have to worry about the bleeding obvious, we know that 1+1=2 (unless your work is in the "foundations" of mathematics or philosophy, in which case 1+1 may well be undefined), but anything less obvious should be backed up by solid evidence. That evidence can be a reference to literature, an argument you make in your writing, the results of your own experiments, or any other suitably rigorous evidence.

Avoid so-called sweeping statements that are effectively impossible to substantiate "all Object Oriented programs couple algorithms and data". Do they? All of them? "Testing improves the performance of students". Really? These sorts of claims are poor academic practice and suggest that you have been a little sloppy in your thinking about your work, and of course that's not the impression you want to give.

 

2. Dangling pronouns and other references

 This seems to be an almost universal problem with student writing. Consider the following paragraph:

In his 1953 paper, Henry Gordon Rice proved that for any non-trivial property of a partial function there is no general decision method to determine an algorithm that computes a partial function with that property. It has far reaching consequences for compilers, static analysis and other fields in practical computing.

What does the "It" in the second sentence refer to? Rice's theorem, his paper, or something else? It isn't clear from the text, although we can guess that the author meant to discuss the theorem. Better though, to be clear about the meaning in the first place. Every pronoun ("I", "he", "she", "it", "that", "who", etc.) should clearly refer to exactly one noun. The first sentence gets this right, it is clear that "his" refers to the noun "Henry Gordon Rice" and not any other noun in that sentence. So, we could improve the paragraph above by re-writing it:

In his 1953 paper, Henry Gordon Rice proved that for any non-trivial property of a partial function there is no general decision method to determine an algorithm that computes a partial function with that property. Rice's theorem has far reaching consequences for compilers, static analysis and other fields in practical computing.

 

3. Using a secondary source rather than a primary one

It's much easier to read the popular press, blogs and other "informal" media than research papers. Very few marks will be awarded for this, though. In a final year project you need to show that you can perform a small academic study, so marks will be available for reading peer-reviewed academic literature. There are two major pitfalls to avoid here. Firstly, you will occasionally come across some disreputable conference or journal which does not use peer-review. Worse, it is possible to come across "articles" on the Internet which have citations and publishing records and look, to all intents and purposes, like a genuine piece of academic writing, but have actually never been submitted to a journal or conference. This is very poor practice on the part of anyone who puts this kind of thing up on their own blog or website, but it does occasionally happen. A reputable publishing venue will have some sort of statement on their website stating how articles are reviewed (look for "Instructions to Authors"). This should say that every article is reviewed by at least two people and sent back for corrections before being published. Without this sort of peer-review any poor standard of work can be "published" without anyone checking even basic standard of good practice, such as detecting plagiarism. That said, even with peer-review, some poor practice still slips through the net.

Secondly, whatever references you cite should be primary, rather than secondary sources. A primary source is one where the author(s) reports work that s/he (they) have personally carried out. A secondary source is one where an author reports on work that someone else has completed and published elsewhere. Secondary sources include news reports, magazine articles and blog posts about research completed by others.

 

4. Confusing structure and use before definition

Any academic writing should generally be written for a reader who is an expert in the general field of the study, but not necessarily in the specific area of the study. If, for example, your final year project is on genetic algorithms, your work might be marked by an expert in artificial intelligence, or in computer science generally, but not necessarily by an expert in GAs. So, write with that in mind, and make sure that you don't use any specific technical terms without defining them. This is often very difficult to get right at first, especially when you have been working with your own ideas for a very long time. A good plan is to swap drafts of your work with a fellow student who is on the same degree course but working in a completely different field for their final year project. If you can both understand each others work, that's fine. If not, make changes.

5. Claims of "proof"

At the beginning and end of your dissertation you will want to set out the aims of your work and describe the conclusions you have reached. Occasionally we see students writing sentences such as "this study proves that ...", "this thesis will prove ...", and so on. "Proof" is specifically a mathematical method, and if you have genuinely proven a theorem, by all means say so. If not, then don't use the word "prove" and be very careful about what you do claim. For example ...

• If you have tested a piece of software and it has passed all your test cases, then you have shown that your software is free of the specific errors you have checked for. You have not shown that it is "error-free" or "works".
• If you have performed some sort of user testing, or any other usability / accessibility testing, then you may have demonstrated that the system under study is "usable" or "accessible" as far as you have tested it. However, without a large-scale study that is as much as you can claim. Be very circumspect about reading research in the area of usability; there is much good research but also much which is over-blown. Be especially careful of authors who also run consultancy practices, make sure you cite their academic literature, and not anything that could be considered advertising. Make sure everything you cite is peer-reviewed.
• Be very, very careful about using questionnaires. I usually tell all my students to just avoid them altogether. It is very, very hard to produce a questionnaire which holds up under academic scrutiny and you will need an amount of statistical sophistication to produce sensible results. Also, you need a very large sample-size because your questions will be circumscribed (and for other reasons). This makes questionnaires very difficult to use in short, single-person projects. If you are in any doubt, then use a "semi-structured interview" to interview test subjects and the "talk-aloud protocol" or "cognitive dimensions of notation" for usability testing. Before you start, read some papers on evaluation methods, such as Hollingsed and Novick (2007) Usability Inspection Methods after 15 Years of Research and Practice, or Hornbaek and Law (2007) Meta-Analysis of Correlations Among Usability Measures.

 

Posted via email from Pass your final year project

Adding a minimal online interface to an imified.com chatbot

Recently, the people who brought you the excellent imified service, for creating IM bots, brought out phono, a simple JQuery interface to phone and IM services. Using Phono, you can create a simple front-end to an IMIFIED bot. The following code does this; you will need to replace the string MYBOT@bot.im with the address of your own bot, and you will need a free API key from phono to make this work.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">   <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">   <head>     <title>Live chat example</title>     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />     <meta name="robots" content="All" />     <meta name="copyright" content="University of Wolverhampton" />     <link id="theme" rel="stylesheet" type="text/css" href="/css/style.css" title="theme" /> <style type="text/css"> form {   width: 700px;   color: #3E4A49;   background-color: #EEEEEE;   padding: 20px;   margin: 20px; }   fieldset {   padding: 0 20px 20px;   margin: 0 0 20px;   border: 1px solid #3E4A49; }   legend {   color: #FFFFFF;   background-color: #444444;   font-weight: bold;   padding: 5px;   margin-bottom: 0;   width: 200px;   border: 1px solid #3E4A49; }   label { display: block; float: left; text-align: right; width: 100px; font-weight: bold; margin-right: 10px; }   #buttons {   text-align: right;   margin: -15px 0 -5px 0; }   input.button {   width: auto;   background: #FFFFFF;   border: 2px solid #4899BE; } textarea:focus, input:focus { border: 2px solid #9b251b; } .throbber { width: 100%; text-align: center; margin-top: 50px; } .throbber img { text-align: center; } </style> <script type="text/javascript" language="javascript" src="http://code.jquery.com/jquery-1.4.2.min.js"></script> <script type="text/javascript" language="javascript" src="http://s.phono.com/releases/0.1/jquery.phono.js"></script> <script type="text/javascript"> $(document).ready(function() {       var myPhono = $.phono({            onReady: function() {           $("#sendChat").attr("disabled", false);           $("#loader").hide(); $("#chat").fadeIn(2000);         },                messaging: {           onMessage: function(event) {             // Get message from event and log it             var message = event.message;             appendChat("\Chatbot:" + message.body);           }         },       }); // end .phono       $('#sendChat').click(function() {         var msg = $('#chatText').val(); if (msg.length == 0) { return; } appendChat("\nYou: " + msg);         myPhono.messaging.send("MYBOT@bot.im", msg);       });       $('form').submit(function () {         return false;       });       function appendChat(msg) {         // Append msg and scroll chat history.         var history = $('#chatHistory');         history.append(msg);         // If the text does not fit in the text box, scroll up.         history.animate({ scrollTop: history.height() }, 1000);         // Clear input box.         $('#chatText').val('');       }; }); // end ready </script>   </head>   <body>   <div class="throbber" id="loader">     <img src="images/spinner.gif"/>   </div>     <div id="chat" style="display:none">     <form id="chatForm">       <fieldset>         <legend>My chatbot is <span style="color:rgb(0, 255, 0);">ONLINE</span></legend>         <p><textarea cols="70" rows="20" name="messages" id="chatHistory" title="Live chat"></textarea><p/>         <p><input type="text" size="50%" name="message" id="chatText"/>&nbsp; <input type="submit" disabled="true" value="Chat" name="send" id="sendChat"/></p>        </fieldset>       </form>   </div>     </body> </html>

Posted via email from snim2's posterous

python-csp Europython round-up

Europython was excellent this year and while the range of talks was very wide, the main themes seemed to be web scripting and web applications, virtual machines and concurrency. Russel Winder gave a keynote on the future of multicore computers and their implications, and a longer talk about Python and the CSP style of concurrency, Michael Sparks gave a lightening talk about his work on Kamaelia, Andrew Francis talked about implementing ALTing in Stackless Python and Tony Ibbs talked about KBus, which is like DBus but sensible, and I gave an introductory talk on our python-csp project.

 

python-csp sprint report

Post-talks we had two days of Sprints and, having never been to a Sprint before I'm really amazed at how much we managed to get done in the python-csp sprint over such a short amount of time. I concentrated on the online tutorial which was well overdue for an overhaul, and the below is just a brief account of all our other activities -- apologies if I've missed anyone out or mis-attributed anything:

• Fabian Kreutz fixed and merged Russel's Python3 port into the default repository, closed a bunch of ancient branches, tidied up our strategy for importing the code library, fixed a whole load of bugs and hosted a Mercurial clone of the main repository on BitBucket for us.
• Russel started a MacOS port, found a whole world of issues with that, and fixed a few bugs. 
• Richard Taylor joined us on the Friday and helped configure Linux to solve the "too many open files on disk" OS error that is thrown when too many channels or processes are created. Tony Heskett told us how to fix the same problem on Mac OS. Richard also gave us some really great ideas about how to use the POSIX standard to finish off Sam Wilson's work on a C implementation of channels.
• Joe Metcalfe, Wout Tankink, Urban Skudnik and others went through the tutorials in some detail, fixing bugs and posting a bunch of bug reports. Fabian tried to eliminate some of the dependencies from the examples and make them a bit easier to understand. Urban also wrote a channel poisoning example and the tutorial page that goes with it.
• Michael Sparks had to go home, but joined us over IRC and gave us a better understanding of the differences between Kamaelia and other asynchronous forms of message passing and the CSP style of programming. Later Michael produced a really interesting OCCAM model of one form of Kamaelia synchronisation primitive, which has been a good prompt to sort out guarded ALTing for python-csp.
• Stefan Swarzer went through our testing strategy and started formalising a really neat way to unit test python-csp code and wrote up some unit tests for the large number of built-in processes we have in the library. Stefan also got us thinking about licensing issues for python-csp, which probably deserves a wider discussion elsewhere. 
• Andrew Francis dropped in briefly on his way to the PyPy sprint, and sent over a deadlock detection algorithm and some other ideas.

Thanks to everyone who came along to the Sprint, it was great fun and hopefully we can keep up some momentum. During the Sprint we added six new project members with commit privileges and set up a public mailing list. If you were at the Sprint or already had commit access to the repository you should already have received an invite to the list, but if not it is public so feel free to join.

Posted via email from python-csp

How to choose a good BSc or MSc project

Planning stuff...

A critical part of the success or failure of any thesis project is the initial choice of what to work on. This is a surprisingly difficult part of any project, in some ways the most difficult part, and it's something that we see students struggle with year on year. Nothing is so disappointing than marking a project and coming to the realisation that with some better decisions at the beginning of the year a failing project could have passed. This is a trap to avoid, and by avoiding it you will not only improve your chances of passing your project, you will greatly improve your chances of getting a first. In fact, projects are pretty straight forward to do well in, so long as you fully understand what is expected of you. This post takes you through what you need to focus on and avoid right at the start of your project journey.

 

Do something you are interested in

A final year or MSc project is a six month, single person project and in most Universities students will have to study several other modules concurrently. This is a long time to be working on a single piece of coursework, so it is important to choose a project which will hold your attention for that length of time. Moreover, you will be working on other things at the same time, so ideally you need to choose a project that is compelling enough that you want to work on it, in preference to doing other things. 

 

How to know what you are interested in

This might seem like a rather unnecessary topic -- what is "interesting" is very personal and individual. However, estimating what you might find interesting in several months time, when you are under pressure to meet deadlines is not easy. One trick to weight the odds in your favour is to choose a project which you do not, at the start of the project, entirely know how to complete. Like Einstein said: "If we knew what we were doing, it wouldn't be called research". Obviously, don't choose something that is completely outside your area of expertise. If you have spent two years studying bioinformatics then don't suddenly decide to try a dissertation in ceramics, but equally, if you know exactly how to complete every part of the work that you will need to do for your project then your idea is not "big" enough in scope. This point, really is the key to finding a project and much of the rest of this post expands upon it: a thesis or dissertation is not simply a long piece of coursework, it is an individual, self-contained work which should stand on its own. Think of it as a sort of "first job". When you leave University and apply for further study or a job, then the results of your project will be part of the professional portfolio of work you can use to convince a future employer to take you on.

 

Project difficulty: a difficult project is an easy project

By far and away the biggest mistake that we regularly see from students writing project proposals is choosing a project which is far, far too easy. The train of thought seems to go ... projects are difficult, I want to make the project easier, therefore, I will choose a simple idea to work on. The classic examples of this in Computer Science are "a website with a database" -- usually for a family member or friend who runs a small business -- or occasionally a website or database on their own. What's wrong with this? Well... so many things:

1. By the time a student has reached the final year of their degree, they will likely already have written several databases, websites and at least a couple of websites-with-a-database. Therefore, the project is something that the student has already been awarded credit for. This means that the student will not be demonstrating that they can learn independently, and go beyond what has been taught in lectures, which is one of the main purposes of the project.
2. Because the proposal is about the same size and quality as an individual module coursework, it is not large enough in scope to gain many marks.
3. An individual website, in ASP, PHP, or similar, for an SME is a very old problem for which there exist a large number of "turn-key" solutions -- that is, off the shelf products that can be used to create the product. These include templating systems such as Joomla, cloud-based solutions such as Google Sites, Posterous, Tumblr and so on, wikis, and a number of other technologies. A straightforward website-with-a-database is, therefore, in no way a demonstration of the students ability to work at the cutting edge of their field.
4. A website-with-a-database is not a problem, it's a solution to a problem. A project proposal should propose an interesting problem, with a suggested strategy for solving that problem during the progress of the project. 

Having said this, I have seen and indeed supervised a number of excellent projects, for which the student implemented some sort of website and some sort of database. So, it's not that websites or databases are inherently bad choices as solutions to the problems posed by a project proposal, but a proposal MUST overcome the four problems outlined above.

The heading for this section said (rather confusingly) that "a difficult project is an easy project". What I mean by this is that the "difficulty" of a project is something that will uppermost in the mind of the staff marking your thesis. A "difficult" project is likely to be looked upon favourably because it will be a bigger step away from what you have already been taught, you will need to be reading more academic literature, you will be showing more independent learning, and so on. These are some of the most important factors in getting a good grade, and far outweigh factors such as finishing every part of your practical work. The up-shot of this is that if you choose a "difficult" project and complete it quite poorly, you are likely to get better marks than a student who chooses an "easy" project and completes all of their practical work. If you did choose to work on a website-with-a-database-for-an-sme then the proposal will be so easy that you will really have to complete every part of the project perfectly just to get a pass. So, choose a small but difficult project.

 

Have a research question

In the last section I said that a project proposal should pose a problem, not a solution to a problem. Ideally, it is best to phrase this as a research question, such as the following:

• is algorithm X more efficient than algorithm Y?
• is it possible to implement product Z on the cloud?
• can feature L be added to programming language P?
• can theorem T be proven?
• can algorithm Z be adapted to be used in conditions C?

and so on. There are several advantages to this. One is that this is a standard form of writing in academia, and your project will be marked against academic criteria. Secondly, if the aim of your project is to answer a question then you leave the issue of how to answer that question reasonably open ended. It may be that you have a very clear idea, at the start of the project, what you are going to do. That's fine, but as you progress through the project you may well find literature that enlightens your views on how your question can be answered. Thirdly, your answer to the question may not be what you expect. That's fine, it's OK to find out that actually, your algorithm isn't as efficient as you thought, or the theorem cannot be proved, so long as you give solid, convincing evidence for your answer. 

 

Do something practical

If you are working in the sciences, it really is important that you do something practical as part of your work. For these purposes "practical" can mean experimental work or mathematical work -- it's OK to prove a theorem, for example, as the main part of the "practical" content of your work. What you should avoid though, is vague, nebulous, thought-pieces, which have no clear results and cannot be evaluated. Avoid anything with a title like "an investigation into X" or "a dissertation on Y". These sorts of writing are well accepted in the humanities, but for a scientific piece of work you need to propose a question and find some answer to it. Equally, a literature review is not really a project in itself, it needs some research question and evaluation with it to form a complete project.

 

Focus on evaluation from the start

Evaluating your work will likely be the last practical work you complete before finishing your dissertation writing. However, you should know from the start of your project how you plan to do this. As with unit-testing, it is best to have designed you evaluation in as much detail as possible before you start you practical work. That way, you know that what you are aiming for is something that can be evaluated in the manner in which you have planned. Remember, the purpose here is to determine whether your project has answered your original research question.

In general, your evaluation will fall into one of the following categories:

• Performance evaluation: either testing the speed, memory footprint, scalability, load-balancing, or other aspect of the performance of a program or system. This is often the easiest form of evaluation -- it can be performed by a program and so automated, the results can be analysed and presented using a statistics and you will not be reliant on users. Work in programming languages, networking, operating systems, databases, and hardware tend to suit this sort of evaluation well.
• User-acceptance testing and usability: if your project involves creating a product for end-users to test, especially if you have an industrial client, then it is essential that you perform some sort of user acceptance testing. Good options for this are the talk-aloud protocol or semi-structured interviews. NEVER, EVER, EVER think that a "heuristic" evaluation is sufficient. Heuristic methods only catch basic errors, they tell you nothing about how your users will actually experience your product.
• Formal or semi-formal methods: such as proving a theorem, using a model checker (such as SPIN), using a formal method such as B or Z to show that your work is free of particular types of errors.

 

Take (academic) advantage of your supervisor

Every student will have at least one supervisor, who will usually be actively involved in research, consultancy or something similar. This sort of work can provide a wealth of good ideas for projects and has several advantages. Firstly, your supervisor will propose projects that have the right scope and difficulty for your degree course. Secondly, if your supervisor has an interest in what you are doing, they will have a vested interest in seeing you succeed and of course will have a lot of relevant expertise with which they can advise you. Lastly, it is likely that your work will be used by other members of a research group which will give you access to feedback on what you have done.

 

Be flexible (within reason)

Remember that a project is a marathon, not a sprint. It may well be that you get part way along the journey and find out that what you had first set out to do is actually impossible, or impossible within the scope of the project. Or it may be that you find some other way of answering your research question, or you uncover some literature which shows that the question can actually be answered very simply. In this case, you should speak with your supervisor and find a way to reword or even completely change your original research question. This is quite a reasonable thing to do and happens often in "real" research projects, so you should not be worried about it. Your final project does not have to match the original proposal exactly, but you should be able to explain why the changes you made were necessary.

 

Summary

• DO choose a project that will hold your interest for the duration of the project.
• DO NOT choose a project that is the same size or scope as a coursework, or something that is very similar to work you have been set in a module.
• DO propose a "difficult" problem -- it is easier to pass a challenging project than an "easy" one!
• DO propose a research question, and an idea for solving it.
• DO propose a project with some sort of practical or mathematical component, DO NOT set out to write a commentary on a topic.
• DO have a very clear plan for how you will evaluate your project. This should clearly state how you will determine whether or not you have answered your research question.
• DO NOT evaluate an end-user product with only heuristic methods.
• DO test end-user products with real users.
• DO take advantage of the expertise of your project supervisor and their research interests.
• DO be flexible, if you find that your original research question cannot be answered, or if you find that a more "interesting" research question emerges during your project.

Posted via email from Pass your final year project

Introducing server processes

Much of the recent activity on the python-csp code base has to do with finding useful ways to debug networks of CSP processes. The dynamic analysis of CSP programs has a long history, dating back to Hoare's original work. I'll post more about that another time, but this post details a small change to the core library that enables debugging to run effectively. 

A common idiom in CSP-style code is to have many processes in a process network (connected via channels, or other guards) which all loop forever. If the program needs to be terminated, that is usually done via channel poisoning. I call these processes server processes, because they continually serve values to their output channels (if they have any).

In fact, all of the processes in the csp.builtins library are server processes, and python-csp has quite a few of these. It has most of the processes from the JCSP "plugNplay" package and a distinct process for every built-in unary or binary operator in Python. So, for example, the csp.builtins.Plus processes reads two pieces of data from its input channels, and sends their addition to an output channel. One possible implementation of csp.builtins.Plus would be this:

@process def Plus(inchan1, inchan2, outchan):     while True:         outchan.write(inchan1.read() + inchan2.read()

In reality, this isn't quite how csp.builtins.Plus is implemented, as there are quite a few unary and binary operators in Python, so we make use of metaprogramming to generate most of these builtin processes.

The problem with server processes is that if you want your debugger to deduce useful information about your program then at some point your code needs to terminate so that the debugger can compute a call graph, or some other structure, from which other useful information can be gathered. Ideally, it would also be nice if the debugger could deduce that your server processes are intending to run indefinitely, even though it actually terminates when the debugger executes them.

To achieve this effect, python-csp now has a special class for creating server processes called CSPServer, and a new decorator, called @forever. These work exactly like the usual CSPProcess and @process types that have been included in python-csp since its inception. Apart from using the new constructors, the only change you need to make in your code to use @forever or CSPServer is that a server process should be a generator and, usually, it should yield at the end of each iteration of its internal loop.

As an example, if we were to reimplement csp.builtins.Plus with the new constructors, we can do this in two ways, firstly with the decorator (which is the recommended method) and secondly using the CSPServer class directly. In the code below I am using two other processes from csp.builtins: Generate which sends an infinite supply of integers down its output channel and Printer which prints anything it reads from its input channel to STDOUT (by default, you can customise this to use any other file type). So now, Plus could be implemented thus:

@forever def Plus(inchan1, inchan2, outchan):     while True:         outchan.write(inchan1.read() + inchan2.read())         yield ... # Silly way to print even numbers in1, in2, out = Channel(), Channel(), Channel() Generate(in1) & Generate(in2) & Plus(in1, in2, out) & Printer(out)

If we decide not to use decorators, then the code is essentially the same, we just need to remember to construct any Plus processes with the CSPServer class:

@forever def Plus(inchan1, inchan2, outchan):     while True:         outchan.write(inchan1.read() + inchan2.read())         yield ... # Silly way to print even numbers in1, in2, out = Channel(), Channel(), Channel() Generate(in1) & Generate(in2) & CSPServer(Plus, in1, in2, out) & Printer(out)

Posted via web from python-csp

Setting up the Freeduino v1.16 and Nokia 3310 LCD shield on Ubuntu Karmic

This post contains some brief notes on setting up a Freeduino (or Arduino) and Nokia 3310 LCD shield on Ubuntu Karmic, this should probably work OK for other versions of Ubuntu and other versions of the Freeduino or Arduino.

Installing the Arduino SDK

Firstly, install the Arduino SDK. This requires adding a new repository to your list of software sources, installing the Arduino SDK and removing a conflicting package:

$ sudo add-apt-repository ppa:arduino-ubuntu-team/ppa $ sudo apt-get update $ sudo apt-get install arduino $ sudo apt-get remove brtlly

Now you should be able to find an entry for "Arduino" on your Application -> Programming menu (if you are using Gnome, it might be somewhere slightly different with KDE). That is a link to the Arduino SDK which is a modified version of the Proce55ing IDE if you have used that. It should look like the picture below when you start it.  

Installing the Nokia 3310 libraries

Next, you need libraries for the Nokia 3310 shield. You can download these directly from NuElectronics or get a slightly updated version from Andrew Lindsey: http://blog.thiseldo.co.uk/?p=383 Either way, download the .ZIP file and unpack it somewhere in your home directory. The next bit isn't well documented, but what you need to do is to copy the files from the library to the directories that are expected by the Arduino SDK. Firstly, copy everything over to the Arduino library path:

$ sudo cp -a nokia_3310_lcd /usr/share/arduino/libraries/

Now, if you restart the Arduino SDK and look up Sketch -> Import Library on the menu, you should see nokia_3310_lcd as an item on the list there.

Next, you need to put the example Arduino application where the IDE can find it:

$ sudo cd /usr/share/arduino/libraries/nokia_3310_lcd $ sudo mkdir /usr/share/doc/arduino/examples/Nokia $ sudo mv examples /usr/share/doc/arduino/examples/Nokia

Try everything out

Now, if you place the Nokia shield on top of your Arduino or Freeduino (it only fits one way), and attached the Arduino to your USB port you should be able to try out the example application. Restart the Arduino SDK, make sure you go to Tools -> Board and select the board you are using -- look on the long chip on the board to find out whether you have an ATmega328 or ATmega168 if you are not sure. Also, go to Tools -> Serial Port to select the port that has been assigned to the Arduino. If Serial Port is greyed out on the menu then unplug the Arduino from the USB port and put it back in again (to force the OS to reassign a new virtual USB device to the Arduino). 

Now, go to File -> Examples -> Nokia and open up the example "sketch" or program. Press the Verify button (that looks like a triangle) to compile the sketch. If you have placed the libraries in the right place you should get a message like this at the bottom of the GUI:

Binary sketch size: 3858 bytes (of a 30720 byte maximum)

Lastly, press the Upload button (the one with an arrow pointing right) to upload the compiled code to the board, and you should see something like the results in the photo below.

Posted via web from snim2's posterous

Fixing Eclipse on Ubuntu Karmic

Since upgrading to Karmic all my copies of Eclipse have been unusable. Text doesn't seem to appear, clicking on the GUI makes it crash, eugh. Sadly, I can't use emacs for quite everything, so here's a quick fix for Eclipse, just place this somewhere sensible in your ~/.bashrc file and you should be fine (unless you've found a different Eclispe bug, in which case you're on your own!):

1 2 3

# Fix Eclipse on Ubuntu Karmic export GDK_NATIVE_WINDOWS=1

 

Posted via web from snim2's posterous