copyleft hardware planet

Here’s a second simple plug which works:

(the silkscreen markings are incorrect, this plug responds to I2C addresses 0×29, 0×39, or 0×49)

The Lux Plug measures incident light intensity which can be converted to a 16-bit Lux value in the range 1 .. 65535. A 16x multiplier can be used to increase the dynamic range to 20 bits.

A class named – surprise! – “LuxPlug” has been added to the Ports library, as well as a “lux_demo” sketch:

Sample output:

The two first values are the raw readings from two internal sensors. The TAOS datasheet explains how to derive the Lux value from them. This calculation is included as the “calcLux” member in the class (to be called after getData() has obtained a reading).

Onwards!

After the meetup tonight, we’ll be having beers in the East Village Ryan’s Irish Pub at 151 Second Avenue between 9th and 10th.  We’ll be there from about 8 PM. So if you didn’t RSVP for the meetup before it filled up, come out and join us for a pint this evening at Ryan’s.

Looks like the Dimmer Plug is working as intended – yippie!

I connected a LED with series resistor between the L1 output and PWR (i.e. 5V in this case).

Added a new “DimmerPlug” support class in the Ports library, and a “dimmer_demo” example sketch:

The result is a LED which blinks briefly 4 times per second, with increasing intensity. When the maximum intensity has been reached, it restarts from off. Note that the blinking and brightness control is done by the plug – the sketch just keeps feeding it new settings.

There are 16 independent channels, the outputs can be either open-collector or totem-pole, and by adding a MOSFET, transistor, or darlington stage, much larger currents and voltages can be controlled by this plug.

Another fun application would be to connect up to 5 RGB LEDs, for full 24-bit color control of each one of them.

The above code has been added to the Ports library.

Just got a couple of new boards back (this was an experiment, expediting some of the boards to get them several days ahead of the rest of this prototype batch).

Meet the new JeeNode USB v3 (this unit was soldered by hand – phew!):

As you may know, the main reason for this revision was to resolve a problem with the voltage regulator, but since I had to rework the design anyway I also added a LiPo charge circuit.

The good news is that everything seems to work fine so far. There are some cosmetic problems with this board, but no show stoppers.

And of course the big deal is being able to hook up a Lithium Polymer (LiPo) battery:

There is an extra LED in the corner, left of the USB jack, which will be orange (once I get them in). It lights up while charging. The charge current is max 280 mA, so this board won’t draw more than that from USB.

Without LiPo connected, the current still goes through the charge circuit, so another major change is that the PWR pin on all the headers of this board never carries more than 4.2V – don’t use the JeeNode USB if you need 5V in your circuit (use a JeeNode + USB-BUB if you really need the 5V).

Two BIG honking warnings, since LiPo batteries can be quite dangerous: one is that they need to be charged with the proper circuitry, such as on this new board, so don’t hook ‘em up any other way. The other issue to keep in mind at all times, is that LiPo’s can discharge at a very high rate! That “20C” label above means that this particular little battery is rated to sustain a discharge @ 20 x 450 mA = 9 amps!

You can probably cause a fire with those wires shown above, by simply shorting out a fully charged battery!

And you will probably fry the circuit and vaporize PCB traces by connecting the battery in reverse!

I’m exploring some options to reduce these risks. Hard-wiring the LiPo would be one way to reduce the chance of loose wires shorting out something. Perhaps a small custom PCB glued to the battery, with a fuse or polyfuse and a switch, wrapped in heat-shrink tubing? The trouble is that battery sizes and capacities vary greatly.

Some first tests w.r.t. power consumption: it looks like the JeeNode USB v3 will draw about 120 µA when in sleep mode. With the above 450 mAh battery, it would last up to 5 months without recharging (and without doing anything useful, such as turning on the radio module once in a while). There’s probably still some room for improvement here, but for now it’ll have to do.

FWIW, I’m going to hand-assemble a few of these boards in the coming weeks, but unfortunately that means there won’t be many v3 units available in the shop, initially. I’m also having solder paste stencils made up right now. Once these are in, the new boards will be much easier to assemble – using the reflow grill that gets a lot of work done here at Jee Labs.

Today we are working at ITP, New York University, Shigeru Kobayashi from IAMAS, presented his Arduino FIO board that he developed together with Sparkfun.

Sneak preview of the Arduino FIO at the Uno Punto Zero meeting

UPDATE (20100319): If you are interested in checking this board out right now, you can get it directly from here.

Meet the new kid kit in the Jee family – the JeeSMD !

At a glance:

• Same pinout as a JeeNode – same 4 port headers, same PWR/SER/I2C, same SPI/ISP
• No wireless, no FTDI, just an ATmega328 – all SMD (32-TQFP, SOT-23, and 0603)
• Two extra pins on the right side (allocated to the RFM12B module on JeeNodes)
• Has a 3.3V regulator, a 16 MHz resonator, and four passive components

What’s the point? Well, it’s going to be made available as an SMD kit, and it’s going to be low-cost. If you don’t care about wireless or FTDI, then this is a convenient and compact way to hook up some Jee Labs plugs.

Of course, all the other stuff fits as before, including the Proto Board, for example:

Here’s the board in more detail:

(don’t look too closely at this prototype PCB – there are some silly cosmetic mistakes…)

There are some trade-offs w.r.t. JeeNodes:

• No FTDI on board – you have to either add the equivalent connections yourself via the left and right headers plus a 0.1µF cap, or use ISP for flashing the ATmega328 chip
• No wireless, so this isn’t a “node” in the usual sense – just a tiny Arduino’ish board
• It’s all SMD, so if you want to practice soldering SMD by hand – this is one way to get started!

I’ve got a few boards for people who want to get their hands on them. The kits will be ready in about a week.

Now the JeeSMD kit needs a detailed set of instructions and close-up shots on how to assemble and start using it – more work to do!

We’ve had an enthusiastic response to the NYC meetup this Saturday, and we’re filled up.  We’ve got an RSVP list that matches the capacity of the space. Thanks to all who RSVP’ed, we look forward to seeing you Saturday. For those who didn’t RSVP in time, watch this space, and we’ll pick a bar for drinks that night and announce it soon.

read more

The Bifferboard described yesterday is a bundle of fun (well, for geeks like me anyway…).

But this weblog is about physical computing, not just embedded hardware or software.

So let’s hook up a JeeLink!

The first hurdle is a silly one: my Bifferboard only has a single USB slot, and it needs the USB stick to run off. So for this experiment I added an unpowered USB hub:

Did I mention that this is a standard Debian setup? Here’s the kernel log with the JeeLink plugged in:

Note how it recognizes the FTDI serial link without having to install or configure anything. Perfect!

The other factoid which can be gleaned from this info is that it took about 36 seconds from the start of the kernel boot to this stage. From this, I’d estimate a Bifferboard with JeeMon to boot up in well under 60 seconds.

To verify that the USB recognition is really complete, I used this little test in “try/application.tcl”:

And sure enough, it recognizes and identifies the USB device:

Let’s try one more thing – by changing try/application.tcl to this code:

Sample output:

That’s a Bifferboard receiving JeeNode packets via a JeeLink – yippie!

I can now go back to developing JeeMon further on my desktop machine, in the knowledge that software updates are one little restart away (due to JeeMon’s built-in self-updating over internet) and that apps will probably work as is on a Bifferboard. Long live platform independence!

El pasado dia 13 se celebro el curso de arduino en el Casal Juvenil "La Gresca" de Cerdanyola organizado conjuntamente por Tuxbrain y el Null Lab.
El indice de la tematica del curso fue la siguiente:

• El Hardware:

read more

• In my personal life, i moved my house from Spain to Brazil (really big change). One of the best consequence of this movement is the people i met at my new job, really nice people with a nice job.
• In the job side i´ m working in a open-minded company for the hardwar/embedded path. That gets me happier.
  

The Bifferboard is an interesting computer which was mentioned on the forum a while back:

It has an ethernet jack, and all it needs is 5V power and a USB stick with Linux on it. You can get an impression of its diminutive size with the JeeLink next to it.

So let’s try it out!

The Bifferboard will work with several different Linux distributions. I decided to use Debian because it’s stable, easy to manage, and has lots of packages ready to install. And because I’m very familiar with it.

Setting up Linux is fairly easy, using these instructions. The hardest part has been done and is fully automated with two scripts: formatting and creating a USB stick to contain a complete Debian 5 (lenny) system. This needs to be done from Linux on your desktop machine, I used Ubuntu.

The only tricky part is that a matching kernel needs to be flashed onto the Bifferboard itself. My older unit has 1 Mb flash, newer units have 8 Mb flash. There are two ways to flash the unit: via a special serial console cable and via a direct ethernet cross-over connection. I tried the ethernet thing, but couldn’t get it to work, and since I had already hooked up a serial line for debugging, I ended up using that method.

The serial port is available as 3.3V I/O signals, but it requires soldering an extra header to the Bifferboard:

(only 3 lines are needed: RX / TX / GND, but I’m swimming in 6-pin connectors around here…)

Those pins are then tied to a USB-BUB, which in turn is hooked up to my Linux setup. The connection is 115200 baud, and shows the kernel boot log on startup.

Once the reflashing is done and the USB stick has been inserted, you end up with a standard Debian setup, which can be accessed over the network via SSH:

If there is interest, I can set up a wiki page with more details about all this.

Now the fun part: the Bifferboard is x86 compatible, so it will run the standard JeeMon build for 32-bit Linux!

There’s about 25 Mb of usable RAM (no swap space), which should be plenty to run just about anything in JeeMon with some other processes alongside it.

The one thing to keep in mind, is that this is a low-power board. It’s equivalent to a 486SX, i.e no hardware FPU, and it looks like it runs about 100 times slower than my (modern) Mac. But hey, you do get something in return: an very small unit and a power consumption of only 1.5 .. 2.5 watt!

The program of talks and BOFs of the 2010 edition of the Embedded Linux Conference has been published a few days ago, an opportunity to look at the most important and interesting conference for embedded Linux developers. For the record, ELC 2010 will take place from April, 12th to April, 14th in San Francisco, CA, USA, in the same place as the 2009 edition.

A nice set of talks

• A set of real-time related talks: Real-Time Linux Failure, by Frank Rowand (works for Sony, well known for his preempt-rt related talks at various ELC conferences), Effective Use of RT-Preempt, by Kevin Dankwardt, Using Interrupt Threads to Prioritize Interrupts, by Mike Anderson (also well known for his very interactive talks, he will also be giving his traditional Using JTAG to debug Linux device drivers tutorial), Measuring Responsiveness of Linux Kernel on Embedded System, by YungJoon Jung and DongHyouk Lim.
• A talk by Grant Likely about Flattened Device Tree ARM support update, an effort to convert the ARM architecture to the same organization used in PowerPC, with a device tree file describing the hardware details instead of platform_device definitions in plain C. An important change for anyone doing ARM kernel development.
• Several power-management related talks: Runtime Power Management: Overview and Platform Implementation, by Kevin Hillman (who works for Deep Root Systems and has done a huge amount of work in the OMAP power management area). Runtime Power Management is probably the most important change done recently to the power management infrastructure of the Linux kernel, so this talk is certainly worth a look, all the more as Kevin is a very good speaker. On power manegement, there will also be other talks : DVFS for the Embedded Linux, by Yong Bon Koo and Youngbin Seo, Wake-ups effect on idle power for Intel’s Moorestown MID and smartphone platform, by German Monroy (Intel), Workload based aggressive Power Management on the Intel Moorestown MID and future Intel MID/Smartphone Platforms, by Sujith Thomas (from Intel).
• The usual tracing-related talks, with Using the LTTng tracer for system-wide performance analysis and debugging by Mathieu Desnoyers and Ftrace – embedded edition, by Steven Rostedt. A talk on debugging Linux toolchain overview with advanced debugging and tracing features, by Dominique Toupin.
• Talks about platforms: a keynote by Greg Kroah Hartmann on Android: a case study of an embedded Linux project (during which Greg will probably explain why the Android kernel modifications are not mainlined), Experiences in Android Porting, Lessons learned, tips and tricks, by Mark Gross and Understanding and Developing Applications for the Maemo Platform, by Leandro Melo de Sales, even though the recent merge of Maemo and Moblin to create MeeGo is likely to change some technical aspects of application development for this platform.
• The question of multi-core now also seems to be present in embedded conferences: Strategies for Migrating Uniprocessor Code to Multi-Core, by Mike Anderson, Embedded Multi-core with Adeos, Dan Malek, Lock-free algorithm for Multi-core architecture, Hiromasa Kanda. Multi-core Scheduling optimizations for soft real-time multi-threaded applications – A cooperation aware approach, Lucas Martins De Marchi.
• Some security talks, with Mike Anderson (again !) talking about Creating a Secure Router Using SELinux and Jake Edge about Understanding threat models for embedded devices
• Some more-or-less multimedia-oriented talks: Supporting SoC video subsystems in video4linux, by Hans Verkuil, An Introduction to the Qt Development Framework, by Jeremy Katz, GeeXboX Enna: embedded Media Center, by Benjamin Zores, Case Study – Embedded Linux in a digital television STB, by Melanie Rhianna Lewis
• In the other talks, I’ve noted the Small Business Owners BOF by Grant Likely, Evaluation of Data Reliability on Linux File Systems by Yoshitake Kobayashi, Porting the Linux Kernel to x86 MID platforms, by Jacob Pan, Linux without a bootloader? by Greg Ungerer, Kexec – Ready for Embedded Linux by Magnus Damn, Custom hardware modeling for FPGAs and Embedded Linux Platforms with QEMU, by John Williams, Edgar Iglesias.

A talk from Free Electrons

Gilles Chanteperdrix, who works for Free Electrons since January, will give a talk about FSCE: Reducing context switching time on ARM. FCSE is an extension of ARMv5 CPUs which allows to significantly reduce the cost of context switches by avoiding costly cache invalidations. Gilles, together with other developers, has created a patch which was proven to provide considerable latency improvements in Xenomai, one of the hard real-time extensions for the Linux kernel. Here is the full abstract of Gilles talk :

The ARM v5 CPUs are inexpensive, low power, 32-bit processors widely used in embedded systems. Because of these processors’ cache implementation, using memory protection on these systems incurs a large performance penalty both to the latency of real-time applications and to the general performance of non real-time applications.

By implementing the Fast Context Switch Extension (FCSE), we achieved both memory protection and good cache performance under the Linux 2.6 kernel. We briefly discuss the problem, explain the necessary changes to the Linux memory management system, and present performance measurements on multiple CPU families, for real-time and non real-time benchmarks.

The corresponding kernel patches are public and have already been submitted to the Linux Kernel Mailing List.

The three people of Free Electrons, Michael Opdenacker, Gilles Chanteperdrix and myself (Thomas Petazzoni) will all be there at ELC. We hope to meet you during this conference!

Just in case you are wondering why there are no updates here: I'm currently on holidays in Taiwan and thus not working much on my various projects, i.e. no major updates on this blog until some early/mid April.

Until now, the Ports library supported software I2C on the 4 “ports”, whereas hardware I2C required the Arduino’s Wire library. The unfortunate bit is that the API for these two libraries is slightly different (the Ports library uses a slightly more OO design).

See the difference in resulting code with and without Plug shield, for example.

Triggered by an idea on the forum, I decided to extend the Ports library, so that “port 0″ gets redirected to Analog 4 (PC4) and Analog 5 (PC5), i.e. the hardware SDA/SCL pins on an ATmega.

So now you can use the Plug Shield with the same code based on the PortI2C class as with JeeNodes. Simply specify port zero when using this with an Arduino and a Plug Shield!

Here’s the Arduino example again, which no longer requires the Wire library:

Note the use of port 0 to connect to hardware I2C pins.

The benefit is that all plugs for which code exists based on the Ports library (Pressure, UART, LCD, etc) can now be used on an Arduino with a Plug Shield.

A nice extra is that this will also work on an Arduino Mega, without requiring two extra patch cables to hook up to the hardware I2C pins.

Long live simplicity!

Yesterday’s enclosure has started a new ball rolling…

I’ve decided to support a mix of plugs with room for prototyping. A first mockup:

This will be made possible by a new Carrier Board with tons of different ways to connect to:

Ports 1 and 4 each have four positions for adding plugs. All connected in parallel, so you can hook up more than one if you’re using a bus such as I2C on that port. Note the big dots, identifying the PWR pins for orientation.

Ports 2 and 3 can be plugged in, but their pins are also brought out to a series of 6-pin headers in the bottom right. These 18 pins bring out everything else, including full SPI, hardware I2C, and the serial I/O lines.

Lastly, the SPI/ISP and the PWR/SER/I2C connectors from the JeeNode have been duplicated.

Note that you can also ignore all that plug stuff and just insert your own board into the entire bottom row, using five 6-pin headers. That gives you access to all the pins on a JeeNode. Here’s a board I’m going to try out:

There’s a split down that board, to allowing breaking off and using either side independently. The left side is essentially a dual JeePlug and will fit in all the 2-port positions on the Carrier Board.

These boards will be included in the next round of PCBs. We’re back to the “Patience, grasshopper!” part…

La Suite Logique hackerspace invites hackers from all around the world to participate to the first edition of Les Contorsions Technologiques that will run from April 30 to May 2 at la Suite, alternative cultural space in the middle of Paris, France.

What are Les Contorsions Technologiques ? It's a mix of workshops, exhibitions, demonstrations and performance, in a setting favorable to discovery, experimentation and exchange. It's an invitation to grab the tools and take the initiative back, to shatter norms and reshape our universe. It's the celebration of all the creative, funny or spectacular uses of technology, and knowledge sharing.

Help us to spread the word by diffusing this Call for Proposals!

--[ Call for Proposals ]----

Les Contorsions Technologiques revolve around three big ideas:
- exhibiting tangible technology applications, as they are easier to feel;
- guiding people on their meeting with technology;
- inspire people into following our footsteps and play with technology.

We decided to not have lectures, and to ignore computer-only subjects. But do
not worry, there is still a wealth of topics. If you are unsure about this,
here is a list of possible topics:

* Electronics Basics
- all arduino things
- blinky boards
- squeaky circuits
- robotic runts
- radio transmissions

* Day to day
- TV-B-gone and friends
- RFID jewelry
- RFID killers
- makerbots and RepRap
- DIY domestic appliances
- DIY biotechs
- DIY clothing

* Art and games
- brainmachine
- demomaking
- 8-bit music
- puredata and supercollider
- object tracking
- physical peripherals
- circuit bending

* Urban hacking
- LED throwies
- laser tag
- building fronts as giants screen, one pixel per window

* Science
- Tesla coils
- quadrocopters
- autonomous drones

And, of course, everything we might have forgotten ...

Finally, we have the pleasure to offer you a quite uncommun exhibition medium,
the front of a 7 story building. Be megalomaniac, we have the resources for!
(more information on this very soon)

--[ Submissions ]----

Send your submissions at cfp@contorsions-technologiques.org before April 3,
23:59 GMT. Acceptance notifications will be sent around April 8 and the
schedule will be published around April 15.

Your submissions shall be a Plain Text, PDF, OpenDocument or RTF file, and
shall contain the following informations:
- type
- summary (1000 characters max)
- lang (fr/en)
- logistics need (tables, chairs, power, light, sound)
- contact information (at least an e-mail address)
- if applicable, a link to pictures or videos

Here are the submission types we accept:
- workshop: one or two people help to realize a small project (30 to 90 min of
work, no big hardware. Soldering iron is OK, drill press is not)
- exhibition: present your realizations and do interactive demonstrations
- demo/performance: be the star during 10 to 30 minutes. e.g.: tesla coil,
quadrocopter flight
- concert: between 30mn and 2h

Don't forget: everything is possible, as long as you drop us some lines to talk
about it.

--[ Practical Informations ]----

Les Contorsions Technologiques are organised without budget by volunteers on
their free time. Therefore, we cannot help with travels or accomodation
expenses, but we might be able to organise makeshift accomodation for
participants. Please contact us for more details.

Check out our web site for the last updates and other stuff:

http://www.contorsions-technologiques.org/

This call for proposals is available here :

http://www.contorsions-technologiques.org/cfp.html

Subscribe to the annonces mailing-list to be warned of the last updates:

http://www.contorsions-technologiques.org/cgi-bin/mailman/listinfo/annonces

Meet us on IRC :
irc://chat.freenode.net/#lasuitelogique

Send us an e-mail:
contact@contorsions-technologiques.org

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

La Suite Logique invite les bidouilleurs du monde entier à participer à la
première édition des Contorsions technologiques qui se déroulera du 30 avril au
2 mai à la Suite, lieu culturel alternatif situé au coeur de Paris, France.

Les Contorsions Technologiques, c'est un mélange d'ateliers, d'expositions, de
démonstrations et de performances, dans une atmosphère propice à la découverte,
l'expérimentation et l'échange. C'est une invitation à prendre les outils et
reprendre l'initiative, à briser les normes et remodeler notre univers. C'est
la célébration de toutes les utilisations créatives, amusantes et
spectaculaires de la technologie, et du partage de la connaissance.

Aidez-nous à répandre la nouvelle en faisant tourner cet Appel à Proposition !

--[ Appel à Propositions ]----

Voici les trois axes qui gouvernent les Contorsions Technologiques :
- matérialiser la technologie pour mieux la faire ressentir ;
- guider le public dans sa rencontre avec la technologie ;
- donner au public l'envie de se lancer sur nos traces et de jouer avec la
technologie.

Nous avons volontairement décidé de ne pas faire de conférences, et d'ignorer
les sujets purement informatiques. Mais n'ayez crainte, il reste amplement de
quoi faire. Si vous en doutez, voici une liste de sujets possibles :

* Électronique basique
- arduino et compagnie
- loupiottes qui clignotent
- circuits qui couinent
- robots riquiqui
- transmissions radio

* Quotidien
- TV B gone et consors
- joaillerie RFID
- tueurs de RFID
- makerbots et ReprRp
- électroménager DIY
- biotechnologies DIY
- vêtements DIY

* Art and jeux
- brainmachine
- demomaking
- 8-bit music
- puredata et supercollider
- object tracking
- périphériques physiques
- circuit bending

* Espace urbain
- LED throwies
- laser tag
- écrans géants en facade, un pixel par fenêtre

* Science
- bobines de Tesla
- quadrocopters
- drones autonomes

et bien sûr, tout ce que nous aurions pu oublier...

Enfin, nous avons le plaisir de vous offrir un terrain d'exposition peu commun,
la facade d'un immeuble de sept étages. Voyez grand, nous en avons les moyens
(plus d'informations très prochainement).

--[ Modalités de soumission ]----

Envoyez vos soumissions à cfp@contorsions-technologiques.org avant le 3 avril,
23h59 GMT. Les notifications d'acceptation seront envoyées vers le 8 avril et
le programme final sera publié autour du 15 avril.

Vos soumissions doivent être dans un des formats Plain Text, PDF, OpenDocument
ou RTF, et doivent contenir les informations suivantes :
- type
- résumé (1000 caracteres max)
- langue (fr/en)
- besoins logistiques (tables, chaises, électricité, lumière, son)
- informations de contact (au moins e-mail)
- éventuellement, un lien vers des photos/vidéos.

Voici les types de soumission acceptés :
- ateliers : un ou deux instructeurs aident le public à réaliser un petit
montage qui prend de 30 à 90 minutes, ne demandant pas de matériel lourd (fer
à souder : OK ; perceuse a colonne : KO)
- exposition/installation : présentez vos réalisations au public et faites de
petites démonstrations interactives
- démonstration/performance : soyez le centre de l'attention pendant 10 à 30
minutes. e.g.: tesla coil, quadrocopters
- concert : entre 30mn et 3h de concert

N'oubliez pas : tout est possible, il suffit de nous laisser un e-mail pour en parler.

--[ Infos pratiques ]----

Les Contorsions Technologiques sont organisées sans budget par des bénévoles sur
leur temps libre. Par conséquent, nous ne pouvons aider à financer les déplacements
ou l'hébergement, mais nous pouvons tâcher d'organiser un hébergement de fortune
pour les exposants. Contactez-nous pour plus de détails.

Surveillez notre Site Web pour les mises à jour et autres nouveautés :

http://www.contorsions-technologiques.org/

Cet appel à proposition est disponible ici :

http://www.contorsions-technologiques.org/cfp.html

Inscrivez vous à la liste de diffusion annonces pour être averti des dernières
nouvelles :

http://www.contorsions-technologiques.org/cgi-bin/mailman/listinfo/annonces

Retrouvez nous sur IRC :
irc://chat.freenode.net/#lasuitelogique

Envoyez nous un e-mail :
contact@contorsions-technologiques.org

Nedit has a very cool feature and I’ve even seen people using gvim have something similar. However emacs for some reason doesn’t. Is it because they don’t have users of their same field of application? Well who knows.

The feature in question that with Ctrl-y on Nedit one can open a file whose filename and path are listed in a text file just by placing the cursor on that
filename. e.g

#----------------------
#!/usr/bin/tclsh
source $(SCRIPTS_HOME)/definitions.tcl
....
#----------------------

After several nights roaming online for a possible solution with emacs, I ended thinking that there is no generic for this. Hence I ended up writing the following lisp code myself with my 4-hours experience with lisp.

The objective is there is an environmental variable for each projects’ path and that each has specific technology files (LEF,Liberty(ccs,ecsm,…) for pads, sram, rom, analog modules, …… One should be able to open the $(SCRIPTS_HOME)/definitions.tcl (with a shortcut i.e Ctrl-Y) within emacs itself , instead of ctrl-x-f ?

;;
;; Nedit file open with control-y
;;
(defun cgo-open-this-file (arg)
  "Copy lines (as many as prefix argument) in the kill ring"
  (interactive "p")

  ;; select whole word
  (let (b1 b2)
    (skip-chars-backward "^<>“[\"‘")
    (setq b1 (point))
    (skip-chars-forward "^<>”]\"’")
    (setq b2 (point))
    (set-mark b1))

  ;; grab selected word and start processing it
  (setq filename
        (if (and transient-mark-mode mark-active)
            (buffer-substring-no-properties (region-beginning) (region-end))
          (thing-at-point 'symbol)))

  ;; identify a environmentalvariable
  (setq envvar (replace-regexp-in-string ".*$(" "" filename))
  (setq envvar (replace-regexp-in-string ").*" "" envvar))
  (setq envvar (getenv envvar))
  (message "envvar %s" envvar)

  ;; replacing the environmental variable
  (setq envvar_replacement (replace-regexp-in-string "\$(.*)" envvar filename))
  (message "file %s" envvar_replacement)
  (find-file envvar_replacement)
)

;; optional key binding
(global-set-key "\C-y" 'cgo-open-this-file)

This code can be improved to support multiple env variables or any thing you would like, However it works and suits my application. Feel free to post a better solution

Ekstra Bladet is a Danish paper that has a quite large online version. This week they have a small online TV documentary about Arduino’s presence at the OSD conference in Copenhagen last week. We cannot embed their video in our site (they give no chance to do so) but visit this link to see it. If you watch the clip you will notice there is a Pong game made with a series of RGB LED matrixes by the guys at BSD-DK, as well as a whole display of different projects that can be made with Arduino … that was a nice job! For the next Open Source Days, please remember I live just across the Oresund, and send me an invitation, thanks

Arduino clip on Ekstra Bladet March 2010

AARL's Quiz for March 2010

The AARL is the US National Association for Amateur Radio with over 150.000 members. This month they published a Quiz on their website that included a question about the term “Arduino”. We have been getting some visits to our website from them during the last days. If you are into electronics in general and radio in particular, you should maybe take a look at their website. Here some facts:

By 1914, there were thousands of Amateur Radio operators–hams–in the United States. Hiram Percy Maxim, a leading Hartford, Connecticut, inventor and industrialist saw the need for an organization to band together this fledgling group of radio experimenters. In May 1914 he founded the American Radio Relay League (ARRL) to meet that need.

Today ARRL, with approximately 157,000 members, is the largest organization of radio amateurs in the United States. The ARRL is a not-for-profit organization that:

• promotes interest in Amateur Radio communications and experimentation

   

• represents US radio amateurs in legislative matters, and

   

• maintains fraternalism and a high standard of conduct among Amateur Radio operators.

At ARRL headquarters in the Hartford suburb of Newington, a staff of 120 helps serve the needs of members. ARRL is also International Secretariat for the International Amateur Radio Union, which is made up of similar societies in 150 countries around the world.

At last! – Here’s a fantastic enclosure for the JeeNode:

The plugs are just one possible orientation, they will also fit sideways, i.e. stacked on their side like the JeeNode in there. No screws, no glue – this just needs a PCB of the right size – or as in this case: perf-board with some male headers to connect to the JeeNode ports.

The whole box clicks together with the other side, which has exactly the same shape:

Available in light gray and in black from Dick Best in the Netherlands.

I’ll look into adding this enclosure option to the shop.

CC 就是Creative Common 。本 NanoNote 的硬件原理图是以CC-BY-SA协议发布。这个SAKC就是一个最好 CC 应用的例子

先贴图片（我总是喜欢图片）

请大家注意看右下角：

QI-HARDWARE

http://nandnote.cc

SAKC_BOARD RC1 CC-BY-SA 3.0 

SAKC 是在Ben NanoNote电路图的基破上设计开发的。这样就省去了很大一部分的设计时间。很快的将产品设计出来。并且 Carlos 用了48 个小时就把所有的组件都焊接到PCB上。而且Ben NanoNote的软件也很容易的就运行在 SAKC 上。只是要对一些特殊功能写一些驱动。

可以想像如果有相当一部分硬件的电路图是以 CC 形式开发的。硬件设计开发成本将大大缩小。也会节省相当一部分硬件设计的投入。

很欺待更多的 NanoNote 的衍生品。别忘了在你的硬件设计图上加上 “ CC-BY-SA “

Didn't we all dream about that the case mass production should become reality?

Well, it has. We got some brand new pictures for you.
The mould has been successfully calibrated and mounted on the machine.
The pieces you see are the first that has been spit out by the machine, so those are testing ones which are being checked.
Not all have the finishing applied - one nice picture that does show how it will look like with finishing applied is the one with the battery lids.

Those samples are being checked - and if they are okay (and they really do look fine), they will continue to spit out the cases and apply finishing.

Enjoy!

{phocagallery view=category|categoryid=21|limitstart=0|limitcount=0}

一些图片已经传到了 qi-hardware.com 的WIKI上。今天又拍了两张

下载是屏幕截图

Summary: 1)new Ben NanoNote software image delayed; 2)IDA Systems, Jaipur/India; 3) schedules for upcoming projects; 4) how to describe SAKC & Milkymist One
From the Qi Hardware Development List Wolfgang Spraul says:
Hi,

---1 new Ben NanoNote software image delayed

read more

配置: 

• CPU：336 MHz XBurst Jz4720 MIPS兼容 CPU
• 显示： 3.0” color TFT
• 分辨率： 320 x 240， 16.7M color
• 尺寸 (mm)： 99 x 75 x 17.5 (lid closed)
• 重量： 126 g (包括电池)
• 内存： 32MB DRAM
• 2GB NAND 闪存
• mini-USB: USB 2.0 High-Speed Device
• 外放，内置MIC
• 耳机接口 (3.5 mm)
• SDHC microSD
• 电池：850mAh Li-ion battery
• 系统：OPENWRT （GNU/LINUX）

NanoNote 是开放版权(简称开权)的硬件

一但购买了开权硬件的产品，其它关于硬件产品的资料你将一起获得如（原理图，源代码）。我们的使命是：为自由软件开发人员提供一个稳定 并达到量产质量的硬件平台，方便自由软件开发人员在上面开发有趣的程序。我们见证过一些硬件不稳 定，没有为消费者准备好的例子。那样的开放硬件无法克服不稳定的问题，软件开发总在不停地挣扎，受 到硬件不断改动的影响。我们在选择硬件设计时，一方面考虑硬件的稳定性和是否已大量生产，另一方面考 虑到它是否开放，是否为自由软件的开发提供保护措施和可能性。在某些情况下，硬件设计的确已经能运 行一些 Linux 内核版本，但内核却是过时的，很难去修改内核代码来达到其它的目的。我们让这一过程变 得容易。我们的主要承诺是给自由软件开发人员提供稳定，工作，高质量的硬件。有了这一坚实的基础， 软件开发人员能将精力放在为终端用户创造出绝优的应用软件上。

我们所有的步骤开始于寻找可以开放并且已经量产的硬件。我们与亚洲的制造商、硬件可以开放的或 是能够合作设计开权硬件的公司合作。我们的硬件设计工作的重点是记录这些设计，在开放版权下发布这 些设计，然后建立一个协作社区努力来改善设计。这些工作将利用自由软件工具如 KiCAD、 HeeksCAD，并且会以开放版权发布完整的硬件和机械设计。

开权硬件有着很好的前景。在专利系统下，终端用户受制于产品的生命周期。在专利的世界里有一个 预定的生命周表－EOL(End Of Life)。届时软件支持会停止，产品的计划会停止。而开权硬件是没有 EOL 的。设计始终为加强和扩展敞开大门;由于运行的是 GPL 的软件，终端用户总是可以自由地为自己 和其他人提供帮助支持。硬件的计划是开放 的。因为设计是基于开放版权，任何一个有新创意的工程师都 可以创建一个新的设计，当然只有那些愿意共享设计的才能享受到这种优势。我们的NanoNote发展计划很简单－ 循序渐进，不断提高。这确保了软件的开发工作。

NanoNote 应用：

1. 维基百科 离线版本，这样你就可以把世界上最大的知识共享库放到你的口袋里。
2. 电子词典 NanoNote 可以运行 星际译王， 有了星际译王NanoNote 比任何一个电子词典产品的字典都要多。
3. PDF 阅读器，虽然屏幕有点小。
4. 嵌入式开发实验平台，NanoNote 的所有的文档都是可以自由免费的获得。另外NanoNote 有一个从USB启动的功能，如果你不小心把 NanoNote 刷坏了。你总是可以从USB 启动来修复你的 NanoNote。
5. 自学平台，对于很多刚入门学习 GNU/Linux 的朋友来说不知道怎么下手。有了OPENWRT系统，你只需要输入两个命令等上～1个小时就可以完整的从0开始编译你的嵌入式开发环境。如果是最小化配置NanoNote 的文件系统只有 1.4M。

相关链接：

1. 官方网址：http://www.sharism.cc
2. 官方网上商店：http://www.nanonote.cc
3. 文档相关：http://www.qi-hardware.com
4. NanoNote 源代码：http://projects.qi-hardware.com/
5. NanoNote 刷机文件：http://downloads.qi-hardware.com/software/images/Ben_NanoNote_2GB_NAND/
6. 关于购买与使用问题可以发邮件到 ：discussion@lists.qi-hardware.com
7. 到这里定阅：http://lists.qi-hardware.com/cgi-bin/mailman/listinfo
8. NANONOTE的QQ群：90586412 欢迎加入。
9. 中文BLOG：http://www.openmobilefree.net

Repost of original vegyraupe wich Tuxbrain suscribe totally, due we share the same vision :)

Original:how did we get here « sharism.cc

Sharism has launched, the NanoNote is widely available and the pieces for other copyleft hardware projects are coming together. It is time to take a step back, pause for a minute and look at the road behind us. Not to wonder, but to realise what we have accomplished and what we still want to achieve. This is the first of a serious of posts shedding light on the history and more importantly the vision of Sharism at Work.

read more

Sharism has launched, the NanoNote is widely available and the pieces for other copyleft hardware projects are coming together. It is time to take a step back, pause for a minute and look at the road behind us. Not to wonder, but to realise what we have accomplished and what we still want to achieve. This is the first of a serious of posts shedding light on the history and more importantly the vision of Sharism at Work.

Moving through the history of the different personalities in our team, there are countless anecdotes and dreams that played their part. However, there are three things that always come up: security, the drive for freedom and the wish for true innovation.

After having worked in various companies and projects ranging from simple web development to complex, embedded systems all of us realised the great danger for the user’s privacy and security. Do you know what all the chips in your all-you-ever-want phone do? Are you sure that only you can control all data on your devices? Sure, this sounds paranoid, but think about it. Recent developments, such as the “Telekom scandal” in Germany and the IPRED law in Sweden have shown that customer data is not private per se. Play with this scenario a bit longer and you will see that the step to using micro chips to gather information on the individual user is not that big and who can be sure that it hasn’t been taken already? So our answer is: know your device! Only once the user has knowledge of ever piece of technology in his/her hardware and can decide what should or shouldn’t happen, do we regain real privacy and are free again.

Running whatever you want, whenever you want it is of course a huge aspect in freedom. Who is to say that your piece of hardware can only be used for this one particular action? Or what if you wanted to adapt a device to fit your needs? Right now you have almost no chance of getting exactly what you want. There will always be trade offs. We want to create a culture where sharing hardware designs is as common as sharing software. Imagine development kits for handhelds, a beginners kit for mobiles or a book titled “How to build your own toaster”. Why would we not take the liberty to build exactly what ‘we’ want, not what ‘they’ give us? You do it every day already, when you mix and match the software you want, and need, on your computer. Of course hardware is more complex and we don’t want to reinvent everything over and over again.

Inventions and innovation have become so complex that they are almost out of reach for the simple person. Even huge companies struggle to get the basics every now and again. The vast spectrum of products that are almost alike, and yet have different qualities and different values of effectiveness, shows that due to modern culture we reinvent stuff all the time. Looking at new technologies as the prime example. Once a new product is released, the other players on the market try to offer the same or similar functionality, but they have to start all over again. Just think. 5 R&D centers trying to innovate will fight the same problems and the same hurdles to achieve a single goal. Wouldn’t it be just natural if they’d work together? Isn’t the very basis of human interaction collaboration? We are not advocating a single R&D effort but innovation on a whole new level, where knowledge and resources are combined to create true competition on quality rather than just simple features.

To be continued :)

Thanks to everyone who RSVP’ed for the NYC meetup mentioned earlier. It will be at ITP on Saturday March 20 from noon to 6 PM.  There is no set agenda for the day, it’s simply an open meetup.  We want to meet  folks using Arduino.

We’ll also be meeting for drinks later that evening at a bar nearby, location TBA. So if you can’t make the meetup, come later for that. Watch this space for details.

We can accommodate about 100 people comfortably without disrupting student work on the floor. Based on the RSVPs we’ve gotten, we have slots for a couple dozen more. So if you’re interested and haven’t RSVP’ed, please send mail to team@arduino.cc. I’ll post again if we run out of room. Looking forward to meeting you all.

I was checking the statistics on the server this morning, when I discovered a couple of hundreds hits coming from a German illustrator (Johannes Kretzschmar) that posts his comics about technology in the form of a blog. Take a look at the one for today … one image sometimes counts more than 1000 words.

Arduino on Beetlebum.de, copyright by the author, 2010

For more illustrated fun, visit: Beetlebum.de

The NanoNote is conquering Europe!

It is now also available from Hackable:Devices.

The price is 99€ plus shipping.

Vous êtes invités à une réunion d’organisation du BEC qui aura lieu le jeudi 18 mars à 20:30 au Golden Gate Cafe, 3 rue St Georges à Rennes.

Au programme:
* rappel des créneaux et salles disponibles: 013, 014 et 015 au sous-sol du bâtiment 2A de la fac Beaulieu de 10:00 à 18:00 le 16/04 et 17/04. 3 salles de 50 personnes, deux seront allouées pour 2 tracks de conférences (pour un total de 32 slots) et la 3e pour workshops/expositions/socialisation/posters/nerdage.
* vote des propositions (les personnes du comité de programmation ne pouvant pas etre présentes enverront leurs votes par mail avant la réunion)
* matos et salle pour le concert du 15
* comm post-CFP: logo, web, affiches et flyers couleur
* inscriptions en ligne des visiteurs
* restauration
* équipement des salles
* hébergement des conférenciers
* streaming et enregistrement des confs
* signalétique sur le site
* assurance

ChangeLog:

• New, light Ethernet MAC (Minimac). We are looking for a developer to write a Linux driver for it – mail devel AT lists.milkymist.org if you are interested.
• TFTP network boot from the BIOS. This should make Linux kernel development a lot easier, by drastically reducing the time it takes to load a new kernel! The network configuration is described in this document.
• Fixed a bug with linear interpolations in TMU2 (reported by Jacky).

Alliance VLSI development cycle has stalled and there are many software compatibility issues that need to be solved before getting a proper (one that can meet the industry’s needs) digital backend flow with opensource software. Herb which was meant as a clone for Alliance VLSI will not be stable enough at the end of this year, nor I would expect some Mixed-Signal designs from it.

Since it won’t be TCL based, I doubt I would even use Herb myself. Hence, I’m investigating further on what should be done before one can design a mixed signal chip with the industry’s requirements.

Magic VLSI is fairly analog oriented, it is TCL based and it is lambda based. Since it is TCL based, it deserves credits. But being lambda based it makes it hard to go beyond 90nm process node with it since it won’t be accurate enough. Surely a timing correlation would prove this.

Magic’s 2 grid cells normally represent the length of the transistor. However, macro models of SRAM/ROM available in the LEF format include decimal points to reflect the position of different metal layers and vias. This is a major drawback with Magic VLSI.

Achieving digital implementation with Magic would certainly require new techniques about  how to use magic itself and how metrics (resistances, capacitances, switching activities,..) are extracted.

I started today with a case scenario: try to get a simple floorplan setup with some macro models. Nigel Nordsworth has kindly forwarded some Macro models. He is FEL’s test contributor for more than a year now. As mentioned above, LEF files might include X and Y positions with 3 decimal points in microns. Hence, to load the macro models, these X and Y positions should be multiplied by 1000 and thereby converting them into the nanometer scale.

Our current possible solution would be to use a Magic’s grid cell to represent 1 nm². This is not how one would normally use Magic. The complexity slope rises as all the tech files should be revisited and possibly be project dependent. Being project dependent, the solution would not be useful for the normal user. But once we can get a proper TCL package with can help us rotate the macro models and one of the 3 internal routers of magic can actually do some power routings (VDD and GND), we will present our solution for standardization.

instance_name ""
foreach instance [ cellname list instances ] {
    if { $instance == $element_name } {
         set instance_name $element_name
    }
}

select cell $instance_name
instance celldef $instance_name

regsub {\.} $xl {} xl
regsub {\.} $yl {} yl
move to $xl $yl

puts "Info: Moved the following selected Macro to ($xl,$yl)"

Using the above TCL commands just to move around the macro model I believe that a digital implementation should be feasible with Magic VLSI. But some intelligent mechanisms should be investigated about the timing and power correlations. As I wrote in the past, coupled with IRSIM we can even estimate leakage power out of the design during standby mode.

It should be exciting to design low power and low voltage designs.

Gracias a la amabilidad de los chicos del  null-lab de Cerdanyola en especial Irraz, podremos relizar  este taller

pensando para todos los públicos y no iniciados, que quieran conocer más afondo las bondades del hardware libre y más

concretamente del Arduino. Ofreciendo este taller de iniciación.

Podeis consutar la ultima hora y acutalizaciones de este evento en el wiki del null-lab

read more

I haven't had much time for blogging recently, too much exciting work going on at OsmocomBB:

• we now have simplistic support for Uplink (transmit) on SDCCH/4
• we have a minimal Layer2 (LAPDm) implementation
• we can send LOCATION UPDATING REQUEST to the network, and receive the respective response
• there's wireshark integration, i.e. all packets on the L1-L2 interface can be sent into wireshark for protocol analysis

There are still many limitations, but this is a major milestone in the project: We have working bi-directional communication from the phone to the network!

The limitations include:

• The cell has to use a combined CCCH (SDCCH/4 on timeslot 0)
• The cell has to use no encryption/authentication
• The layer2 is not finished, especially re-transmissions will not work yet
• There's no power control loop yet
• There's no timing advance correction

Also, the existence of a stable bi-directional communications channel between the network and the phone means that anyone interested in working on the higher layers can now actually do so. Completing and testing layer2 as well as RR/MM/CC on layer3 is a major task in itself, and it definitely requires the lower layers to be there.

The other good part is that development of layer2 and layer3 can happen entirely on the host PC, where debugging is much easier and there's no need for cross-compilation and we can use all the usual debugging options (gdb, valgrind, ...)

I'm now almost heading off for holidays (starting March 10), so don't expect any major progress from me anytime soon. I hope other interested developers will be able to take it from here and fill in some missing gaps until I'll get back.

Europeans are used to the fact that we are a conglomerate of multiple cultures. This affects more or less everything, even the press. When it comes to the maker culture, the US has the advantage of having a single market, a single language, and a single culture. On the other hand, Elektor is a brand that has been since long time ago aware of the fact there are people who don’t speak multiple languages (like e.g. English). Therefore their magazine has been published in different languages in different countries since as far as I can remember. At some point I was collecting it in Dutch, German, English and Spanish. You could find the January article on ARM from the Spanish issue, in the Februrary Dutch one, or in the May German one … and vice-versa.

Cover

Page 12

Page 13

March 2010, Elektor’s English edition brings an article on 20 Open Source Tools. Arduino is featured as the first one of a series of tools that we all admire. It is really nice to be featured in Elektor (though I know it is not the first time, there have been several articles before where readers were using the Arduino board to develop their projects). This same issue brings a very interesting article titled Small & Open Source embedded operating systems that can run on AVR … this means you could probably run many of those small OS on one of the Arduino board models.

Interesting features for embedded Linux system developers

Linux 2.6.33 was out on Feb. 24, 2010, and to incite you to try this new kernel in your embedded Linux products, here are features you could be interested in.

The first news is the availability of the LZO algorithm for kernel and initramfs compression. Linux 2.6.30 already introduced LZMA and BZIP2 compression options, which could significantly reduce the size of the kernel and initramfs images, but at the cost of much increased decompression time. LZO compression is a nice alternative. Though its compression rate is not as good as that of ZLIB (10 to 15% larger files), decompression time is much faster than with other algorithms. See our benchmarks. We reduced boot time by 200 ms on our at91 arm system, and the savings could even increase with bigger kernels.

This feature was implemented by my colleague Albin Tonnerre. It is currently available on x86 and arm (commit, commit, commit, commit), and according to Russell King, the arm maintainer, it should become the default compression option on this platform. This compressor can also be used on mips, thanks to Wu Zhangjin (commit).

For systems lacking RAM resources, a new useful feature is Compcache, which allows to swap application memory to a compressed cache in RAM. In practise, this technique increases the amount of RAM that applications can use. This could allow your embedded system or your netbook to run applications or environments it couldn’t execute before. This technique can also be a worthy alternative to on-disk swap in servers or desktops which do need a swap partition, as access performance is much improved. See this LWN.net article for details.

This new kernel also carries lots of improvements on embedded platforms, especially on the popular TI OMAP platform. In particular, we noticed early support to the IGEPv2 board, a very attractive platform based on the TI OMAP 3530 processor, much better than the Beagle Board for a very similar price. We have started to use it in customer projects, and we hope to contribute to its full support in the mainline kernel.

Another interesting feature of Linux 2.6.33 is the improvements in the capabilities of the perf tool. In particular, perf probe allows to insert Kprobes probes through the command line. Instead of SystemTap, which relied on kernel modules, perf probe now relies on a sysfs interface to pass probes to the kernel. This means that you no longer need a compiler and kernel headers to produce your probes. This made it difficult to port SystemTap to embedded platforms. The arm architecture doesn’t have performance counters in the mainline kernel yet (other architectures do), but patches are available. This carries the promise to be able to use probe tools like SystemTap at last on embedded architectures, all the more if SystemTap gets ported to this new infrastructure.

Other noticeable improvements in this release are the ability to mount ext3 and ext2 filesystems with just an ext4 driver, a lightweight RCU implementation, as well as the ability to change the default blinking cursor that is shown at boot time.

Unfortunately, each kernel release doesn’t only carry good news. Android patches got dropped from this release, because of a lack of interest from Google to maintain them. These are sad news and a threat for Android users who may end up without the ability to use newer kernel features and releases. Let’s hope that Google will once more realize the value of converging with the mainline Linux community. I hope that key contributors that this company employs (Andrew Morton in particular) will help to solve this issue.

As usual, this was just a selection. You will probably find many other interesting features on the Linux Changes page for Linux 2.6.33.

Buildroot is a embedded Linux system build system. It automates the process of downloading, configuring, compiling and installating all the components of an embedded Linux system, from Busybox to more complicated software stacks using Gtk, Qt, X.org, Gstreamer, etc. Buildroot is easy to use and extend, making it a nice choice for small to medium-sized embedded Linux systems.

As promised by the fixed-release schedule, a 2010.02 release has been published on Friday, with numerous improvements over the previous version 2009.11, many of which are part of the general cleanup process that the project is doing since the beginning of 2009. These improvements are detailed in the project CHANGES file.

Thomas Petazzoni, from Free Electrons, implemented several of these improvements :

• Creation of a package infrastructure for non-autotools packages. Buildroot had for a long time an infrastructure to factorize the code needed to build packages based on the autotools build systems. But all other packages were using hand-made Makefiles, which were hard to write and generated a lot of code duplication. Therefore, we have introduced an infrastructure that makes adding new packages much easier, and which allows us to cleanup the existing codebase significantly by factorizing a lot of common code. The autotools infrastructure has also been reworked on top of the generic infrastructure to avoid code duplication as well. At the same time, we have significantly improved the documentation on how to add new packages. This infrastructure is a building block that will allow us to easily add more features to all packages in Buildroot (such as package generation).
• Removal of the external toolchain source mechanism, which was merged with the normal toolchain building procedure. This special casing was implemented to allow the compilation of AVR32 toolchains, but such an additional complexity wasn’t needed. Now, Buildroot continues to build AVR32 toolchains as it used to do, but the code is much cleaner. Another illustration of our large cleanup effort.
• Many, many, many fixes to different packages, many of them to ensure that we do not depend on development packages being installed on the host. This is very important to ensure that our build procedure is as independent as possible from the development machine configuration.

From the list of contributors, ordered by the number of patches, Thomas Petazzoni of Free Electrons has been the first Buildroot contributor for this last release :

$ git shortlog -e -n -s 2009.11..2010.02
139 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
124 Peter Korsgaard <jacmet@sunsite.dk>
26  Lionel Landwerlin <llandwerlin@gmail.com>
23  Gustavo Zacarias <gustavo@zacarias.com.ar>
7   Julien Boibessot <julien.boibessot@armadeus.com>
4   Nigel Kukard <nkukard@lbsd.net>
4   Sven Neumann <s.neumann@raumfeld.com>
2   Anders Darander <ad@datarespons.se>
2   Chris Packham <judge.packham@gmail.com>
2   Daniel Mack <daniel@caiaq.de>
2   H Hartley Sweeten <hartleys@visionengravers.com>
2   Richard van Paasen <rvpaasen@t3i.nl>
2   Will Wagner <will_wagner@carallon.com>
2   William Wagner <will_wagner@carallon.com>
2   Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
1   Cameron Hutchison <lists@xdna.net>
1   Clark Rawlins <clark@bit63.org>
1   Francisco Gonzalez <gzmorell@gmail.com>
1   Francisco Gonzalez Morell <gzmorell@gmail.com>
1   Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
1   Lionel Landwerlin <lionel.landwerlin@openwide.fr>
1   Ormund Williams <ormundw@panix.com>
1   Rob Alley <ralley@NZ-DEV-HW-BS3.nw.local>
1   Sagaert Johan <sagaert.johan@skynet.be>
1   grante <grante@alpha.(none)>

For the next release, we will work on additional cleanup of Buildroot and particularly the target/ directory, which contains the code to build the Linux kernel, different bootloaders, and to generate the final root filesystem image in various formats. Improving support for external toolchains is also on our TODO list : supporting multilib toolchains such as the CodeSoucery toolchain, and fixing a long-standing issue with libtool.

Don’t hesitate to try Buildroot, and to report your successes and failures on the mailing-list, in our bug tracker, or on our IRC channel, #uclibc on Freenode.

As Michael stated in his review of the interesting features in Linux 2.6.30, new compression options have been recently added to the kernel. We therefore decided to have a look at those compression methods, from a compression ratio and decompression speed point of view.

This comparison will be based on “self-extractible kernels”, that is, kernel images containing bootstrap code allowing them to extract a compressed image. As underlined in the previous article, this approach is not used on all architectures. Blackfin, notably, chose a different path and compresses the whole kernel image, without including bootstrap code. While this has the clear advantage of making compression much simpler with respect to kernel code, it forces decompression out to the bootloader code.

Each of those methods has its advantages. Indeed, the Blackfin approach relies on the bootloader to provide the necessary functions, so that may be a problem to do things like bypassing u-boot to reduce the boot time. On the other hand, implementing it only once in the bootloader (as architecture-independent code) makes it unnecessary to write the low-level bootstrap code for each architecture in the kernel, which is surely interesting on virtually all architectures, the notable exceptions being x86 and ARM.

Gzip (also known as Zlib or inflate) has been the traditional (and, as a matter of fact, only) method used to compress kernels. Consequently, we’ll use it as the reference in the following tests. Our test environment is as follows:

ARM9 AT91SAM9263 CPU, 200MHz, using the mainline arch/arm/configs/usb-a9263.config

This comparison includes figures for LZO, a new kernel image compression method that I have contributed to the Linux sources, and which hopefully will make its way into the mainline kernel (the patches I implemented are still waiting for review from kernel developers here). LZO support in the kernel is only new for kernel decompression, as it is already used by JFFS2 and UBIFS. LZO is a stream-oriented algorithm, and although its compression ratio is lower than that of gzip, decompression is lightning-fast, as we will soon find out.

So, here are the figures, average on 20 boots with each compression method:

Bzip2 has not been tested here: the low-level bootstrap file, head.S, only allocates 64Kb for use by malloc() on ARM. Some quick tests showed that the kernel would not extract with less than 3.5Mib of malloc() space. That would require to modify head.S so that malloc can use more memory, which we will not do here. However, given that enough memory is usable on the system, one could well use bzip2. All the other algorithms performed the extraction using the standard 64Kib malloc space.

From the results, we can clearly see that LZMA is nearly unsuitable for our system, and should be considered only if the space constraints for storing the kernel are so tight that we can’t afford to use more space that was is strictly necessary.

LZO looks like a good candidate when it comes to speeding up the boot process, at the expense of some (almost neglectable) extra space. Gzip is close to LZO when it comes to size, although extraction is not as fast. That means that unless you’re hitting corner cases, like only having enough space for a Gzip compressed image but not for one made with LZO, choosing the latter is probably a safe bet.

Besides, the LZO-compressed kernel size is about 54% the size of the uncompressed kernel. As the kernel load time varies linearly with its size, load time for an uncompressed kernel doubles. While 0.55s are won because there’s no need to run a decompression algorithm, you spend twice as much time loading the kernel. This time is not negligible at all compared to the decompression time. Indeed, loading the uncompressed image takes roughly 0.8s. That means that at the cost of slowing down the boot process by 0.15s (compared to an uncompressed kernel), one gets a kernel image which is roughly twice as small. Rather nice, isn’t it?

Hi

usbboot is subdirectory in xburst-tools. here is the step to separate usbboot to an individual Git repository:

<> git clone –no-hardlinks git://projects.qi-hardware.com/xburst-tools.git xburst-tools.tmp
<> cd xburst-tools.tmp/
<> git filter-branch –subdirectory-filter usbboot HEAD
<> git reset –hard
<> git gc –aggressive
<> git prune

git filter-branch --tree-filter "rm -rf usbboot" --prune-empty HEAD
git reset --hard
git gc --aggressive
git prune

for more information :

http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository

In the Motorola/Compal C155 phone supported by OsmocomBB, we have found a ringtone melody chip called SPMA100B from sunplus.

As strange as it might seem, this is the only part used in the phone for which we have not been able to find any kind of programming information. So if you know anything about how to program this part from software (register map, programming manual, ...) please let me know!

And no, we don't need electrical/mechanical data sheets, thanks :)

Hey,

traveling season has begun and so I wanted to give a first review as well as a look ahead on things to come.

My first destination, in a row of short trips, is Paris. After a long Bus ride (don’t ask) from Berlin to Paris I got here and was welcomed with sunshine and good coffee.

During my stay which will probably end tomorrow (wednesday at 7pm) I plan to visit Bearstech and talk to local SHR developers. If you are in the area and want to see a Ben NanoNote and talk about paroli get in touch with me :)

Update: As I didn’t blog earlier meeting me will be difficult, but as you’ll see further down I will be back in Paris soon :) I can also update on the Ben NanoNote situation. We managed to flash a device here and it was rather easy and smooth. I expected the flashing to be more unstable, but I was positively surprised. A big thanks to Julien who did the actual flashing part :)

What would such a message be without proof? So here we go!

Here for non-flash download.

The next stop on the tour will be Berlin at the Atoms&Bits Camp from Sept. 26th to 27th. I will attend as many sessions as possible and of course carry a Ben NanoNote at all times :)

Next up is Paris again. I will be attending the Open World Forum from October 1st to October 2nd.

For now the rest of October seems quiet. On the second weekend in November FSCONS ‘09 takes place. I will give a talk on Copyleft hardware.

A trip to Basel concludes the current planning with the OpenZim developer meeting on November 20th – 22nd.

If you are in any of these areas and wanna organize a local meet-up outside of the mentioned events just let me know.

Any other events that you know of that might be worth attending?

Pictures will follow.

/mirko

Hey,

a lot of things have happened over the past few days. I wanted to touch on a view points here for those who are not subscribed to our mailinglist [1], yet .

First some small technicals, Mirko, together with the rest of the software team, reported progress in several areas:

[snip]
USB-Ethernet-Gadget is working.
You’re now able to speak ethernet, and therefore IP, to your Ben
Nanonote via USB.
That’s really cool, because now all the network-stuff can be used which
simplifies lots of things (e.g. SSH into the NanoNote, copying files,
etc.)

Lars found out the used NAND-chip is a multilevel-chip that has to be
treated by the flash-tools in a special way which should fix most of our
previous ECC-NAND-chip-problems.

OpenZIM, an opensource implementation for handling ZIM-files which
mainly provide wiki-articles (e.g. the wikipedia), it’s dependencies and
lynx as first webbrowser are ported to OpenWrt! This way the Ben
NanoNote can be used as offline wikipedia reader.
All of them need some more cleanups but will be committed soon.
Unfortunately the amount of RAM (32MB) of the Ben limits applications
like OpenZIM, so they’ll need some more tweaking to get them running
smoothly.

Thanks to Lars and Xiang Fu Sound (based on ALSA) and keyboard are now
supported, also work is going on to get the battery driver cleaned up /
improved (thanks to JieJing Zhang).

In addition there’s now a driver for the internally used real time clock
- also written by lars.

[/snip]

Wolfgang worked with Ingenic (the SoC manufacturer) and made amazing progress:

[snip]

good news for all Ingenic hackers: Ingenic agreed to install a little
rsync box behind their firewall that will rsync their ongoing Linux
and u-boot development svn repositories to our public server.
What that means is that any updates they do on the 2.6.24.3 or 2.6.27
Linux tree, as well as u-boot (old 1.1.6 version) and usbboot, will
become public the next day :-)

You can find the 4 new projects at http://projects.qi-hardware.com

ingenic-tools-usb-boot
ingenic-linux-01boot-u-boot-1-1-6
ingenic-linux-02os-linux-2-6-24-3
ingenic-linux-02os-linux-2-6-27

[/snip]

Atoms&Bits

Yesterday the first event (for me at least) in the Atoms&Bits Festival took place.

It was a reading of Cory Doctorow’s Makers. A very interesting meet-up of people from various parts of the Open Everything movement. The event will continue on Saturday for me. I will be around the event location, presenting the Ben NanoNote and the Qi philosophy. So if you have the chance, join us!

Design

We finalized the design of the device. Finally. Many tweaks here and there. Most importantly, the files are uploaded to our downloads directory[2] and of course are all released under a Creative Commons Attribution-ShareAlike license[3].

There is more news in the making and things will move quickly over the next few days, so stay tuned.

/mirko

[1] http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer

[2] http://downloads.qi-hardware.com/hardware/design/

[3] http://creativecommons.org/licenses/by-sa/3.0/

You have until March 10th to send us a few words on the projects or the subject that you would like to present at Breizh Entropy Congress (Rennes, France, April 15-17 2010). After your submission, we will contact you before March 20th to tell you if it is going to be part of the schedule. The schedule with the timetable will be published on March 25th.

ANYONE can submit a proposal to Breizh Entropy Congress: students, entrepreneurs, enthusiasts, artists… on ANY subject related to free and open technologies. This congress is about eclecticism!

To participate, send a mail to cfp@breizh-entropy.org including the following points:
- Format of the submission: lecture, workshop, installation, lightning talk, other…
- Title of the submission
- Name of speaker(s)/presenter(s)/artist(s)
- Language (if applicable): French/English
- Summary of the submission
- Short bio of the speaker
- Hardware/logistics requirements
- Contact e-mail and (if possible) mobile phone

The complete call for proposals is online.

Looking forward to your participation!
And we are grateful for any kind of distribution of this info!

Subscribe to RSS headline updates from:
Powered by FeedBurner

Okay, now some - really little - text I promised…

As you can I see Qt is running inside OpenWrt on the Ben NanoNote of qi-hardware. The device has only 32MB of RAM so this - especially this video I made (qt_openwrt_nanonote.ogm) with it’s coverflow-like 3d and mirroring-effects - shows the great potential of even such embedded hardware.

The Qt packages are not yet committed, I’ll do some cleanups and testing before.

However it’s almost ready to get its way into the OpenWrt packages repository.

Received a Ben NanoNote today. It is a really natty little device with a lot of potential.

My standard test on how hackable a device is involves getting Guile running. Anyway, it was pretty easy to accomplish this despite not using openWrt before.


root@BenNanoNote:~#
root@BenNanoNote:~# guile
guile> (map (lambda (x) (+ x 1)) '(1 2 3 4 5))
(2 3 4 5 6)
guile>


To install get the 3 xburst packages from here.

Happy Scheming!