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

Amino

I would like to outline some of the background to the Amino project and perhaps explain better what the project is about.

The Amino project isn’t a single product or board but rather an evolving series of designs made available for opensource and distributed production. Each basic design release will be versioned and or named. The basic design may be produced as is or in a customised format by anyone.

Amino came to be in order to fulfill a series of opensource production goals, hardware unlike software poses some obstacles for opensource production.

Amino groups together a number of concepts that we are working on around opensource hardware production. As outlined in an earlier Folknology post, opensource hardware poses a number of obstacles compared to opensource software.We can help reduce the friction of such hardware production, working around such hurdles and that is really what Amino is aiming to achieve, by putting some of these basic principles into action :

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 simply 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.

Lets tackle these one at a time..

Modularisation, we have been working on a bus suitable for use in small devices and embedded designs, this bus allows for modular peripheral cards to be slotted into a small microcontroller motherboard (microboard/µboard/uboard ?) to achieve the required functionality. The bus therefore enables a limited form of hardware modularisation to occur by design. Common peripheral card modules may be designed and reused as can the µboard itself. Composition of these modules can achieve more complex designs without lengthy construction. In essence construction is reduced to the bare minimum, just those parts that differentiate the project or task. Where bespoke build is required it should be possible by accessible technologies such as through hole rather than more complex smd. This allows a greater number of participants to innovate on top of the project.

Standaradisation is of course what enables the modularisation. By standardisation we mean standard opensource implementations with documented constraints, that is led by example and open for anyone to use, reuse or extend within the community. Standardisation by opensource implementation and constraint is led by problem solution rather than top down standard bodies or industry vendors stacking cards in there favor. Standardisation in this manor is designed to optimise open replication, essential for efficient distributed production.

Digitisation has been shown to be very successful in opensource hardware projects like Arduino with its standard shields/interface and opensource development based around wiring. Much of the innovation on Arduino is produced by its founders and community writing opensource software ideal for reproduction as it is again just digits with near zero replication costs. With Amino we intend building on this by offering (where possible) backward compatability with the Arduino Wiring and IDE. But we also intend to extend beyond this to a full build and debug chain based around GCC, OCD, Eclispe/Emacs to provide even higehr end functions such as inline debugging using the onboard JTAG and its powerful boundary scanning. In later Amino versions we will extend this further still using FPGA technologies to expand modularisation deep into the core of the designs. The first Amino design will be focussed around ARM Cortex M3 microcontrollers but we intend extending this range for even greater efficiencies and value across this category. Initially we will produce designs around the STM32 family of Cortex M3 microcontrollers as it provides a powerful and efficient base to begin with. I should restate here that the bus design is controller agnostic and as such could be implemented by any microcontroller with enough GPIO/SPI pins, from a software compatability point of view however there is a great deal more work involved in porting. Where possible we are trying to minimise this by leveraging work already existing in the opensource community.

Reuse is important to maximise use of any given component, it is also crucial to reducing the environmental impact of any hardware produced. If modules can be used in more than one situation it will save production of another. It also prolongs the life of any hardware and thus reduces disposal risks. modularisation also encourages reuse as does programability whether thats microcode,opcode or flashed logic in its various forms. Reuse is also a benefit to rapid prototyping and a move to more agile hardware production will require as much reuse as is feasible. Designing for mashup and hacking cultural norms is part of Amino’s makeup, its form isn’t final it has merely begun expressing itself, it is for others to take it further as far as they can imagine.

What is different about Amino from say the Adruino? First of all we are not interested in just making Yet Another Arduino With kNobs on (YAAWN) there are plenty of those already Beyond the principle goals 1 to 4 set out above, the Amino is biased toward production as well as prototyping and academia. The designs should be robust enough for both prototyping and small scale distributed production by dealing with build issues like replication, cabling, housing, cost reductions for small quantities, removal of connectors and direct soldering of modules as wells as modular PCB and schematic layouts promoting decomposition/recomposition.

What do we hope Amino will provide? well we would love it to enable more and more folks getting into Opensource Hardware to innovate and to do so openly and in a more rapid fashion. Great agility emerged from opensource software, we believe that opensource hardware will benefit in similar ways. We would like to see these designs and tools in the hands of the creative opensource communities producing innovative new hardware. We are imagining that folks will customise, change, mould and hack Amino designs into things that free their imagination, we sincerely hope a thousand hardware flowers will bloom.

We are also using Amino to experiment with Opensource distributed production and hope to provide further innovation and tools in this space and perhaps just help folks break out of the older vendor driven market places and prohibitive costs associated with its production, who knows maybe we can all reinvent a new hardware economy together, watch this space..

Welcome to Folknology Labs

Instead of filling the Folknology blog with discussions about all of the technology we are working on inside the Folknology Labs we decided to give it it’s own area dedicated to those conversations, ideas, updates and developments.

So expect a lot of OpenSource hardware and software within these posts and comments as well as more general discussions around OpenSource production and distribution.

Stick around it’s gonna be a lot of fun