If iPad is the pinnacle have we climbed the wrong mountain?

When I was young I tinkered with radios, record players and just about anything I cold take apart. I even started an electronics club at school, persuading a teacher to campaign with the faculty to buy some basic components and soldering irons. Our school had a single BBC computer between 1000 pupils which I managed to view from a distance. When I first went to technical college after school, we spent a year theorising, flowcharting & programming computers without actually using one. The net effect of this was I became disillusioned with computing, my school boy dream of becoming a robotisist was more or less scuppered by lack of hands on experience, in short I lost my way.

Later I revived my interest at a second college in London, it was very hands on affair with electronics. We built stuff like bistable and astables from scratch and programmed a microprocessor (6502) motherboard using a hex keypad and 7 segment LED displays. After this I attended university, focusing on Electronics Systems Engineering which was electronics with computing (analog and digital). We did things like analog control systems using analog computing blocks to create PID based control systems. One example I remember fondly machine having a dial that controlled via a motor another replica dial, the object was to get the replica dial to follow the movements you initiated on the control dial. This kind of problem sounds simple until you actually try to do it – Thats when you learn about dynamics, thats when engineering control and real world reveal themselves via experimentation. You take those tools that you learnt in Maths class and actually apply them to physically controlling something, its a real eye opener. Once you have been there its difficult to get the same satisfaction from any theory or algorithm. Doing stuff that has physical results is deeply satisfying and incredibly rewarding. Fast forward to today with the rise of making and hacking, I think this is why folks like to tinker and to hack, its simultaneously a creative, physical and educational exercise using 3 crucial parts of the brain. Adding opensource to the hardware equation engages a 4th part of the brain – social and community interaction, these in turn feedback,amplify and reinforce those creative juices.

In the earlier days of computing we tinkered and hacked a great deal both with the software and the hardware innards of computers. Eventually Apple and motorola, Intel and Microsoft came along and began their long journey of unification of computing singularity. As these companies pushed forward in their singular directions the other ideas and tinkering of computing fell away replaced instead by prescribed de-facto standardisation and convenient monoculture. I think we lost a great deal on that journey, the train was moving so fast that alternative concepts were simply passed like passenger-less stations on an express line. so keen were the drivers of these corporations to increase their revenue, that little thought was given to the question of whether it was the right direction or not, we were launched headlong into obscurity, conform or be dammed.

I think now however we are coming to the pinnacle of that ignorance, the train is slowing and the wheels are starting to rattle loose, the energy providing the locomotion is no longer sufficient to provide acceleration, rather we are now experiencing deceleration. But this isn’t a train wreck its more a darwinian, a fork in computing evolution that leads to a thousand dead ends, some of which will take years maybe decades to fizzle out. The latest greatest example of this is the iPad a minor fork of a struggling branch, one of the latter attempts to reinvent this evolutionary cul-de-sac.

At the same time the iPad reveals how this once firm evolutionary trunk is beginning to bifurcate, take at look at its innards to reveal ARM based processing from what was an embedded microprocessor IP company, very different from the end to end design and manufacture of Intel and motorola. yet the iPad is the ultimate in this same trunk of evolution, an inevitable device hatched to be used as an instrument of consumption. This is not a computer with which you hack or tinker, it is not a device for which you are expected to create, this is a consumption gateway to its vendor, the pinnacle of our computing evolution. This is what our best minds can come up with, a hands off, narrowly purposed sleek design, disguising the fact that underneath it is just pretty cash register for its manufacturer Apple. Pretty soon the rest of the herd will follow in their footsteps placing the final nails in the coffin of this popular computing evolution.

Obviously I am little sad to see it decay in this manner, but I am not surprised, it was inevitable, driven by a selfish 20th century industrial strategy, the result of a economic foundation whose days are numbered. But surely I hear you say “it has been huge success, look a the proliferation of personal computers, look at how little they cost, look at the bang for buck you get from these prolific PCs.” It is true, if population is a measure of success, then they are very successful. However throughout its ascent I have often wondered about those ideas that have fallen by the wayside, all of those missed opportunities, the many diverse possibilities that could have taken us down different roads. Maybe just maybe things may have turned out much more different even more successful and much more diverse. For example if we had taken a more concurrent approach to computing from both a hardware and software perspective rather than being blindly led by Intel’s clock race we might have ended up with a more evolutionary successful class of computing. Something much more robust than the current crop of high end PCs and servers, something more creative and enabling than the iPad.

But these are just whimsical what ifs, we cannot change the past, what is done is done. But we can invent our own brighter innovative future. This is a good time to reinvent a better more flexible computing, one not tied to clock races, corporate profits and monocultures, rather something more radical, computing that can effectively reinvent, reconfigure and replicate itself on the fly. Computing that is designed with real world concurrency, responsive,reactive and parallel like the real world, something not hampered by 20th century sequential thinking, a new computing of real and the physical rather than a virtual one. More importantly I want computing I can tinker and experiment with, something not confined to repetitive recipes, but one with infinitely combinational components with which I can assemble new ideas. Computing that connects to physical as well as virtual, computing which enables the internet of things, computing that enables me to make new things. Most of all I want creative, intelligent computing not stupid consumptive computing, I want 21st century computing for everybody and everything and all the things I cannot even envisage yet and I want it open completely open from the bottom up this time.

Who is with me for a better, brighter and more innovative future..

OSH a way forward Pt.3 – XCore & Amino Fusion

So in part 2 ‘OpenSoftChip’ OpenSource Hardware (OSH) a way forward I provided some details on XCore from XMOS and expanded on why the approach beats Microcontroller (MCU) + FPGA for DSP like applications. In part 3 here I would like to cover XCore as a primary candidate for the Amino project, so lets remind ourselves of that projects initial aims:

1. Modularisation – A modular topology enables common components to be snapped together using composition, allowing focus on just the custom features of a given project or task, it also reduces complexity and leads to faster project turnaround.

2. Standardisation – In order to have modulisation and composition as well as reuse, standardisation is required via opensoource implementations made available for testing, production, modification and experimentation.

3. Digitisation – Opensource software is perfectly digital it’s reproduction is as simple as copying bits, hardware isn’t so simple, but the more of it that can be digitally expressed and rendered the easier its reproduction and the more accessible it becomes to a larger audience.

4. Reuse – Being able to reuse as much hardware and software as possible reduces consumption and is more environmentally friendly. Common modules or components can be assembled at reduced cost minimising overlap, they can be reused time and time again for experimentation and prototyping. Hacking culture often seeks to reuse, mashup and redefine items for use elsewhere, design should embrace this modern form of cultural reuse.

it may also be useful to refer to the historical framing of this from the Open Hardware Production post.

Lets tackle these with XCore at the center of Amino and perhaps makes some comparisons vs MCU/FPGA along the way.

Modularisation

Ports & Expansion

Originally to provide modularisation we extended the shield concept into a bus with ports. The MCU+logic would provide simple 8 bit busses for expansion. Although this was an improvement on the shield concept, by enabling multiple hardware modules to be used together, limited MCU pin numbers combined with hardwired functions made this an exercise in juggling and resulted in significant compromises. Using XMOS XS1 series soft chips provides significantly more I/O pins and ports which are dynamically reconfigurable, these are closer to an FPGA than a MCU. This flexibility enables an Amino development board to have many I/O ports which can take on multiple personalities/functions as dictated by the add on module hardware and a corresponding software driver*. Its worth noting that we are only using and defining digital I/O with the new designs, analog is added via modules to provide maximum flexibility.

Ports – Response & Control

In addition to the I/O modularity, we also get solutions to some of the more complex issues. Dealing with I/O in a timely manner using MCUs requires the use of interrupts which tend to be limited on MCUs, often logic is added to provide flexible port I/O response and management of interrupts. With XCore’s event driven I/O architecture these problems are eliminated completely and become part of the software and the module itself.

Ports – Special functions

Unlike MCU which use dedicated pins for special functions such as SPI,I2C etc.. XCore defines the pin functionally in software itself as a driver. Thus such functionality can be loaded at runtime according to the module requirements. This may seem counter intuitive at first compared to dedicated hardware blocks within an MCU. But it means you can have any number of pins dedicated to any number of functions rather than being limited to what’s hardwired on the MCU. For instance my application and its modules could require lost of SPI channels or UARTS, XCore can handle these requirements by dynamically loading the functions as required.

Ports – Dynamic Adaption

Even though I have not worked out where such an idea could be used in practice, an XCore could effectively change its pin functions during runtime to adapt to hot swappable modules or even complex modules that actually change there own functionality at runtime. This is an area that would be worth examining in the near future to take Amino to a completely new paradigm.

Standardisation

The physical pins will likely be grouped into 4/8 or 16 bit segments to provide standard pinouts and polarisation, logic will likely be at 3.3/3.6 volts to accommodate a wider range of modern peripherals not capable of 5v operation. The rest of the standardisation is defined by the software drivers and a simple XML configuration file. In addition to the regular Port expansions there will also be Link expansions to enable units to be interconnected to deliver arrays for more complex computing requirements. Debugging would be achieved using JTAG like schemes which may also be available on board via a USB interface. The programming environment will use a standardised toolchain and all hardware and software will be opensourced (there may initially be some limitations until all of the new toolchain pieces are completed). Because of the software nature of the standardisation an Amino board can be updated in the field to support any changes and or patches to the standards. Standards will be governed by full opensource implementations, these will act as de-facto standards and anyone can reproduce them in an opensource manner. This is key to any potential opensource distributed production tenets and as such will be encouraged to enable development and innovation across the Amino project. I am also looking at what can be included in the standard for testing using loopback and maybe even virtual instrumentation. Here standardisation enables replication to a given operational specification, important for opensource distributed production.

Digitisation

Here we are again playing to OSH strong points as illustrated by Arduino. In this case however we take it even further, with the digits controlling much more at a much lower level and with a much greater capacity for programming. Because such a large part of Amino using XCore is digits it is easily replicated and shared. In fact building a large opensource code base is the primary task for Amino’s success and is the number 1 focus right now. It will also allow new participants to build on the ‘shoulders of giants’ and lean on the wealth of the commons.

Reuse

A great deal of XCore Amino fusion is really just software, reuse of bits is trivial, so much so that it could actually be reusable at runtime which is an interesting concept. Also because of its greater modularity and more flexible core its uses multiply. Thus it can be plucked out of one project or design and placed straight into another. I am also tempted by a lego like composition that enables projects to be completed with multiple units increasing reuse even further.

Moving Forward

So the combination of XCore and Amino aims fuse together nicely, what’s more the XCore blows the other candidates away when it comes to the key tenets of the project and thats why we don’t have the MCU + FPGA deliverables, there really isn’t any point. Instead I am focusing my time on developing the software architecture and standards alongside several XCore based boards in Fast, Faster and ‘To infinity and beyond..’ flavours. At this point I am developing using existing hardware development kits from XMOS themselves, and will have the software operating on several of these first. Plus I will also be making sure it runs on a stamp like board, possibly Omer’s Stamp board in the very near future.

As usual if you are interested in Amino or XCore let me know, if you want to help there is plenty to tuck into. Obviously we will be chewing the fat around the board and software designs as we post here so please contribute and let us know your thoughts.

At some point I would like to add a part 4 to OSH a way forward concentrating on ‘infinity and beyond..’ and where that could take us, but right now I am still gathering thoughts around how that will function and how it can be managed and how we could use composition to solve more complex projects, so watch this space.

*Note I use the term ‘Driver’ here but really it is a simple software module that can be dynamically loaded, driver is a little overkill but conjures up the basic idea.

OSH a way forward Pt.2

OSH a way forward – Part 2 OpenSoftChip

So this second post would be a good place to explain where we are coming from with regard to moving OpenSource Hardware (OSH) forward, also see Open Hardware Production for a historical background/context. Obviously many folks working on many projects are all contributing to moving OSH forward, but my primary concern here is what started out as the Amino project but has expanded beyond this into more complex open hardware projects with significant performance requirements. The Arduino is a great example of successful OSH and it has opened up 8bit embedded development to the opensource world. Arduino represents an approachable platform for anyone with only modest programming knowledge to get a taste of what OSH can achieve. Amino began to see if that approach could take things to a much higher level, to bring much more within OSH reach, challenges not practical on 8Bit Microcontrollers.

Initially I and others envisaged the combination of microcontrollers (32 bit) being combined with FPGAs to provide a more powerful OSH development platform that could tackle Digital Signal Processing (DSP) applications like audio,video,voice,gesture,AI as well as opensource robotics and vision projects. In this model the stuff that has to be processed quickly is handled outside of the micro by the FPGA, opensource modules would be effectively loaded in suitable for the task : MACs,FFTs whatever. The trouble is FPGAs tend to be built around proprietary IP and tools, even though there are Open Cores and GCC based tools getting this stuff to play nicely together is very difficult. Add to this the complexities of HDLs, VHDL/Verilog,C/C++ models and simulators and pretty soon you need to be an expert to do anything useful. Even if one could modularize the FPGA parts integrating back into the development stream with the microcontroller codes add yet another moving target. I am not saying it is impossible to achieve the FPGA/Microcontroller marriage but doing so in an OpenSource manner is virtually impossible. One could also integrate the controller into the FPGA itself but often this modus operandi is again limited to IP rights and licensing issues.

That is when I figured that rather than using traditional Logic blocks within an FPGA, instead use super fast mutithreaded simple 32bit cores (or multicores) able to achieve results beyond microcontrollers and well into the FPGA applications bandwidth ranges. The theory goes like this ; rather than building VHDL rearrange the problem into a programming problem using more familiar programming languages like C/C++ with added concurrency constructs. In fact there are examples of this already within the FPGA world which are then translated back into logic blocks or HDLs. In this case however no translation is required, we assume that the ‘software chip’ has enough threads/cores in order to execute the concurrent code within the bandwidth envelope. It also makes simulation easier as one isn’t needing to convert into exotic HDLs and deal with widely varying latency/timing issues. One of the other advantages of this route would be the learning curve and the ease of use and entry for programmers as opposed to traditional electronic engineers. Another major advantage is that it could use proven opensource toolchain like GDB/GCC/Eclipse to provide a good overall OSH environment. What is more this model builds on the success of the Arduino where the software is the hardware approach that has proven so popular.

So is it possible to achieve this feat, is there such thing as a ‘soft chip’ that is capable of tackling at least modest DSP/FPGA applications? and can one build an opensource toolchain around it? What about the power requirements if its tens of watts then its not practical? Well the parallax propeller is an interesting candidate but fails on delivering an opensource toolchain. Its programming leaves a little to be desired along with its performance due to going the interpreted route, although incredible results are possible using its assembly language, its a good start but we can do better. We are in luck however as the XMOS XCore range of processors and development kits offer what I have enumerated and much more. It may also be useful to check out the heritage of XMOS and its founders, you will discover things like the Transputer and Occam, ideas before their time but perfect for our emergent issues and challenges. So this is no fly by night idea, many of the XMOS technologies and ideas have solid research and experimental application footing spanning a couple of decades.

More importantly XMOS have taken their lessons from INMOS and it’s Transputer/OCCAM and added much more to focus the technology for the current era. In case you haven’t heard, concurrency is the next programming language killer app, I’ve personally spent the last couple of years coming to terms with it using languages like Erlang. It is amazing how much easier concurrency is if a language has concurrency at it’s foundations and within it’s primitives. Languages like C/C++ make the transition exceptionally difficult and fraught with hidden dangers, liable to trip up even the most experienced developers and engineers. XMOS have tackled this by creating a language called XC (PDF), which looks a lot like C and will help in the initial learning curve for existing mirocontroller programmers (XCore also supports C/C++). XC however also has roots in Communicating Sequential Processes CSP and includes primitives that not only provide concurrency but also simplify event driven programming for hardware. Rather than having to come to terms with complexities of Interrupt Service Routines (ISRs) and the multiplexing of them using a Realtime operating system (RTOS) one can use an XC based event driven approach to solve concurrent hardware processing simply and logically. I would say it is almost natural in the way one uses events instead of the engineering abstract Interrupts found on traditional microcontrollers. As for the performance of the XCores themselves even the basic single core L1 chip (<$5 in quantities) zips a long delivering 400 MIPS across up to 8 concurrent threads, with further models such as the G4 (<$14 in quantities) containing 4 cores each with 8 threads per core or 1600MIPs in a 11×11 mill package that doesn’t need a heat sink!! And if thats not powerful enough for you you can build hypercubes of G4’s to rack up the proceessing power you require e.g the 25GIPS XMP-64!
As a bonus for hardware hackers, the XSI chips come with lots (I mean lashings) of I/O ports just like an FPGA only better!

But one of the key features about XCore (and XMOS) is their opensource friendly approach. I don’t mean just paying lip service, they actually developed XC around the opensource LLVM project which I have talked about before and where incidentally I first found out about XC. Not only that but XMOS are committed to a complete opensource toolchain including eclipse which makes it fit into OSH snuggly. Further more, initial conversations with folks at XMOS and within their communities, have shown that they are excited by the possibilities that OSH and XCore together can achieve in 2010 and beyond, I will have more on specifics later in separate posts.

A company with this pedigree, and such timely technology including good opensource tools and a community approach is just to good a chance to miss IMHO, we should take advantage of it and take the technology places others have only dreamed of until now.

In the next post (part 3) I will touch on Amino and how XCore can help deliver some of its goals, and perhaps paint a picture of how far we can take the idea..

Epiphany – Part 1 OSH a way forward

OpenSource Hardware a way forward – Part 1 Epiphany

So 2009 passes and 2010 begins, it’s goodbye to the ‘noughties’ and hello to the ‘teenies’? For Folknology however the start of 2010 is an important milestone and marks the transition away from software only projects, everything from here on out will be a combination of software and hardware, we are not taking on any new software only gigs. It is also the start of potentially fascinating decade of possible innovation not dictated by the Microsoft/Intel unnovation, but rather by emergent opensource hardware and software combinations that will bring into existence completely new ways of building information technology innovation.

As part of my research over the last two years at Folknology I finally have some of the pieces of the Opensource Hardware (OSH) and OpenSource Software (OSS) jigsaw in place, enough to begin building a much bigger picture. This also means I can focus in on some of the critical tasks that are required to move Folknology’s OSH plans forward. It is always good to sharpen one’s focus so that the building can begin on a solid foundation. But before I enumerate where the labs are heading I would like to give you an update for the last 3-4 months where it has all come together.

Whilst working on Amino at the end of summer 2009 I met with and researched microcontroller vendors like TI/NXP and STM etc..those conversations reshaped the initial plan for the project, I ended up dropping STM and looked at porting to NXP’s ARM Cortex M3 with a view to later settling on NXP’s emerging Cortex M0 platform. The reason for the change was based around cost/performance/value propositions that the M3/M0 combination offered. NXP was the only vendor that could provide pin compatibility all the way through along with tempting pricing. More importantly NXP had a promising story around opensource toolchain support (based around OCD/GCC/Eclipse). So why aren’t I announcing the proverbial ‘Amino delivered using M0/M3 NXP parts’ win post? Well the tools/parts I needed to follow through didn’t show up within the expected timeframe, this wasn’t any major slippage, rather just a short delay and poor follow up by the vendor. The delay was just long enough to give me thinking room to explore the upper bounds of Amino as projected into the future, the breather enabled me to explore some ‘what ifs’ particularly with respect to the higher end applications around audio/video/music and other general DSP like requirements. I had always planned on adding FPGA modules to help handle these more bandwidth intensive applications of Amino. It was in this period I started hitting road blocks, the FPGA market place is a mix of competitive silicon production of increasingly high densities, interlaced with numerous business models based upon intellectual property (IP). It is not straight forward and there appears to be little appetite in the industry for an opensource approach to innovation. In fact the more I spoke with industry proponents the more alien the concept of opensource hardware/chips became. I was just getting to the point when I was ready to kick down a few doors in anger when I had an epiphany, not a sudden one but rather something that had been bubbling up for months unconsciously, triggered by a conversation with a like minded individual. I was at the Open Hardware Camp at Nesta having a few drinks after the event chatting to Omer about the things we were both working on. Coincidently he was about to embark on a fiendishly complicated PHD project around reconfigurable vision systems and had been doing a lot of FPGA research before implementation. As I explained what my problems had been moving OSH format forward around Amino, I managed to coin what I thought represented an ideal vendor offering, the core technology that could enable the transformation we required.

My thinking was based on conversations with many folk over the months but boiled down to what if the basic logical building block was a super fast multithreaded cores that could be assembled in multiples to match the application, rather than the tricky FPGA programmable logic blocks which varied considerably between vendors. This would allow the complex FPGA proprietary toolchain issues to be bypassed and a simple code based model (c/c++ or new even a language) to be developed around existing opensource tools and libraries, I even mentioned parallax’s propeller as an interesting but less than perfect example way forward.

With Omer’s interest in Arduino as well as he’s knowledge and experience of the FPGA issues he quickly got where I was coming from and asked me if I was familiar with XMOS, as he had also been working with the XCore silicon and was even considering arrays of G4 multicore versions on mass like XMOS’s XMP-64 platform as a possible hardware candidate for his PHD thesis. It was at this point I had my epiphany that maybe there was already a way forward that I had forgotten about months ago, I hadn’t looked at the XMOS technology since early 2009 when I was still thinking Arduino compatibility and it had completely escaped me as a candidate to solve the current issues.

The next few days were spent catching up with what XMOS had planned and what their game plan was moving forward. It became clear to me that they could well be a candidate not just for Amino but a range of higher end ideas I had been playing with for sometime. Over the next few weeks and months it became clear that XMOS was not just a candidate but quite possibly the answer to more than one of Folknology’s visions, so I decided to integrate those concepts into a more coherent strategy not just with Amino projects but a number of potential community initiatives that could help push the OSH envelope much further forward perhaps in conjunction with XMOS themselves. In the next few posts I will expand on Folknology’s OSH vision for 2010 and beyond as well as the opportunities offered by technologies like XMOS’s XCore and their opensource toolchain and look forward to your contributions and feedback..

OpenSoftChip Part 2 of OSH a way forward

Lab Prototypes updates

Just to keep everyone up to speed I have been working on both the Arduino prototype boards following feedback and further enhancements.

Heres the new Protuino layout :

Here are the enhancements:

1. The D-Type is now optional, allowing another 2 x 16 0.1″ row and/or a second DIL placement area adding lots more flexibility.
2. Added 3 pin 0.1 spacing to allow side slide reset switch (or external) .
3. Optimised the tight routing around the ATMega.
4. Added (optional) ferrite bead smd to reduce noise on power line for analogue work.
5. Added extra decoupling capacitors (optional) in first DIL placement area.
6. Added optional blocking diode for alternate comms supplied power source
7. Re-routed power circuits for easier access and layout
8. Added top and bottom ground planes.
9. Eliminated the need for any compulsory smd components

I want to get the first Protuino batch ordered in the next few days (we have some urgent prototyping to do!) so if there is any further feedback let me know swiftly.

I will continue to work on the arDuino-Proto shield as that will be next up for production.

Protuino – Prototyping Arduino or AVR

We had put off our arDuino-Proto board build until we new exactly how many we wanted to order, in addition a subtle change in our PCB sourced pricing, this lead to a  restriction in the boards dimensions. Whilst all this was occurring I had a sudden brain wave. What if we didn’t go the regular Arduino shield route, what if the prototype boards could directly accomodate Arduino or AVR circuitry?

So I scratched the itch and below is what I came up with:

Protuino PCB (minus ground planes)

It provides a barebones like Arduino onboard with minimum components along with a small prototyping area.

here are some key features:

1. I tried to make it as low cost as possible (cheaper than a shield as no headers required)
2. Smaller than the Arduino shield version
3. It can be Arduino and AVR going down to ATMega4x…
4. Its a member of the D-Type revival using an (optionally) 15 Pin D-Type connector
5. Its cuter and smaller than a Duemilanove for prototyping
6. Did I mentions it ’s going to be really low cost!

Overall I really like it and am going to order a large bunch of these for the lab, let me know if you want in on the order the cost should be less than €3/PCB depending on the quantities we aggregate over the next few days.

Folknology Labs AVR board – Labduino?

We have a couple of interesting lab projects on the go that require a small AVR controller board. These projects fall into our ‘Lab category’ as they are part of tooling, instrumentation and control equipment that we are working on. Originally we thought about using one of the current crops of Arduino, primarily because we are prototyping using Arduino software and boards. However when we looked at the problem more closely we realised that a number of these projects shared more than just a micro-controller.

It became obvious it was time to scratch an itch so I set about designing a small AVR board with the kind of features we needed for these projects. I am just finishing the PCB layout but figured I would put it up for your perusal and discuss what the board provides in case anyone else out there is interested in using one.

Here is the PCB (without ground planes)

We haven’t yet come up with a name for it (the project was originally called MiniPID as part of a small PID controller, Labduino is one suggestion) perhaps you can come up with something better? What it fullfills is the following requirements:

1. Arduino software compatible (at least for prototyping) which allows us to leverage existing code.
2. A numerical display – 4 digits in this case, we could have gotten away with less, but that would have limited this boards applications.
3. Ability to drive small motors, relays, solenoids and externally powered devices (> 5v/3.3v).
4. A way of programming it when developing new uses – serial port in this case.
5. It must be compact and low cost to produce.
6. We wanted to be able to build it by hand so avoiding any of the high density SMD parts (MLFs,TQ/VQ packages etc..).
7. It should still be expandable so we can add custom peripherals for  each application, primarily analogue interfaces but serial digital could also be useful.

Here is the annotated birds eye view of the design

I also managed some quite nice design wins which took me a little longer but I hope will pay of in flexibility.

1. The display and controller sections are modular and can be separated by a single Guillotine cut on the PCB. This enables the display section to be separate from the main controller making housing more flexible. It also allows each module to be used separately later on. For example we may look at a more integrated controller using an ATtiny with analog circuitry on the PCB  in an even simpler single board solution. This allows cleanly forking the project later.
2. The display also has a pair of linear or bar-graph displays which extends its functionality and range of applications. These turn out to be quite handy as an accompaniment to the numerical displays. They can provide instant level feedback or can be used to illustrate timing or steps etc.. In fact if only a few of the leds are populated they could show things such as modes or warnings so it provides a lot of flexibility.
3. The serial coms should fit to a standard Arduino USB – RS323 adapter cable which are commonly available.
4. The controller board houses a 28 pin DIL socket which can house any of the ATmega48-328 microcontrollers allowing the most economical controller to be chosen for the given job.
5. Despite its small size (~50mm x 50mm) I managed to squeeze  in an ICSP programming port, Analogue port , SPI port, serial connector  and higher current digital open collector outputs all of which are on 0.1″ headers. One can either attach a small shield or expand horizontally using right angled connectors.

One of the original projects which will use this design requires a PID which naturally needs things like a numerical display, in our case it also needs timers and control curves. Labduino lends itself to lots of other applications like monitors & controllers of anything numerical from metering to sequencing, I would be really interested in what you can think of application wise, got any good ideas for its use? There may be a freebie in it for a deserving purpose.

So as usual let me know your thoughts, if you see any mistakes or can suggest any improvements please do. If anyone fancies owning one of these little puppies to play with or for your own projects please let me know ASAP as I am about to get a batch of PCBs ordered along with components. If you are interested it will be provided in kit form or just PCB to build yourself as we do not have assembly folks. Given it would be a DIY board I must warn you that it is not a board for a beginner, its small and quite tricky involving some SMD parts in tight spaces! But if your confident it could be yours at cost, if you want a challenge perhaps you could get someone to help you put it together. As usual the board will be Opensourced just as soon as I have optimised it and  cleaned it up etc..

Board Run – arDuino Proto

Hi folks, We need some boards to do prototyping on Arduino so I am about to perform a prototype board run for the lab. Given that others often require such things I am putting up a prototype design shield for the Arduino (different from some of the others out there). One of the key things here is better cabling hence the ‘D’ connector (more of that D revival..) this makes interfacing simpler and more robust. You can even use these cables to just patch Arduino signals which is really handy.

Please take a look at the PCB layout below

If you have any suggestions, changes or notice any mistakes please let me know.

Obviously the more we can all order together the cheaper each board will be, and we will pass them on at cost as usual.

regards

Al

Amino part of the D-Type revival

Idea for Amino to tackle the cable issues

Amino D Type

OK so I have added a high density 26pin D-Type along with the USB connector. The D-Type Connector provides robust cabling (including screws) so I am hoping that this may be a way to go particularly given that its build in so should be robust.

As usual let me know your thoughts, is this a good idea are we having a D-Type revival? Or do you have other ideas?

Al

Arduino, Armadillo, Armaduillo, Amino

I would like to provide a little more history of  a project that has been taking up a lot of our time. This project has been on the drawing board for some while and originally started under the label ‘Armadillo’. In it’s initial guise it would have become an Arm based Arduino, one that offered a little more processing power among other things. Armadillo however rapidly became fused with another project to improve Arduino’s expansion and openess (OpenSource and open as in processor agnostic). The idea was that of an OpenSource bus with standard peripherals as well as custom and customised peripherals complying to some basic but flexible guidelines.

To differentiate the new version from Armadillo we conjured up The label ‘Armduillo’ this also helped disambiguate from discussions on the Arduino forum by others using a similar term.

Armed with the new Folknology lab plans for the Armduillo I decided it was time to out it to the community which spawned it  - Open Hardware Hackers (#OHH) London chapter. The meetup was a quiter one than usual which was fortunate because we had lots of time to talk about particular projects including Armduillo. The initial design followed the Arduino physically by providing shield backward compatibility, this quickly became an obvious flaw in the design. Many of the issues we are trying to solve are actually hampered by the original physical layout. We talked about a number of its other features and the possible future development of the idea to its logical conclusion. The meetup provided excellent feedback, especially when dealing with the nitty gritty of Paul’s ongoing project in which we intend putting it to good use. Peter as usual provided some fantastic insight from his own experience of using and supporting the Arduino at TinkerIt including the daily burdens of such support.

As a result I decided to sit down and redesign the layout of the board subtlety taking into account the feedback from the meetup. Thus I would like to show the revised layout so that similar discussion can take place before we move the first batch of prototypes. The initial batch will probably be 4 or 5 units (we might consider a few more) to enables us to help finish the software and fix any early issues with the design. If you would like in on the first batch let us know ASAP as we might be able to stretch to a few more.

At the same time we have renamed the project to ‘Amino‘ to better reflect where it is heading and to remove some of the previous associations. For example although we are looking at providing levels of compatibility with Arduino, we are not letting that hold the project back from its longer term goals. For example we are not providing physical compatibility with Arduino shields on the basic board although we may provide a shield adapter for this purpose if there is demand for it. This is largely because of the design flaws of the shields themselves, confined by the Arduino connector scheme. Of course these sorts of design decision carry risk but sometimes tough choices have to be made, we would certainly be open to alternate view points on this prior to the initial prototypes, just make yourself heard.

So I wanted to put up the layout of the board to enable some further discussions to take place around the new design, take a look below at the highlighted board layout :

Amino Board Layout

The board dimensions are Approximately 55 x 45 mm subject to change even though the PCB is 90% done a little  power routing, via optimisation and ground plane is needed and hence may change things slightly.

Heres a quick once over of the board connectors

I will start with the Bus ports (the original ebus concept) A to C coloured yellow, blue and green. These are comprised of  2 dual row 8 pin 0.1 inch female connectors carrying the power and digital parts of the bus and a single dual 2 pin analogue 0.1 female connector. Each digital bus is composed of power plus a bus addressable SPI interface and an 8 bit GPIO port. The analog section contains 2 analog input channels, a single AREF along with an analogue ground pin. The bus cards fitted with dual 0.1 inch right angled  pins slot vertically into the appropriate bus port. The cards may or may not include the analogue pins, but should include the power and digital pins (it is actually possible to exclude some of these).

Thus the expansion capabilities of the bus ports offer 24 bits of GPIO, 3 SPI channels (individually addresable) and some control signals. To complement the digital, each port has 2 analogue inputs and a common reference voltage with an separate ground.

In addition to the bus ports there are expansion and support connectors, all of these with the exception of the JTAG port are horizontal expansions and will be populated with right angled dual row 0.1 inch female sockets. These allow sideways expansion of up to 16 bits of GPIO, 6 analogue channels (repeat of ports A to C in this case) and addressable SPI ports (2 additional addressable spi channels from those on the bus ports). Also hidden within these connections are board to board/Peripheral/PC interface with USB currently heading the candidates.

The Micro itself is an STM32 series micro-controller the details of which are not fixed in concrete as the board can accommodate various members of this family. It is likely to operate at 72Mhz and contain at least 128K Flash and 20K Ram, in fact it may be available in different configurations offered by its distributed open production.

One of the key design changes that have taken place is the expansion ports which are now presented in a grouped horizontal fashion at the north of the board. This design achieves a number of advantages vs the earlier shield based layout.

1. It is not confined to the Arduino pinout and limited connections, yet it provides signals to enable a shield adapter to be created.
2. It maximises the number of expansion possibilities by exposing all of the unused pins.
3. It enables the expansion to solve the common production cabling issues such as those discussed at #OHH (I hope to provide an example of this shortly as part of the initial prototype design).
4. It provides enough flexibility to handle common case flat peripherals such as displays, communication as well as general inline I/O perhaps terminated with board mounted connectors (D-types, usb, terminals etc…).

Anyhow we wanted to get the new layout up early in order to get some more feedback, I’m sure their are lots of other questions so please ask away and let us know your thoughts.

Al