New Curriculum @ Cal State Long Beach

Hi all,

I am running a new course in the fall out of the Art Department at CSU Long Beach called ART 364 Electronics, Mechanics, Kinetics. A not very specific title for an interdisciplinary studio art course that will explore basic electronics, mechanics, and microcontroller programming for studio art majors (lots of light, motion, reactivity, and simple behavior). Last fall I offered a test run of the class and based the curriculum off of Igoe's Physical Computing book and used the PICAXE ( line of microcontrollers. Without an available Windows-PC lab (it IS an art dept) the students were stuck with the 1 or 2 machines I could provide them because of the PICAXE's windows only programming editor.

I do however have a nice Mac lab available (used for a couple video classes) and have been seeing the Arduino pop up everywhere so it seemed like a natural decision to switch my curriculum over to the Arduino platform (and use the Mac lab). The one thing I am going to sorely miss is the PICAXE free 220 page manual which makes learning the code structure and commands very easy for the beginner. (And it makes my job admittedly easier.)

Ok, now I know about the arduino guide that just came out which is a good primer. I have also seen the reference section here and Igoe has some great labs written up over at the NYU Phys Comp site. I have a feeling switching to the Arduino platform is going to require some writing on my part and thats ok. Before I get started putting this stuff together though, I wanted to ask this forum for help pointing to good reference material that might be floating about that I havent seen yet. I would also greatly appreciate any comments, suggestions, or wisdom any of the members might be able to provide as I start up this new Arduino based curriculum.

Many thanks, Brian Evans, CSULB

Hej Brian,

it is interesting you are talking about writing your own curriculum for a class. We have been teaching at K3 (School of Arts and Communication - Malmo - Sweden) since the beginning. We are having an oral tradition to transfer knowledge from teachers to students, and I feel that it is time to put all of these into a document. However I don't feel I have the time to make it on my own. Are you interested in working together?

If so, I will suggest we create a page in the playground (our open wiki) and start adding an index. This would allow other interested teachers joining this project.

Shall we go for it?



Im up for it. I think one thing that would be nice for a class reference are specific tutorials (Tom Igoe has labs up at ITP) on basic things that build on one another and interrelate. For example, how to read an LDR with schematics and pictures. Then add a servo and tie the sensor values into servo position again with schematics and pictures. And on and on, always building in complexity. Now a lot of this info seems to exist right now but in lots of different places by a lot of different people. Im afraid thats a little too confusing for the absolute beginner. (Now of course what I have my students put together as opposed to any of the other classes will always be different.)

What else do you have in mind?

Thanks, Brian


yes, this is the kind of thing I was talking about. We all need the proper courseware where the examples are placed in the right order.

Shall we get started then?



OK, Ive been reading through the tutorials, many it would appear written by you, and they’re really pretty good. Massimo has gotten started on covering the general program structure in the booklet. So, I guess what Im looking for is a way to combine (and organize) these all into a concise collection of information for my students (and of course myself!).

Im not exactly sure how I can help. With that said, yes by all means lets do something. How do you suggest we proceed? What can I do? I am more than happy to contribute in any way I can.

Let me know,
bwevans AT


this is the way (in my humble opinion):

0) we announce on the site we launch a project to create a "generic workshop document" 1) we open a page in the playground's wiki dedicated to coursware 2) we suggest an order in which the examples could be placed 3) we link the right texts/examples and analyze what is missing/needs to be corrected 4) we propose this to the community as a "typical course" for the type of students you work with 5) we evaluate the response from people 6) we package it into a PDF and post it into the tutorial's site (official site) for people to download

If you agree with this, we start working with it tomorrow, as soon as I have got some sleep :-)

(In the way I bet that we will get a lot of interesting people to help out)


PS. and, if we can convince someone to put some money for printing, we could print this as a GPL book

Absolutely! This sounds great. I agree completely. I was concerned that it would sound like I wanted to redo some of what has already been done (and done well) but what you propose just helps organize what is out there and unifies it in a single format. I will do everything I can to help.


Does it make sense to build on the Arduino booklet? It already attempts to provide a philosophy and introductory sequence for workshops, etc.

In my opinion we have to choices:

1) to make a continuation to Massimo's work 2) to make a completely new thing that refers to it from a more academic perspective

Dave: what do you think? Massimo: what would you prefer? Community: proposals?


Ok, let's get started with this at:

and if there are things to be discussed we use the forum, deal?


Ok I threw out some topics and links to the closest thing that already exists. (Wiki newbie here so not sure what Im doing.) Some of the examples, IMO are way too complex and should be paired down some. The material could be chunked into smaller units so that it better builds on itself. Ill go back and start trying to add notes and question some of these things.

There should also be a more in depth primer to the structure of the language. Massimo has some of that going in his booklet but it would be nice to have that flushed out more (pg 21, 22, 23). Something for the absolute beginner to latch on to.

The other big thing, except for Igoe's examples, is the lack of schematics. Schematics are so important it makes sense to me to see them from the beginning. At some point I will edit a (or make a new) tutorial as a suggestion for a format and see what everyone thinks. Basically a text intro, maybe parts needed, schematic, photo, and code.

Is Massimo out there? I wonder how much of this he has been already working on with the booklet project?


Also, you should probably use the new examples I'm writing to replace the current ones (and to synchronize the ones on the site with the ones that come with the software): If you have any suggestions for those examples, let me know soon - Arduino 0008 should be coming out in the near future.


I started separating the possible subchapters into different pages, also added an introduction, and I think we should have something about electricity, and the history of electronics for those more brave as an appendix.

About the schematics, I will see if I can find the basic file we use to make schematics (it is an illustrator file of a USB board ... maybe Dave has it ... I only have one for the serial board, which is the one we use at the site.

I will also work a little with more texts about the examples. Each one of us has created a whole discourse about how to introduce the different exercises, and I think it will be nice if we put some effort in trying to figure out a common discourse understandable from a written document.


Added a looong explanation about analog signals, ADC conversion, etc ...could someone read it through and proof read it? Remember I am not native in English ::)


Added colour coded information about the level of development of every subchapter, so far indicating the amount of text produced



Thats a lot of info there on analog! (Maybe too much?) Ill have a look through the next day or two. Ive always told my students that digital is just on or off, high or low, +5v or 0v and that analog is everything in between. That is of course too simplistic.

My contribution today was to start on the schematics. Ive never liked the look of EagleCAD-esque schematics so I whipped out Illustrator and drew my own. I linked them to each bulleted list starting with "Schematic:". They are a little high res, 300dpi at 3"x3" but I have in mind a print version. I will continue with the schematics for now and then edit a course workshop next.


Hey guys, I split out serial communication into its own section, since it didn't really seem to fit with all the miscellaneous sensors and because I think it's important enough to have its own section.

What do you think about renaming the "Advanced" section to something like "input devices" (or "sensors") and then creating another section called "output devices" (or "actuators") that includes the various types of motors, driving a relay, etc.?

Dave: sounds good, I like the idea, can you then split the chapters?

Brian: if you make your basic files available, then we can all help out making more illustrations

I will work more tonight, now I have some moving to do


Added a handful more schematics and found an extra couple of examples thanks to Tom Igoe's archives.

First I think Analog Output should be rolled into a combined Analog Input/Output as was done for the Digital side. Although it seems like there is a possible redundancy in having the "Sensors" and "Actuators" broken out. A lot of these either send or receive an analog or digital signal and use similar code to one another. Big exception with the SRF04 (although the new matchbotix sonar outputs an analog signal). Maybe it should be Basic Digital IO (switch & LED) and Basic Analog IO (pot, variable resistor, PWM LED) and everything else filed under Sensors or Actuators? Either that or for Sensor & Actuators to somehow get rolled into both Digital & Analog IO?

I really dont know. Thoughts, opinions?


I think it makes sense to separate digital/analog from sensors/actuators. The former is more of an introduction to the concept of analog and digital signals and to the basic Arduino functions for interacting with them. The latter talks more specifically about particular sensors and actuators, what they do, and how to control and use them. That is, in the digital/analog sections, you might talk about the pulseIn function, but in the sensors/actuators sections you would talk about an accelerometer (that you might read with pulseIn), what acceleration means, etc.

I also think it makes sense to split the analog input from the analog output, as they're really different things: real analog signals vs. PWM.