LaForge's home page (Electronics Engineering)

First actual XMOS / XCORE project

Harald Welte — Fri, 01 Sep 2017 16:00:00 GMT

For many years I've been fascinated by the XMOS XCore architecture. It offers a surprisingly refreshing alternative virtually any other classic microcontroller architectures out there. However, despite reading a lot about it years ago, being fascinated by it, and even giving a short informal presentation about it once, I've so far never used it. Too much "real" work imposes a high barrier to spending time learning about new architectures, languages, toolchains and the like.

Introduction into XCore

Rather than having lots of fixed-purpose built-in "hard core" peripherals for interfaces such as SPI, I2C, I2S, etc. the XCore controllers have a combination of

I/O ports for 1/4/8/16/32 bit wide signals, with SERDES, FIFO, hardware strobe generation, etc
Clock blocks for using/dividing internal or external clocks
hardware multi-threading that presents 8 logical threads on each core
xCONNECT links that can be used to connect multiple processors over 2 or 5 wires per direction
channels as a means of communication (similar to sockets) between threads, whether on the same xCORE or a remote core via xCONNECT
an extended C (xC) programming language to make use of parallelism, channels and the I/O ports

In spirit, it is like a 21st century implementation of some of the concepts established first with Transputers.

My main interest in xMOS has been the flexibility that you get in implementing not-so-standard electronics interfaces. For regular I2C, UART, SPI, etc. there is of course no such need. But every so often one encounters some interface that's very rately found (like the output of an E1/T1 Line Interface Unit).

Also, quite often I run into use cases where it's simply impossible to find a microcontroller with a sufficient number of the related peripherals built-in. Try finding a microcontroller with 8 UARTs, for example. Or one with four different PCM/I2S interfaces, which all can run in different clock domains.

The existing options of solving such problems basically boil down to either implementing it in hard-wired logic (unrealistic, complex, expensive) or going to programmable logic with CPLD or FPGAs. While the latter is certainly also quite interesting, the learning curve is steep, the tools anything but easy to use and the synthesising time (and thus development cycles) long. Furthermore, your board design will be more complex as you have that FPGA/CPLD and a microcontroller, need to interface the two, etc (yes, in high-end use cases there's the Zynq, but I'm thinking of several orders of magnitude less complex designs).

Of course one can also take a "pure software" approach and go for high-speed bit-banging. There are some ARM SoCs that can toggle their pins. People have reported rates like 14 MHz being possible on a Raspberry Pi. However, when running a general-purpose OS in parallel, this kind of speed is hard to do reliably over long term, and the related software implementations are going to be anything but nice to write.

So the XCore is looking like a nice alternative for a lot of those use cases. Where you want a microcontroller with more programmability in terms of its I/O capabilities, but not go as far as to go full-on with FPGA/CPLD development in Verilog or VHDL.

My current use case

My current use case is to implement a board that can accept four independent PCM inputs (all in slave mode, i.e. clock provided by external master) and present them via USB to a host PC. The final goal is to have a board that can be combined with the sysmoQMOD and which can interface the PCM audio of four cellular modems concurrently.

While XMOS is quite strong in the Audio field and you can find existing examples and app notes for I2S and S/PDIF, I couldn't find any existing code for a PCM slave of the given requirements (short frame sync, 8kHz sample rate, 16bit samples, 2.048 MHz bit clock, MSB first).

I wanted to get a feeling how well one can implement the related PCM slave. In order to test the slave, I decided to develop the matching PCM master and run the two against each other. Despite having never written any code for XMOS before, nor having used any of the toolchain, I was able to implement the PCM master and PCM slave within something like ~6 hours, including simulation and verification. Sure, one can certainly do that in much less time, but only once you're familiar with the tools, programming environment, language, etc. I think it's not bad.

The biggest problem was that the clock phase for a clocked output port cannot be configured, i.e. the XCore insists on always clocking out a new bit at the falling edge, while my use case of course required the opposite: Clocking oout new signals at the rising edge. I had to use a second clock block to generate the inverted clock in order to achieve that goal.

Beyond that 4xPCM use case, I also have other ideas like finally putting the osmo-e1-xcvr to use by combining it with an XMOS device to build a portable E1-to-USB adapter. I have no clue if and when I'll find time for that, but if somebody wants to join in: Let me know!

The good parts

Documentation excellent

I found the various pieces of documentation extremely useful and very well written.

Fast progress

I was able to make fast progress in solving the first task using the XMOS / Xcore approach.

Soft Cores developed in public, with commit log

You can find plenty of soft cores that XMOS has been developing on github at https://github.com/xcore, including the full commit history.

This type of development is a big improvement over what most vendors of smaller microcontrollers like Atmel are doing (infrequent tar-ball code-drops without commit history). And in the case of the classic uC vendors, we're talking about drivers only. In the XMOS case it's about the entire logic of the peripheral!

You can for example see that for their I2C core, the very active commit history goes back to January 2011.

xSIM simulation extremely helpful

The xTIMEcomposer IDE (based on Eclipse) contains extensive tracing support and an extensible near cycle accurate simulator (xSIM). I've implemented a PCM mater and PCM slave in xC and was able to simulate the program while looking at the waveforms of the logic signals between those two.

The bad parts

Unfortunately, my extremely enthusiastic reception of XMOS has suffered quite a bit over time. Let me explain why:

Hard to get XCore chips

While the product portfolio on on the xMOS website looks extremely comprehensive, the vast majority of the parts is not available from stock at distributors. You won't even get samples, and lead times are 12 weeks (!). If you check at digikey, they have listed a total of 302 different XMOS controllers, but only 35 of them are in stock. USB capable are 15. With other distributors like Farnell it's even worse.

I've seen this with other semiconductor vendors before, but never to such a large extent. Sure, some packages/configurations are not standard products, but having only 11% of the portfolio actually available is pretty bad.

In such situations, where it's difficult to convince distributors to stock parts, it would be a good idea for XMOS to stock parts themselves and provide samples / low quantities directly. Not everyone is able to order large trays and/or capable to wait 12 weeks, especially during the R&D phase of a board.

Extremely limited number of single-bit ports

In the smaller / lower pin-count parts, like the XU[F]-208 series in QFN/LQFP-64, the number of usable, exposed single-bit ports is ridiculously low. Out of the total 33 I/O lines available, only 7 can be used as single-bit I/O ports. All other lines can only be used for 4-, 8-, or 16-bit ports. If you're dealing primarily with serial interfaces like I2C, SPI, I2S, UART/USART and the like, those parallel ports are of no use, and you have to go for a mechanically much larger part (like XU[F]-216 in TQFP-128) in order to have a decent number of single-bit ports exposed. Those parts also come with twice the number of cores, memory, etc- which you don't need for slow-speed serial interfaces...

Insufficient number of exposed xLINKs

The smaller parts like XU[F]-208 only have one xLINK exposed. Of what use is that? If you don't have at least two links available, you cannot daisy-chain them to each other, let alone build more complex structures like cubes (at least 3 xLINKs).

So once again you have to go to much larger packages, where you will not use 80% of the pins or resources, just to get the required number of xLINKs for interconnection.

Change to a non-FOSS License

XMOS deserved a lot of praise for releasing all their soft IP cores as Free / Open Source Software on github at https://github.com/xcore. The License has basically been a 3-clause BSD license. This was a good move, as it meant that anyone could create derivative versions, whether proprietary or FOSS, and there would be virtually no license incompatibilities with whatever code people wanted to write.

However, to my very big disappointment, more recently XMOS seems to have changed their policy on this. New soft cores (released at https://github.com/xmos as opposed to the old https://github.com/xcore) are made available under a non-free license. This license is nothing like BSD 3-clause license or any other Free Software or Open Source license. It restricts the license to use the code together with an XMOS product, requires the user to contribute fixes back to XMOS and contains references to importand export control. This license is incopatible with probably any FOSS license in existance, making it impossible to write FOSS code on XMOS while using any of the new soft cores released by XMOS.

But even beyond that license change, not even all code is provided in source code format anymore. The new USB library (lib_usb) is provided as binary-only library, for example.

If you know anyone at XMOS management or XMOS legal with whom I could raise this topic of license change when transitioning from older sc_* software to later lib_* code, I would appreciate this a lot.

Proprietary Compiler

While a lot of the toolchain and IDE is based on open source (Eclipse, LLVM, ...), the actual xC compiler is proprietary.

Upcoming v3 of Open Hardware miniPCIe WWAN modem USB breakout board

Harald Welte — Thu, 23 Mar 2017 16:00:00 GMT

Back in October 2016 I designed a small open hardware breakout board for WWAN modems in mPCIe form-factor. I was thinking some other people might be interested in this, and indeed, the first manufacturing batch is already sold out by now.

Instead of ordering more of the old (v2) design, I decided to do some improvements in the next version:

add mounting holes so the PCB can be mounted via M3 screws
add U.FL and SMA sockets, so the modems are connected via a short U.FL to U.FL cable, and external antennas or other RF components can be attached via SMA. This provides strain relief for the external antenna or cabling and avoids tearing off any of the current loose U.FL to SMA pigtails
flip the SIM slot to the top side of the PCB, so it can be accessed even after mounting the board to some base plate or enclosure via the mounting holes
more meaningful labeling of the silk screen, including the purpose of the jumpers and the input voltage.

A software rendering of the resulting v3 PCB design files that I just sent for production looks like this:

Like before, the design of the board (including schematics and PCB layout design files) is available as open hardware under CC-BY-SA license terms. For more information see http://osmocom.org/projects/mpcie-breakout/wiki

It will take some expected three weeks until I'll see the first assembled boards.

I'm also planning to do a M.2 / NGFF version of it, but haven't found the time to get around doing it so far.

Autodesk: How to lose loyal EAGLE customers

Harald Welte — Sun, 22 Jan 2017 16:00:00 GMT

A few days ago, Autodesk has announecd that the popular EAGLE electronics design automation (EDA) software is moving to a subscription based model.

When previously you paid once for a license and could use that version/license as long as you wanted, there now is a monthly subscription fee. Once you stop paying, you loose the right to use the software. Welcome to the brave new world.

I have remotely observed this subscription model as a general trend in the proprietary software universe. So far it hasn't affected me at all, as the only two proprietary applications I use on a regular basis during the last decade are IDA and EAGLE.

I already have ethical issues with using non-free software, but those two cases have been the exceptions, in order to get to the productivity required by the job. While I can somehow convince my consciousness in those two cases that it's OK - using software under a subscription model is completely out of the question, period. Not only would I end up paying for the rest of my professional career in order to be able to open and maintain old design files, but I would also have to accept software that "calls home" and has "remote kill" features. This is clearly not something I would ever want to use on any of my computers. Also, I don't want software to be associated with any account, and it's not the bloody business of the software maker to know when and where I use my software.

For me - and I hope for many, many other EAGLE users - this move is utterly unacceptable and certainly marks the end of any business between the EAGLE makers and myself and/or my companies. I will happily use my current "old-style" EAGLE 7.x licenses for the near future, and theS see what kind of improvements I would need to contribute to KiCAD or other FOSS EDA software in order to eventually migrate to those.

As expected, this doesn't only upset me, but many other customers, some of whom have been loyal to using EAGLE for many years if not decades, back to the DOS version. This is reflected by some media reports (like this one at hackaday or user posts at element14.com or eaglecentral.ca who are similarly critical of this move.

Rest in Peace, EAGLE. I hope Autodesk gets what they deserve: A new influx of migrations away from EAGLE into the direction of Open Source EDA software like KiCAD.

In fact, the more I think about it, I'm actually very much inclined to work on good FOSS migration tools / converters - not only for my own use, but to help more people move away from EAGLE. It's not that I don't have enough projects at my hand already, but at least I'm motivated to do something about this betrayal by Autodesk. Let's see what (if any) will come out of this.

So let's see it that way: What Autodesk is doing is raising the level off pain of using EAGLE so high that more people will use and contribute FOSS EDA software. And that is actually a good thing!

Open Hardware IEEE 802.15.4 adapter "ATUSB" available again

Harald Welte — Tue, 06 Dec 2016 17:00:00 GMT

Many years ago, in the aftermath of Openmoko shutting down, fellow former Linux kernel hacker Werner Almesberger was working on an IEEE 802.15.4 (WPAN) adapter for the Ben Nanonote.

As a spin-off to that, the ATUSB device was designed: A general-purpose open hardware (and FOSS firmware + driver) IEEE 802.15.4 adapter that can be plugged into any USB port.

This adapter has received a mainline Linux kernel driver written by Werner Almesberger and Stefan Schmidt, which was eventually merged into mainline Linux in May 2015 (kernel v4.2 and later).

Earlier in 2016, Stefan Schmidt (the current ATUSB Linux driver maintainer) approached me about the situation that ATUSB hardware was frequently asked for, but currently unavailable in its physical/manufactured form. As we run a shop with smaller electronics items for the wider Osmocom community at sysmocom, and we also frequently deal with contract manufacturers for low-volume electronics like the SIMtrace device anyway, it was easy to say "yes, we'll do it".

As a result, ready-built, programmed and tested ATUSB devices are now finally available from the sysmocom webshop

Note: I was never involved with the development of the ATUSB hardware, firmware or driver software at any point in time. All credits go to Werner, Stefan and other contributors around ATUSB.

Open Hardware miniPCIe WWAN modem USB breakout board released

Harald Welte — Thu, 24 Nov 2016 16:00:00 GMT

There are plenty of cellular modems on the market in the mPCIe form factor.

Playing with such modems is reasonably easy, you can simply insert them in a mPCIe slot of a laptop or an embedded device (soekris, pc-engines or the like).

However, many of those modems actually export interesting signals like digital PCM audio or UART ports on some of the mPCIe pins, both in standard and in non-standard ways. Those signals are inaccessible in those embedded devices or in your laptop.

So I built a small break-out board which performs the basic function of exposing the mPCIe USB signals on a USB mini-B socket, providing power supply to the mPCIe modem, offering a SIM card slot at the bottom, and exposing all additional pins of the mPCIe header on a standard 2.54mm pitch header for further experimentation.

The design of the board (including schematics and PCB layout design files) is available as open hardware under CC-BY-SA license terms. For more information see http://osmocom.org/projects/mpcie-breakout/wiki

If you don't want to build your own board, fully assembled and tested boards are available from http://shop.sysmocom.de/products/minipcie-wwan-modem-usb-break-out-board

Open Hardware Multi-Voltage USB UART board released

Harald Welte — Thu, 24 Nov 2016 16:00:00 GMT

During the past 16 years I have been playing a lot with a variety of embedded devices.

One of the most important tasks for debugging or analyzing embedded devices is usually to get access to the serial console on the UART of the device. That UART is often exposed at whatever logic level the main CPU/SOC/uC is running on. For 5V and 3.3V that is easy, but for ever more and more unusual voltages I always had to build a custom cable or a custom level shifter.

In 2016, I finally couldn't resist any longer and built a multi-voltage USB UART adapter.

This board exposes two UARTs at a user-selectable voltage of 1.8, 2.3, 2.5, 2.8, 3.0 or 3.3V. It can also use whatever other logic voltage between 1.8 and 3.3V, if it can source a reference of that voltage from the target embedded board.

Rather than just building one for myself, I released the design as open hardware under CC-BY-SA license terms. Full schematics + PCB layout design files are available. For more information see http://osmocom.org/projects/mv-uart/wiki

In case you don't want to build it from scratch, ready-made machine assembled boards are also made available from http://shop.sysmocom.de/products/multi-voltage-usb-dual-uart

First month of running the openmoko.org USB Product ID registry

Harald Welte — Wed, 20 Jun 2012 19:00:00 GMT

One month ago, I had announced the availability of USB Product IDs under the Openmoko USB Vendor ID. By now, there have been 37 registrations, and the List of assigned USB Product IDs in the openmoko.org wiki is turning into something like a directory of really cool projects with Open Hardware or at least Free Software device firmware.

So actually, I enjoy a lot seeing so much activity in this field, and being able to contribute a tiny bit by enabling people to get a unique USB Product ID that they can use.

Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the community

Harald Welte — Sun, 20 May 2012 19:00:00 GMT

As it has been quite some time since Openmoko, Inc. (the company) has released any hardware, I have obtained the permission to "donate" the Openmoko-assigned USB Product ID and IEEE OUI (MAC Address) allocations to the community.

As the actual allocations cannot be transferred unless the registrant (Openmoko. Inc.) is sold, the official registration will remain with Openmoko Inc. while the various Free / Open Source Software and hardware communities can make use of the range.

Registering a USB Vendor ID is expensive (USD 2000), and even if it wasn't for the money, many companies (let even aside community projects) will never require the 65535 product IDs allocated within that one USB Vendor ID.

As for Ethernet/Wifi/Bluetooth MAC addresses, they are allocated from the IEE OUI number ranges, which are also quite expensive (USD 1600) - but at least you get 16.7 million (24bit) and not just 16bit like USB ;)

So if you are running a small homebrew or community built project that implements a USB device or Ethernet ports, and either the software or the hardware of it is available under a free software / open source license, you can follow the instructions given at the pages in the Openmoko wiki that I linked above and request an allocation.

I'd like to thank Openmoko Inc. and especially Sean Moss-Pultz for making this donation.

Name that UART: April 2012

Harald Welte — Sun, 08 Apr 2012 19:00:00 GMT

It's sort of a cheap knock-off idea stolen from the Name that Ware on bunnies blog: I'm going to post one picture every month about a UART that I found on embedded hardware. Unfortunately I don't have much to offer in terms of a reward for whoever finds the true solution ;)

In any case, every month there are devices that I'm looking into either out of my own interest, or because the work at gpl-violations.org requires it. In most of them, you can find a UART to get to the u-boot / Linux serial console.

So here is the device that I just took apart earlier today:

The location of the UART pads was obvious, after looking at the PCB for a very short time. The entire unpopulated U1 footprint appeared suspiciously like a UART level shifter for true RS232 voltage levels:

You can see two signals going directly to a small unpopualted3-pin header
There are two other signals coming from somewhere under the main SoC
There are capacitors (C440, C441) directly connected to the U1 for the charge pump

OsmoSDR status update

Harald Welte — Thu, 01 Mar 2012 19:00:00 GMT

It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at that time, there was no FPGA code yet, and some hardware bugs still had to be resolved. Nonetheless, the e4k tuner driver could already be implemented and tuning was confirmed by looking at the analog i/q spectrum.

Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL code written by maintech.de. Ever since that, they dropped the ball again with me as I had been careless enough to volunteer for writing the firmware.

And that's what I did or at least tried to do for quite some time during the last two weeks. The main problem was that I didn't have much time. The second problem was that I never was able to get the SSC (synchronous serial controller) receive DMA working.

This was a really odd experience, as I've worked a lot with that very same SSC peripheral before, while writing firmware for the OpenPICC some 6 years ago. However, this was in an at91sam7s, where the SSC is interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller, capable of scatter-gather DMA and other fancy stuff.

Atmel has provided reference code that uses the SSC DMA in transmit mode (for a USB audio device playing back music via the Wolfson codec on the SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I set out to write code for DMA-based SSC receiver. And it never worked.

I actually wrote two independent implementations, one from scratch and the other based on Atmel reference code. Neither of them worked. It seemed to be a problem with the hardware hand-shaking between SSC and DMAC. The SSC was successfully receiving data, and that data could be read out from the CPU using a polling or IRQ based driver. But if you're running at something like 32 Mbps and don't have a FIFO, you desperately want to use DMA. When the DMA handshaking was turned off, the DMA code worked, but of course it read the same received word several thousand times before the next data arrived on the SSC.

In the end, I was actually convinced it must be a silicon bug. Until I thought well, maybe they just connected the flow controller to a different ID in Rx and Tx direction. Since there are only 16 such identifiers, it was relatively easy to brute-force all of them and see if it worked. And voila - using the identifier 4, it worked!

So what had happened? The Atmel-provided reference code contained a

 #define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3

and that was wrong. 3 is valid for SSC TX but not for SSC RX. Unfortunately I never found any of those magic numbers in the SAM3U manual either. They are not documented in the chapter of the SSC, and they are not documented in the chapter about HDMA/DMAC either. And they are not identical with the Peripheral Identifiers that are used all over the chip for the built-in peripherals.

In case anyone else is interested, a patch can be found at my at91lib git repository.

I filed a ticket with Atmel support, and they pointed out in fact there was a table with those identifiers somewhere in the early introductory chapters where you can see a brief summary of the features of each integrated peripheral. Unfortunately they use slightly different naming in that chapter and in the DMAC, so a full-text search also didn't find them. Neither is that table visible in the PDF index.

So about four man-days later it was finally working. Another day was spent on integrating it with the USB DMA for sending high-speed isochronous transfers over the bus into the PC. And ever since I'm happily receiving something like 500,000 or 1,000,000 samples / second from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or Windows, the Linux audio drivers don't make arbitrary restrictions in the sample rate. According to the USB Audio spec, the sample rate can be any 24bit number. So audio devices with 16.7 Ms/s are very much within the spec. I hope some of the other OS driver writers would take that to their heart.

One of the first captures can be found at this link, containing a bzip2ed wave file in S16LE format Stereo (I/Q). It contains a FM audio signal transmitted using a small pocket-sized FM transmitter.

There is no I/Q DC offset calibration yet, but once that is done we're probably able to finally put the design into production.

First osmo-nvs-gps evaluation boards soldered

Harald Welte — Tue, 24 Jan 2012 19:00:00 GMT

At the osmocom project, we recently discovered the most interesting NVS NV08C-CSM module. It not only is a superb GPS receiver, but it includes GALILEO and GLONASS receivers, too. However, it's only available as an industry module, or as an expensive (700 EUR or so) evaluation kit.

Given the cheap PCB prototyping service at seeedstudio, I thought I'd spend an afternoon creating the schematics and PCB layout for an evaluation board. It exports the two 3.3V UARTs on OsmocomBB-style 2.5mm jacks, so they can be used with the T191 cables. I have the feeling this 2.5mm jack is becoming a new standard for low-voltage RS232 links ;)

Furthermore, it exports the SPI, I/O and I2C on a 20pin 2.54mm pitch header, connects to an external antenna via a MCX socket and has an optional footprint for a CR2032 battery on the bottom side.

So far, the board seems to be working fine. If there is interest in the bare PCB itself (without components!), please send me an e-mail. Depending on the amount of interest we might add it to the sysmocom webshop.

Schematics and Gerber files will be available at http://openbsc.osmocom.org/trac/wiki/osmo-nvs-gps soon.

First assembled prototypes of osmo-e1-xcvr

Harald Welte — Fri, 13 Jan 2012 19:00:00 GMT

I mentioned it briefly before: I've designed a small E1/T1/J1 transceiver board, which is going to be used for experimentally interfacing such a TDM line with microcontroller and/or FPGA. The name of this board is osmo-e1-xcvr.

The first prototype PCBs have arrived yesterday, and despite lots of other more important work I couldn't resist but to actually solder some of the units. The result can be seen here:

I don't have time to do anything beyond very basic testing right now, but so far the boards seem to be doing fine. Now we need a driver for the transceiver chip, and connect its control interface over SPI to some microcontroller (likely sam7s/sam3s/sam3u in my case). The actual serial bitstream will end up at the SSC peripheral of the controller.

OsmoSDR status update

Harald Welte — Mon, 09 Jan 2012 19:00:00 GMT

It's already two weeks since my last post mentioning OsmoSDR only very briefly. By now, OsmoSDR is fully public and you can read all about it on the http://sdr.osmocom.org/ website.

Specifically, the website includes Schematics, and one of my colorful block diagrams. I am a text guy and really hate to work with graphics, but the block diagram of the Calypso has helped a lot in the context of making people understand OsmocomBB, so I tried again for OsmoSDR:

So as you can see, it is a very simple, straight-forward design with a chip tuner, direct I/Q down-conversion, ADC for differential I and Q signals as well as a small FPGA for basic filtering and serial format conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high speed USB).

And yes, it's receive only. However, it has a stacking connector for later addition of a transmit daughter-board which may eventually follow later in 2012.

So what is this OsmoSDR going to be used for? Well, for receiving any kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz, untested). We don't build it for a specific application, but we simply thought that for many applications a member of the USRP family is expensive overkill, and the FCDP has this arbitrary restriction at 96 kHz sampling frequency.

Please note that while I may be the only OsmoSDR developer that blogs about this project, it is very much a team effort and I'm only a minor part of that team. Apart from selecting the SAM3U, writing firmware and drivers for it as well as some discussions early on in the project, I didn't have any involvement in the Hardware design. Those credits go to Christian Daniel and Stefan Reimann.

So where do we stand? There are 5 prototypes of the first generation, they look like this:

There are some smaller hardware issues that were easy to work around, but one bigger problem related to the fact that the Si570 programmable oscillator output levels didn't match quite with what the FPGA clock input requires.

There will be a second generation board fixing this and other problems, and hopefully we'll see some progress in the weeks to come.

Firmware-wise, the code is currently scattered over a couple of different repositories, but I'm going to consolidate that soon. If you've worked with OpenPCD or SIMtrace, you will find some similarities: We split the flash of the controller into two partitions: One for the DFU bootloader, and one for the application code. You can then use the USB DFU (Device Firmware Upgrade) standard to quickly update the actual firmware of the device, without having to resort to jumpers or un-plugging and re-plugging of the hardware.

This also meant that I had to re-implement the old sam7dfu code for the SAM3U, which has considerable differences in the USB peripheral, cpu core, board startup code, etc. So it's really a reimplementation than a port. The good news is that I tried to make it as general as possible and integrate it with at91lib, Atmels reference code. So it should be easier to use it with other Atmel SoCs like the sam3s which I want to use e.g. in SIMtrace v2.

More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bank

Harald Welte — Thu, 22 Dec 2011 19:00:00 GMT

I'm currently quite excited to be doing more bare iron programming as well as actual electrical engineering work again.

There's actually not just one project I'm working on, but a variety of them:

OsmoSDR - an upcoming small form-factor, inexpensive USB SDR. Not big and expensive like USRP or real "professional" solutions, but also not as weak as the ultra-narrow-band funcube dongle. I wasn't involved in the hardware design, but have volunteered to take care of the firmware development for the Atmel SAM3U micro-controller inside.
osmo-e1-xcvr - a relatively simple circuit board containing the magnetics, LIU, clock generation and transceiver for E1/T1/J1 lines. The idea here is to have a solution for the analog part, as well as HDB3/B8ZS/AMI encoding, which can then be attached to any FPGA, CPLD or micro-controller development board. It exposes SPI for controlling the transceiver, and a synchronous serial bit-stream for Rx and Tx.
unnamed sim-bank project - here the goal is to find a cheap solution to attach a large number of SIM cards to either a PC or directly to Ethernet. This can be very useful for testing, where you host your sim cards in a centralized location and can borrow them to remote users/devices over TCP/IP. There are commercial devices available for this, but they are quite expensive (like 1700 USD for 32 card device) and intended to be used with some proprietary windows software (who wants that?!?).

In the latter two projects I'm also doing the component selection, schematics design and PCB layout. One project with KiCAD, the other in EAGLE, as I really want to get first-hand experience of the usability of Free vs. proprietary EDA tools. I'd love to also evaluate Altium Designer, but they are still windows-only, and that would just make life way too difficult for me.

The projects will be duly announced soon, and they are all intended to be Open Hardware designs with Free Software. We'll probably also make all of them available at shop.sysmocom.de, too.

Facebook "Open Compute Project" nothing but hot air

Harald Welte — Fri, 08 Apr 2011 19:00:00 GMT

There has been a lot of fuzz about facebook's Open Compute Project, and it seems to originate mostly from journalists without much technical skill.

Did anyone actually bother to check what they released? You can find mechanical designs and simple specification data sheets. More or less every vendor is publishing that kind of information, or at least there are common form factors that are specified (like ATX, eATX, mini-ITX, ...)

It is sad to hear that they are 'openwashing' themselves (like BP is greenwashing itself). Specifically, the following portions are not "open":

Any type of electrical schematics (mainboards, power supply, ...)
Any type of detailed data sheets or programming manuals on the electronic components used
Gerber files of the PCBs

So what this really is all about is: Facebook advertising this is our new mechanical form factor, now we want all of you to adopt it, so we can buy cheaper hardware.

Go home, facebook. Come back if you have something _really_ open.

Wide-screen sucks for heavy terminal users

Harald Welte — Fri, 28 Aug 2009 19:00:00 GMT

I've always been complaining loudly about wide-screen displays. 4:3 is much better for those of us who mainly work with xterms of 80 characters width (due to e.g. kernel coding style and e-mail conventions). The additional width is typically not enough for having three terminal windows next to each other, but the lacking height means way less visible lines of code.

This is why I'm still using my Panasonic CF-R5 (10.2" 1024x768 sub-notebook) from 2006. Despite it almost falling apart on all sides after three years of most intensive daily use, despite it feeling slower than any Atom based netbook that I've used.

So despite having tried an ideapad S9e, a HP mininote 2133, I can only deem them unusable for any serious without an external display.

Right now I'm desperately looking for a device that can be the successor for the CF-R5. I don't need much computing power, a Atom N270 would be the minimum but would work. I am happy with narrow keyboards as I'm using one for 3 years every day. I don't need tons of memory as I'm not using any bloated graphical desktop (just ion+uxterm). All I care about is Intel integrated graphics, a small device, ideally 10", with at least 768 pixels height.

It seems there are now 1366x768 based 10" netbooks, but all you can find is nVidia based Samsung devices, which are obviously completely unsuitable for, considering nVidia treats the FOSS community like crap.

I've spent half the day in Seoul's Yeoksam Electronics Market. The only thing that would remotely resemble my requirements is the ASUS eeePC 1101HA. But it's 11.6" wide screen, which makes the device considerably wider/larger than the CF-R5. Plus, the maximum memory configuration is 2G.

The other options is to buy a CF-R8. Still 4:3 ratio, almost the same size as the CF-R5. If only Panasonic was selling them outside the US. Yes, I know you can mail order them. But I'd love to have a look and try it before spending at least 1500 EUR on it.

So the Notebook industry still fails to impress me. Noisy (with fan) devices with ever wider screens. Apparently ignoring the fact that there are people who can imagine more interesting things to do with their computer than to play movies.

Embedded Projects Journal

Harald Welte — Tue, 28 Jul 2009 19:00:00 GMT

As it seems, for about one year there has been a new Embedded Projects Journal (in German). This magazine focuses entirely on FOSS embedded projects and open hardware. The idea is to have a magazine written by the community for the community. Plus, the magazine and all its articles are freely redistributable.

It's a pity that I've only noticed about this now. Let's hope more people learn about it, now that I'm mentioning it here.

If you want to contribute, feel free to contact the journal's makers.

Why do all those netbook need to have fans?

Harald Welte — Fri, 16 Jan 2009 19:00:00 GMT

This is a question that I've been asking myself ever since the first eeePC was released. Sure, there are other problems like bad keyboards and mechanical design (with the exception of the HP mininotes) and too small / low-res displays. But the question that bothers me most is: Why do those supposedly-so-power-saving new processors still need a fan in those systems?

I am the happy owner of a Panasonic Let's Note CF-R5. It was bought in September 2006, where it was already end-of-life. It does not have nor need a fan, the Intel U1300 (1.06GHz) CPU and the Intel IGP chipset are doing quite fine without it. So why are the supposedly less power-consuming later systems like Intel Atom built with fans? It's really annoying to me. I don't want this kind of noisy design. It sucks. It is a clear sign of bad engineering.

So far, the only replacement for the CF-R5 that I would consider is a CF-R7 or CF-R8. A netbook faster than the CF-R5 without fan could make me reconsider.

Photographs of disassembly and PCB of a e-ten glofiish X800

Harald Welte — Fri, 29 Aug 2008 19:00:00 GMT

Heh. You could say I'm now among other things a professional hardware reverse engineer. This mostly started as a kid, where I always had to take everything apart. In more recent years, I've mostly been doing hardware reverse engineering as part of the gpl-violations.org effort, or projects like openezx.osmocom.org.

Now, I've actually been asked by a company to buy a device on their expense to disassemble and photograph it, to find out about the components it uses, etc. And no, before you start to wonder, I don't work for Openmoko anymore. So they are not that company ;)

The device in question is the E-TEN glofiish X800, a full-vga 3.5G Windows Mobile PDA-Phone with AGPS, Wifi and bluetooth. You can find the pictures of the disassembly process and PCB photographs here.

As you can see, the device employs the following major components / chipsets:

Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)
CSR4 based Bluetooth (same like Openmoko and many other devices)
microSD slot, must be connected to S3C2442 SD/MMC controller
WiFi Module using a Marvell 8686 chipset (you actually can't see that, I had to peel open the shielding of the module and the angle didn't allow any good photographs)
TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02
AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal
Two cameras of unknown type, must be using the S3C2442 camera interface
Ericsson based quad-band GSM and tri-band 3.5G chipset centered around the DB3150, which is used in many Sony-Ericcson 3G/3.5G phones. Sony-Ericsson has excellent public documentation on their AT-commandset for their phones. Since they are likely to use the same firmware base, the AT commandset should thus be known.
A Xilinx CPLD

So now what does all this mean? Setting aside the CPLD and the unknown camera modules, this device (and its keyboard-enabled brother the M800) should be a very attractive target for porting Linux to it. Known SoC, wifi with driver already in mainline, GSM/3.5G modem with documented AT commands, etc.

Big question is the power management. It looks like they're using a lot of discrete regulators rather than an integrated PMU. Also, the CPLD is likely to cause a lot of trouble since neither the external connection nor the internal logic is known...

Schiphol airport uses active millimeter wave screening

Harald Welte — Wed, 26 Mar 2008 19:00:00 GMT

I was quite surprised that Amsterdam airport is beginning to introduce active millimeter wave screening instead of the good old metal detectors. The specific device seen in operation at one of the queues between the international and the Schengen area of the airport was L3 Communications ProVision(TM).

While doing some research about this subject on the net, I discovered cargo X-ray solutions such as those described in this article. You can mount a mobile unit onto a track and then go as deep as 200mm of steel to x-ray through the metal plating of a cargo container. This is really scary stuff...

Repairing VIA EPIA-ME6000 busted capacitors

Harald Welte — Wed, 02 Jan 2008 19:00:00 GMT

Just before Christmas, my vdr powered diskless Linux-based digital video recorder went bust. A bit of testing revealed that the VIA EPIA-ME6000 main board itself must be dead.

I immediately ordered a replacement mini-ITX board without further investigating the broken one, expecting that the replacement might actually arrive before the Christmas holidays. Unfortunately this didn't happen. While replacing the board, I discovered that six of the 1000uF electrolytic capacitors went bust.

So today I finally found a bit of time (it's great to be able to find time to do things again) to try and replace the broken capacitors. Despite the new ones being slightly larger, the board now works again like a charm. And that at a total cost of 1.62 EUR.

So now I have two working mini-ITX boards. Guess I have to either find some use for it, or sell the new one again...

Petition against obnoxious WEEE implementation in Germany

Harald Welte — Sun, 03 Dec 2006 19:00:00 GMT

There is now an official Petition to re-work the obnoxious WEEE implementation in Germany (see my detailed posting earlier in this blog. This is good, and definitely a step forward in getting regulations in place which are supportive of small and medium-sized companies, rather them getting them out of business. I've spoken to lawyers about the current regulations, and they e.g. have severe doubt that they are even constitutional.

If you are German, and/or operate a business in Germany, please consider signing the above-mentioned petition!

btw: I'm planning to start a petition against hosting petitions of the German Bundestag at a University in the UK, anybody interested in joining it?

Obnoxious RoHS/WEEE rules and their German implementation

Harald Welte — Sun, 01 Oct 2006 19:00:00 GMT

You might have heard about RoHS (Reduction of Hazardous Substances) before. I always thought it is a well-meant and important contribution of the European Union to reduce the amount of hazardous substances in electronic waste. As a supporter of many environmental groups, and an occasional voter for the Green party, I definitely support such a goal.

If I was to manufacture electronic equipment, then certainly I would consider it as my moral duty to pay for the cost of processing ('recycling', how they call it, if that was ever possible)the resulting waste. No debate on that at all.

Now I actually am involved with producing small quantities of electronic equipment, and suddenly those issues come up again. The product obviously only uses RoHS compliant components, no question on that. We do want to reduce the environmental impact, after all.

Now enter EU and German bureaucracy, combined with lobbying of large industrial electronics manufacturers, and you end up with the German implementation called "ElektroG" (Gesetz ueber das Inverkehrbringen, die Ruecknahme und die umweltfreundliche Entsorgung von Elektro- und Elektronikgeraeten [Law about distribution, withdrawal and eco-friendly disposal of electrical and electronic devices]). That law basically regulates and delegates the administration of the RoHS/WEEE guidelines to an authority called EAR (Stiftung Elektro-Altgeraete Register [Foundation for Registry of Electrical Devices]).

The way how this system works is:

All manufacturers and importers have to register themselves with EAR
They also have to register the quantity (weight) of produced/imported goods every month
They furthermore have to produce proof of having made a deposit on the amount of money required to "recycle" the resulting electronic waste, even in the case of bankruptcy of the producer/importer

This all sounds very reasonable and well-thought. Given the facts stated until here, I would still be an avid supporter of such a system.

Now enter the disaster: The minimum quantity that this system can deal with is the metric ton. This is very suitable for large manufacturers, but what about a small company that produces 100 units of 180grams of weight every year? It will take more than 55 years to fill up that metric ton. Now, if they actually allowed you to pay for one ton every 55 years, then that would be great. Obviously, they don't. Rather they employ an undisclosed lottery algorithm, which elects one registered producer/importer who has to take care of recycling one specific container that was filled last at the electronics waste collection station. Yes, every time one container is filled, they elect another lucky lottery winner. And in order to make sure that every possible "winner" could actually afford the disposal of that container, EAR has the "proof of bankruptcy-safe deposit".

You might think: Well, quite a fancy system, but assuming that algorithm was tuned right, there still is no problem, even for small producers, since the probability of them being chosen by the lottery is very low. And in fact it is. An EAR person has publicly stated in an interview that only producers having produced more than 3.5 metric tons of electronics are eligible to win that lottery. Great, since in our example that would be in 194 years. Son nothing to worry about, right?

Wrong. The administrative fees of EAR.

155 EUR one-time fee for registration is still quite acceptable.
85 EUR per product that is put on the market is fine, too.
100 EUR for each notice of change in production quantity is a bit steep, given the inevitable flux of that figure.
455 EUR for the validation of the proof of having made the deposit
215 EUR annually for the re-validation of the proof of having made the deposit

Now what kind of bull**it is this? This means that during those 55 years we would fill one metric ton, we'd have to pay 12066 EUR only in administrative fees for validation and re-validation of the bankruptcy-save deposit? All that for the disposal of one ton of electronic waste, which costs [now] between 200 and 400EUR ?

I would be very surprised if such fees would not violate anti competition rules of the EU somewhere at some point. This is the creation of a serious market entrance barrier for small manufacturers of electronic equipment and nothing else.

OpenPCD press release, online shop

Harald Welte — Sun, 24 Sep 2006 19:00:00 GMT

Ok, after a painful day full of shippin rates, insurance, taxation issues, etc. Milosch finally worked out how to ship our product to about any country of the wokld. This means that the OpenPCD shop is now online, and we're accepting orders from those people who don't want to fabricate the four-layer PCB themselves ;)

We also sent out the Press Release, in the hope that some press actually might be interested in free hardware project.

On OpenPCD.org we now also published the first binary firmware images (source code has always been in svn), including full USB DFU (device firmware upgrade) support.

If I manage to resolve some of the problems I still have with the SAM7 SSC controller, then the PICC simulator should also get working some time soon.

Visiting armzone.com in Shanghai

Harald Welte — Wed, 05 Jul 2006 19:00:00 GMT

Today I had the pleasure of visiting armzone.com in Shanghai. Now if that was like visiting any other hardware or electronics store, I wouldn't be blogging about it. It might actually be that visiting any shop like this in China is a similar experience. But I'll write it anyway, you don't have to read it.

So we were there to buy some S3C2410 based development boards (full-featured, basically PDA development boards, including 65MB SDRAM, 64MB NAND Flash, Ethernet, USB host and device, a CPLD, IDE, 2xSerial, JTAG, SD-Card, ..). The first thing to notice was the price. Including a touch screen LCD panel they were something like USD 180 each. Actually less than any PDA based on them would cost in the western world. Aren't devel boards usually at least one order of magnitude more expensive than the actual systems you're going to design with them?

Then we were looking for some JTAG adaptor compatible with that devel board. The boards ship with a wiggler, which is supported by OpenOCD and also some s3c2410 version of JFlash, but which is slow as hell. Sort of the least interesting option. They had a number of USB and parallel port models available, some of them clones of well-known modules such as MultiICE, some others being developed by themselves.

The main problem was that they all seem to require some RDI server to run on a windows box. Hey, If I'm doing Linux target development on a Linux host system, they ask me to run a windows box just for that daemon? They must be kidding me. So my Chinese contacts engaged in some almost two hour debate on whether he couldn't release the source code to their own RDI server so I can port/re-implement that code on Linux, and why it might be a benefit to them to get that Linux version back to ship with further products. The debate also seems to have included all kinds of other options. Going as far as to the shop wanting to sell us a Raven compatible device, to which we almost agreed, only to learn that he needs a week to produce some more apart from the engineering sample.

One other thing we'd need for the parallel port versions is a PCMCIA parport card. Yes, such things actually exist, and you can buy them even on some Chinese eBay like site whose name I forgot. Rather than buying that, armzone offered us to wait two weeks, until then they will have built (!) their own parport adaptor for only a part of the price. Yes, they would have gone all the way down to molding a case for the parport connector sticking out of PCMCIA, etc. And that for us buying a max of 5 of those cards. Hey, we're talking about electronics / PCB / case design here, not about whether I want ketchup with my french fries!

This seriously made me wonder whether when you buy a car in China they also ask you if they should be personally just for you build a different car radio from scratch. These guys are crazy...

Ridiculous fees for USB Vendor ID

Harald Welte — Sun, 25 Jun 2006 19:00:00 GMT

Sometimes you happen to find yourself starting a DIY electronics project, much like a Free Software project. And if that hardware is actually to be plugged into one of the standard interfaces such as the various PCI variants, or USB, then you'll need to give it a USB Vendor and Device ID. Vendor ID's are 16bit, and allocated by the USB Implementers Forum (IF).

Unfortunately, applying for a Vendor ID costs you USD 2,000. Yes, two-thousand bucks US for creating an entry in a table. This might be peanuts for large hardware companies, but it's an awfully large amount of money for any of the many USB hardware projects that people tend to experiment with. Especially since micro-controllers with embedded USB device controller are quite commonplace these days.

In the software / Internet world, there also are unique ID's that need to be applied for. I'm talking about protocol numbers, port numbers and the like. I've already applied for a number of them at bodies such as IANA. Obviously they are for free. This way you can ensure not to use values that get later assigned to other organizations/projects, and everything is clean.

Ridiculous fees such as the USB IF fee for a Vendor ID are just leading to the situation when independent developers will chose random ID's, which will sooner or later clash with other vendors and his devices.

If the USB IF was really interested in stability and unique assignments, they would

reserve a couple of vendor ID's for experimental/ organization internal use
create a hand full of vendor ID's which are not assigned to any vendor, but where hobbyists and Free Hardware developers can have individual device ID's assigned to themselves, e.g. like the IANA protocol/port number process works

Developing a 2.4GHz active RFID system

Harald Welte — Tue, 09 May 2006 19:00:00 GMT

Together with Milosch from bitmanufaktur.de, I've spent a couple of days and nights working on building our own 2.4GHz active RFID system. The parameters are: Battery powered, small transponders based on the Nordic Semiconductor nRF24L01 and a ultra-low-power PIC micro-controller. Base-stations have the same nRF chip, plus an Ethernet-enabled micro-controller. Operational range is ~10 meters, we even made it through two walls in our preliminary tests.

So what's the point of all this? The goal is to have that system in operation at the HOPE Nr.6, and to give a practical demonstration on how feasible it is to track people, make protocols on who has spent how much time in which lecture hall, etc.

I'm not involved with HOPE at all, but was only involved in writing firmware and higher-level code for the two embedded systems involved, as well as some testing.

I'm looking forward to learn how the system will perform with several hundreds/thousands of transponders at its first real-world test at HOPE. With some luck, we can have the same system at 23C3 in December this year in Berlin.

Until then I'm certainly going to try to implement my idea for peer-to-peer time slot synchronization of the transponders. I had that idea as a solution to avoid collisions between transponders while working on the project. Unfortunately, the current transponder hardware doesn't have a low-power timing source that is precise enough for such a protocol. Adding a 32.768kHz low-power quartz should do the trick - but will inevitably also make the transponder more costly.

Kudos to bitmanufaktur. I wouldn't even dare to try to design a PCB for 2.4GHz RF...

LaForge's home page (Electronics Engineering)

First actual XMOS / XCORE project

Introduction into XCore

My current use case

The good parts

Documentation excellent

Fast progress

Soft Cores developed in public, with commit log

xSIM simulation extremely helpful

The bad parts

Hard to get XCore chips

Extremely limited number of single-bit ports

Insufficient number of exposed xLINKs

Change to a non-FOSS License

Proprietary Compiler

Further Reading

Upcoming v3 of Open Hardware miniPCIe WWAN modem USB breakout board

Autodesk: How to lose loyal EAGLE customers

Open Hardware IEEE 802.15.4 adapter "ATUSB" available again

Open Hardware miniPCIe WWAN modem USB breakout board released

Open Hardware Multi-Voltage USB UART board released

First month of running the openmoko.org USB Product ID registry

Openmoko USB Product ID and IEEE OUI (Ethernet MAC Address) range available to the community

Name that UART: April 2012

OsmoSDR status update

First osmo-nvs-gps evaluation boards soldered

First assembled prototypes of osmo-e1-xcvr

OsmoSDR status update

More "bare iron" development: OsmoSDR, osmo-e1-xcvr and SIM bank

Facebook "Open Compute Project" nothing but hot air

Wide-screen sucks for heavy terminal users

Embedded Projects Journal

Why do all those netbook need to have fans?

Photographs of disassembly and PCB of a e-ten glofiish X800

Schiphol airport uses active millimeter wave screening

Repairing VIA EPIA-ME6000 busted capacitors

Petition against obnoxious WEEE implementation in Germany

Obnoxious RoHS/WEEE rules and their German implementation

OpenPCD press release, online shop

Visiting armzone.com in Shanghai

Ridiculous fees for USB Vendor ID

Developing a 2.4GHz active RFID system