Amino Alpha

I have been very busy in the Folknology labs working through tens of different designs and boards as part of the Amino project. I am now at a point where I have a design for the first candidate Amino board – Amino Alpha. Below is an image of the boards layout, with highlighted I/O connectors, let me briefly show you around.

Amino Alpha


For communications we have full speed USB (480Mb/sec) and 10/100Bt Ethernet, the connectors for these can be seen to the north of the board. There is also a serial comms connector “C” to the left of the Ethernet RJ45, this houses dedicated UART and I2C pins. Also notice there is an optional MicroSD card slot underneath the mini USB connector facing northwards.


Interface “A” on the westside of the board provides a minimum 4 channel multiplexed analogue interface (we may add more channels here), based around a 10bit successive approximation ADC which is buffered over SPI, offering minimum conversion time of approximately 2.5 microseconds.


Alpha provides 2 high bandwidth nibble ports “B” and “D” to the south of the board, with channels capable of shifting up to 50MB/sec. Each port contains 4 1 bit bidirectional I/O pins and a single 4 bit bidirectional (nibble) channel. Together they provide effectively 16 bits of bidirectional I/O. In addition we have 3 further I/O pins which are currently uncommitted (we are currently reserving their use for more complex peripherals and a more modular expansion scheme), these sit between ports B and D along with some power and control pins.

External Debugging

To the west of the board lies interface J, providing a set of JTAG pins which can be used with Xtag or Xtag2 boards connected with only minor modifications/adaptors. This interface is used to debug the management and communication layer of the Amino stack and is not used for either regular participant space development or low level hardware layer development. Both of these development layers are debugged onboard without the need of an extra Jtag/Xtag adaptor. But obviously for ourselves and other alpha geeks this additional debug option is crucial. I will talk more about the layers in the Amino stack in a separate post later.


The main meat inside is obviously the brain and the nervous system made up of 2 XMOS XS1 L-64 chips. One of which (East) provides the nervous system, handles the low level I/O and Ethernet systems space, East is responsible for running low level layer 1 code which will conform to a modular service interface which unlike operating system drivers gets out of your way. The other (West) the brain, manages the entire Amino system including comms (TCP/IP,USB,Serial), memory and participant sketch/application space. The other chips handle lower level PHY, comms and ADC hardware.

I will be sharing the schematics over the next few days to provide more detail and feedback, in the meantime let me know your thoughts. I am still routing the boards so there may be some subtle changes before the first prototypes are made, but generally it should be very similar.

P.S. We are also considering a more robust industrial version which could add Canbus + CANopen, POE and grade 5 components for more harsh environments, if that’s of interest let me know.


17 thoughts on “Amino Alpha

  1. Hi Al,
    I was at the XMOS presentation last night. Unfortunately I had to dash off at the end so didn’t get a chance to talk. I considered a similar idea – a web based programming environment that resides on an ARM microcontroller.
    For the embedded language I thought eLUA looked interesting –

    I also found this presentation on the now defunct OOVM relevant: – though it’s not a browser based development environment, it allowed dynamically changing and debugging code in a running system.
    For a simple web based IDE alternative to Bespin you might consider something similar to Clamato:
    Hope this is interesting and look forward to meeting up another time
    Nick @nickager

  2. Thanks for the comment Nick and glad you enjoyed the talk.

    Clamato looks interesting, the small talk influence is fairly clear. In fact I hadn’t thought of going that route but It is an interesting possibility on a number of levels given Smalltalk’s original aims. The question would be if we could built a Jit for it on the back end. I will give this angle some thought as I really like the original Smalltalk concepts. Perhaps those ideas could be re-invented for the net generation of programmers.

    As for elua its already on my list

  3. Hi –

    I’m actually working with the eLua project, if you’re interested or have any questions please feel free to drop by our mailing list or get in touch with Bogdan, Dado or I directly. We don’t yet have a port on XMOS, and I’m not very familiar with development on the platform, but we certainly love to add hardware support.

    Lua runs quite well under constrained memory conditions, especially with a few tricks we use (and there are a few more up our sleeves to allow larger programs). eLua runs Lua on the bare metal, and we don’t currently use any threading, but with enough memory one could certainly run multiple Lua states or just have a single state farm out work to C-based threads.

    We very much like the idea of hosting development on the board as much as possible, and we also still haven’t found an ideal reference board 🙂

    1. Thanks for offering your help James at the momemnt I am concentrating on finalising the hardware to get the prototypes out. My next job is the essential layer 1 and 2 service architecture. WE will then add layers 3 and above including any self hosted languages.

      Now is a good time to start looking at all of the possibilities for the hosted runtimes and languages, I expect there may be more than one, and hope many can be developed.

      What kind of information do you need to assess an elua port to Amino?

      1. I suppose the first consideration would be figuring out what the port would look like to XMOS in general. Right now pretty much everything should work with any C99 compiler except for the hooks we use in newlib to allow some C standard library file I/O. If the C library used with the XMOS toolchain is different we’d need to adapt our current mechanisms to use similar mechanisms on XCore/Amino. It sounds like you plan to provide some APIs to abstract low-level I/O and peripheral control. C APIs would be preferable to C++ if this is the case. standard Lua is C89 which will compile as C or C++, but we use some C99-isms like designated initializers and flash being in the main address space to keep down SRAM usage, so it might add a little complexity to have C++ APIs.

        Beyond that, if there are any special considerations in developing for this architecture that differ significantly from ARM or AVR32, those might influence how well eLua/Lua might fit in. I’ve not developed on any XCore chips before so I’m not familiar with how the concurrency model works (scheduling, are they stackfull?), so that could influence what the best approach might be. Also, are you planning to have additional memory external to the two cores on the board or is it just the on-board 64kB of SRAM? Knowing any other specs would likely be useful too.

        If you’re looking at different dynamic languages to host, you’ll likely find that giving yourself more RAM will make life somewhat easier later. We put as much infrastructure as possible in C, and have deliberately made selections in constructing our platform interface to minimize RAM usage within the Lua VM to leave as much RAM as possible open to user programs. If you want to build any of your infrastructure on top of a dynamic language runtime, memory will make a huge difference.

      2. Ah, I have stumbled upon this:

        That answers some questions about feasibility of external RAM support, and some related searching answers some questions I was having about code stored in flash.

        I have no doubt that Lua will fit within the SRAM available on this device, but some of the tricks we’ve used on other platforms to keep resident SRAM usage down will not work in the same way here. We keep certain constant code and data in flash that wouldn’t appear to be directly possible here. For some of these things to work in an analogous way you’d have to write some sort of MMU to simulate this sort of behavior. I’m not sure how the resulting performance might compare with our existing ARM targets with something like this in place, but it would certainly be interesting to experiment with.

        Short of something like that I can think of a few other approaches to take, but I’m not sure what would work best without doing some testing. It seems like the XMOS tools come with a simulator, so perhaps I should play around with that a bit.

      3. Hi James

        Yes you will find the Xmos chips a little different, all flash is external normally connected ofver SPI rather than memory mapped so you will not be able to use it in the way you have with others. Probably one of the key features of the chips are their event processing model and concurrent hardware threads, I am not sure how you would use this feature in eLua but it is an important feature to support as it adds great power.

        regards Al

  4. Great work Al

    I love the tilted XMOS XS1 L-64’s

    I wish i had the energy and drive you have, or atleast seem to have 🙂
    I look forward to see and hearing more about the board, and also if Iin any way can contribute, let mee know.


  5. Distribute the clock signal to the module board ?

    Would it be possible to send the 13 MHz (USB & XMOS) clock signal on one of the free expansion pins ?
    (So the clock can be reused on a module, generating new clocks with a PLL or clock-syntesizer)

    1. Its approx 50 x 60mm, the reason for not being specific is that I am still routing and am leaving a little headroom.

      Alpha has 2 clocks on board a 13Mhz clock for East and the USB3318, nearest connection point is the JTAG edge, I could add a pin there perhaps. The second clock is 25Mhz for West, the LPC1111 and the LAN PHY. The nearest header for this is probably the comms header “C”. The 13mhz clock is also better buffered than the 25Mhz so would thus be a better choice between the two.

      I also need to explain how I envisage connecting modules, there are two concurrent ways, over the top (shield like) and extending to too the south via “B” & “D”.


    1. HI Mika

      I replied on the forum thread with a south facing suggestion that gives you more connection options let me know your thoughts.


  6. Hello Al,

    I’m happy to have stumbled upon this project! I’ve had my eyes peeled for a ‘game-changer’ open source dev. board for awhile – something like the Arduino, but with DSP capabilities and an eye toward concurrent paradigms. This looks like it! Plus you’re doing a whole bunch of other stuff right (like considering support for add-on hardware modules). I’m impressed that somebody is already basing an audio card around this platform, something I’d like to do myself.

    After dipping into data acquisition as primarily a media programmer, I have a suggestion for your project. Something that the Arduino doesn’t address is the issue of conditioning continuous data before it gets to the ADC. I’ve had the idea for awhile that it would not be difficult to create a module with an array of self-calibrating variable voltage dividers, PGAs and filters specifically for this purpose. Something easy to use, flexible and easily addressable from software. I know this is outside of your problem domain, but I think that making data acquisition accessible for people who lack the skills to spec and tune high precision analog circuits could be a big win. In my case, I’m working with conductive fabrics and plant sensing and I’d like to work experimentally rather than having to spec parts for requirements that are liable to change.

    1. Hi Morgan

      Thanks for your comments and agree Amino could change things dramatically given half a chance 😉

      Amino itself is a bigger project and I have literally tens of board designs I am whittling down based on different benefits and features. One of them for example provides both High speed differential ADCs (and DACs) as wells as PGA. Notice I haven’t added filtering, primarily because if the ADC is fast enough the filtering can actually be achieved digitally which has enormous benefits. Thus one just adds perhaps a roll off at input to lower HF noise. The board I’m referring to was actually being designed for motor control applications but I am rapidly coming to the conclusion that I should offer it as a generic DSP board as I have recently found a way to significantly reduces its BOM cost.

      Stay tuned for more..


      1. “One of them for example provides both High speed differential ADCs (and DACs) as wells as PGA. Notice I haven’t added filtering, primarily because if the ADC is fast enough the filtering can actually be achieved digitally which has enormous benefits. Thus one just adds perhaps a roll off at input to lower HF noise. The board I’m referring to was actually being designed for motor control applications but I am rapidly coming to the conclusion that I should offer it as a generic DSP board as I have recently found a way to significantly reduces its BOM cost.”

        Please do. One buyer here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s