Some years ago I reverse engineered the coefficients of the Philips SAA7220 filter, just for fun. At that time the microcontroller I implemented the filter on (LPC1114) didn't have a fully implemented I2S interface so I needed additional logic to get the data in (an array of 74HC595s) and I used the SSP to output a serial stream, albeit not reliably as I didn't implement a foolproof method of generating WS. Hence the filter wasn't ready for primetime.

Now though STM has introduced a Cortex M0 MCU which does have the dedicated I2S ports to realize a pukka emulation of the SAA7220. At least that's what I'm hoping - I know the code worked on the LPC1114 but I seem to recall I needed a slight overclock - there is a report that the STM32F072 can be overclocked but I shall need to check this out for myself. One major advantage this replacement will have is going to be lower power consumption - something of the order of 100mW or under.

In order to kick this project off,...

On the face of it, this article gives the appearance that Atmel's raced into the lead by a substantial margin in the realm of low power ARM offerings - New ARM-powered chip aims for battery life measured in decades | Ars Technica

However a quick peek beneath the surface reveals all is not what it seems at first sight.

First a stand-out from the linked article :

Atmel, the San Jose-based microcontroller maker, today released samples of a new type of ultra-low power, ARM based microcontroller that could radically extend the battery life of small low-power intelligent devices. The new ... (MCUs) consume less than 35 microamps of power per megahertz of processing speed while active,

Radically eh? Less than 35 microamps /MHz is the claim here - wanna see how that stacks up?

Ostensibly the 35uA headline figure is a worthwhile improvement over NXP's latest offering - where NXP is claiming 55uA/MHz (the LPC5410x I posted about...

Yesterday I had this very interesting exchange with RocketScientist about his open source design for a headphone amp, the O2.

https://www.diyaudio.com/forums/headp...ml#post2736266

The nub of the issue raised here is - should designers stick only to what datasheets tell them about parts or to what extent use what's 'common knowledge' about parts to eek out better performance?

I was surprised to learn from RS that offsets within dual opamps are so closely matched in practice - its a really new discovery for me. So why don't semiconductor manufacturers tout this feature? Or perhaps RS just 'got lucky' with the relatively few samples he tested?

My experience of reading opamp datasheets is that the specs for offsets (both the typicals and the max) degrade in going from single to dual devices, where the devices are all on one die. Let's have a look at a relevant opamp from...

Where is all this going I hear you ask? What's his point? Well to tell the truth I don't hear anyone asking this - the comments sections are remarkably empty save for jkeny egging me on

So here's my point, and its a single word: convergence. Convergence is coming to digital architectures - indeed its already here, just the majority of people have yet to notice.

The diverse marketplace for embedded processors is rather similar to the market for home computers in the early to mid-1980s. It was hard to make the choice - Acorn, Sinclair, Apple, Commodore, Atari, Amstrad, Dragon? Then convergence arrived in the shape of the IBM PC and those brands (with the exception of Apple) were relegated to the history books.

It took quite a while after the 1983 arrival of the PC for this to occur. I had an Acorn Atom which I built from a kit in the long summer vacation after I graduated, and I didn't make the jump into PC-land until the early 1990s. It wasn't...

Apart from an architecture which is attractive to program in, I also have several other demands on the checklist for the digital toys I'm going to pin my colours to. Ease of entry into the game and low cost development tools are a must.

Arduino is a phenomenon I did a little research into. Its become jolly popular over the past six years or so since its inception and I wanted to understand some of the reasons for its acceptance. One of the reasons has to be its open source nature. Another is the well written materials to get you going - they've put quite a lot of thought into the practical issues, even inventing their own vocabulary for elements in the process - 'sketches' springs to mind. If there's a weakness in what they're doing its this - its tied to Atmel as they're the vendors of the chips used. There are no second sources of the parts to my knowledge. This vendor-specific approach doesn't sit at all well with the open-source side - Atmel's architecture is unique...

When I began writing real-time code for the 68k, the price of entry into the development game was rather high. My first project was a tachometer processor which my boss was applying on a patent for: US patent 4924420. In order to develop this we purchased a hardware emulator which became my pride and joy - it cost a sum equivalent to around two months of my salary at that time. This was a considerably more expensive solution than the other commonly used development technique in those days - EPROM emulators - it did though provide a much faster development path by virtue of providing a window into the interior of the CPU as well as a history in its trace buffer of everything it had done. During the course of this and subsequent projects which also used the 68k (later we added a 68020 too) I became a confirmed devotee of the architecture. One of my nicknames in the company was 'the cycle stealer' - if someone had some 68k code that wasn't running fast enough, I'd find some way to get it...

My first brush with a micro as programmer was as a schoolboy - my maths teacher had a National Semiconductor SC/MP board with LEDs and toggle switches. It could be programmed in binary. I was hooked.

About a year later Science of Cambridge came out with adverts for their Mk14, using the same SC/MP. This though had a real hex keyboard and calculator style 8 digit 7 segment display. I ordered one almost immediately I saw the ad. Trouble is, it seemed to take an age to come. Someone joked that Clive Sinclair's approach was to gather up the cheques and when he'd got a few thousand pay someone to do the design! I dialled SoC's number so many times chasing my order that its still engrained in my memory over 30 years later: 0223 311488.

When I got to uni, it was clear my room-mate was in a league above me - he'd designed a system with a Z80. That was a real man's processor, compared to my little boy SC/MP. I felt a tad threatened by his prowess. Science of Cambridge...