Swapping Dev Board Crystals to Suit Your Needs

Microcontroller Dev Boards have the main hardware choices already made for you so you can jump right into the prototyping by adding peripherals and writing code. Some of the time they have everything you need, other times you can find your own workarounds, but did you ever try just swapping out components to suit? [Andy Brown] documented his process of transplanting the clock crystal on an STM32F4 Discovery board.

Even if you don’t need to do this for yourself, the rework process he documented in the clip after the break is fun to watch. He starts by cleaning the through-hole joints of the crystal oscillator with isopropyl alcohol and then applies some flux paste to each. From there the rest is all hot air. The crystal nearly falls out due to gravity but at the end he needs to pluck it out with his fingers. We’re happy to see others using this “method” as we always feel like it’s a kludge when we do it. Next he grabs the load caps with a pair of tweezers after the briefest of time under the heat.

We’d like to have a little bit of insight on the parts he replaces and we’re hoping there are a few crystal oscillator experts who can leave a comment below. [Andy] calculates a pair of 30pf load caps for this crystal. We understand the math but he mentions a common value for board and uC input capacitance:

assuming the commonly quoted CP + CI = 6pF

So we asked and [Andy] was kind enough to share his background on the topic:

It’s a general “rule of thumb” for FR4 that the stray capacitance due to the traces on the board and the input (lead) capacitance of the the MCU is in in the range of 4-8pF. I’m used to quoting the two separately (CP,CI) but if you look around you’ll see that most people will combine the two and call it just “CP” and quote a value somewhere between 4 and 8pF. It’s all very “finger in the air” and for general purpose MCU clocks you can get away picking the mid-value and be done with it.

That leaves just one other question; the original discovery board had an in-line resistor on one of the crystal traces which he replaces with a zero ohm jumper. Is it common to include a resistor and what is the purpose for it?

Continue reading “Swapping Dev Board Crystals to Suit Your Needs”

Execution Tracing on Cortex-M3 Microcontrollers

The higher-power ARM micros have a bunch of debugging tools for program and data tracing, as you would expect. This feature – CoreSight Trace Macrocells – is also found in the lowly ARM Cortex M3 microcontroller. The Cortex M3 is finding its way into a lot of projects, and [Petteri] wondered why these debugging tools weren’t seen often enough. Was it a question of a lack of tools, or a lack of documentation? It doesn’t really matter now, as he figured out how to do it with a cheap logic analyzer and some decoders for the trace signals.

There are two trace blocks in most of the Cortex M3 chips: the ITM and ETM. The Instrumentation Trace Macrocell is the higher level of the two, tracing watchpoints, and interrupts. The Embedded Trace Macrocell shows every single instruction executed in the CPU.  Both of these can be read with a cheap FX2-based logic analyzer that can be found through the usual outlets for about $10. The problem then becomes software, for which [Petteri] wrote a few decoders.

To demonstrate the debugging capability, [Petteri] tracked down a bug in his CNC controller of choice, the Smoothieboard. Every once in a great while, the machine would miss a step. With the help of the trace tool and by underclocking the micro, [Petteri] found the bug in the form of a rounding error of the extruder. Now that he knows what the bug is, he can figure out a way to fix it. He hasn’t figured that out yet. Still, knowing what to fix is invaluable and something that couldn’t be found with the normal set of tools.

Library upgrade to PRU gives Fast IO on Beaglebone

The BeagleBone Black has a powerful featureset: decent clock speed, analog inputs, multiple UART, SPI and I2C channels and on-board memory, to name a few. One missing feature seems to be the lack of support for the two on-board Programmable Real-time Units (PRU’s). Each of these 32-bit processors run independently of the main processor, but are able to interface with the main processor through the use of shared RAM and some interrupts. Unfortunately, PRU’s are not supported and in the absence of information, difficult to program. Enabling the PRU’s will allow them direct access to external sensors via the GPIO pins, for example. Perhaps most enticing is the idea that the PRU’s add real-time processing capability to the BBB.

[Thomas Freiherr] is working on the libpruio project to allow PRU support on the BBB. It is “designed for easy configuration and data handling at high speed. libpruio software runs on the host (ARM) and in parallel on a Programmable Realtime Unit SubSystem (= PRUSS or just PRU) and controls the subsystems”. Additional information about the project is available on the libpruio wiki, and files can be downloaded from here (German Page).

This paper presented at inter.noise2014 (PDF) a couple of months ago has a nice comparison of various small computer/controller boards and outlines the advantages of the BBB once its PRUs are enabled. If readers come across applications of the BBB with PRUs enabled, let us know in the comments. If you want to work your way into the world of the PRU we highly recommend this tutorial series.

Thanks for sending in the tip, [Patrick]

[Image Source: libpruio stepper motor example]

The Teensy LC. LC Means Low Cost.

For one reason or another, we’ve been seeing a lot of builds featuring the Teensy 3.1 filtering in on the tip line recently. In retrospect, it’s somewhat obvious; it’s a good board that’s cheap and fast. Yes, somehow [Paul] hit all three in the good/cheap/fast mutually exclusive triumvirate.

Now, there’s a new Teensy. It’s the Teensy LC – Low Cost. It’s not as powerful as the Teensy 3.1, but it does give you the power of an ARM for something that’s just about as cheap as a board with an ATMega.

The chip [Paul] chose for the Teensy LC is the Freescale MKL26Z64 (datasheet here and 876-page reference manual here. PDFs of course). This is a 32-bit Cortex-M0+ running at 48 MHz with 64k of Flash and 8k of RAM. There are 27 digital I/O pins on this one, and the Teensy LC has been designed to be pin-compatible with the Teensy 3.0 and 3.1.

On board are 13 analog inputs, 8 PWM outputs, on 12-bit DAC output, three serial ports, two SPI ports, and two I2C ports. Most of the pins can drive 5mA with a few capable of driving 20mA, and there is a single 5v output pin for driving WS2812 Neopixel LEDs.

Since this is a cut-down version of the Teensy, everything available on the Teensy 3.1 just can’t fit into the BOM of the Teensy LC. The pins aren’t 5V tolerant, there’s no CAN bus, and there are only 4 DMA channels instead of 16 on the Teensy 3.1. Still, it’s a great ARM answer to the ATMega Trinket or other small dev boards.

Passion Project Turns BeagleBone into Standalone Super NES

So you want to play some retro games on your BeagleBone, just load up Linux and start your favorite emulator right? Not if you’re serious about it. [Andrew Henderson] started down this path with the BeagleBoard-xM (predecessor of the BeagleBone Black) and discovered that the performance with Snes9X wasn’t quite what he had in mind. He got the itch and created a full-blown distro called BeagleSNES which includes bootloader and kernel hacks for better peformance, a custom GUI, and is in the process of developing hardware for the embedded gaming rig. Check out the documentation that goes along with the project (PDF); it’s a blueprint for how open source project guides should be presented!

The hardware he’s currently working on is a Cape (what add-on boards for the BBB are called) that adds connectors for original Nintendo and Super Nintendo controllers. It also includes an RTC which will stand in for the real-time clock features included in some cartridges (Pokemon Yellow). Also in the works is a 3D printed enclosure which would turn it into a portable, something like this other BBB portable hack.

Check out a demo of what BeagleSNES can do in the video after the break.

Continue reading “Passion Project Turns BeagleBone into Standalone Super NES”

Casing up the Teensy SDR

[Rich, VE3MKC] has made a lot of progress on his Software Defined Radio (SDR) which is based on a Teensy. His latest update shows off the hardware in an enclosure and a few new features.

When we looked at this in April of last year it was pretty much a proof-of-concept with components hanging loose from jumper wires. The new case mounts everything securely in a plastic Hammond enclosure with copper clad for the front and rear panels. The SoftRock SDR unit was yanked from its case and retrofitted with connectors to make it swappable for other units.

A little help goes a long way and [Rich] thanks his friend [Loftur, VE2LJX] for contributing numerous code improvements and feature additions which can be viewed in the repository. Check out the video below where these features are shown off.

In its present state the radio draws 80 mA at 12V in receive mode. It doesn’t transmit yet but we’ll keep our eyes open for another update on that. [Rich] plans to populate the input circuitry and write the transmit code next.

Continue reading “Casing up the Teensy SDR”

ARM Pro Mini

Slowly but surely, the age of 8-bit micros being the first tool anyone picks up is coming to an end, and we’re seeing more and more ARM dev boards in nifty, breadboard-friendly packages. [Zapta] thought he would throw his hat into the ring with the ARM Pro Mini, a tiny little board based on the ARM M0 microcontroller.

The ARM chip on this board is the NXP LPC11 with 64 kB of Flash, 12 kB of RAM, and just enough pins to make the whole endeavor worthwhile. The board itself is extremely simple, with just enough SMD parts to be annoying to hand solder.

All the nifty bonuses of ARM boards are available on the ARM Pro Mini, including drag and drop firmware over the USB port, support for single stepping and debugging, and the IDE is a single install with NXP Eclipse/LPCXpresso. Mbed is also supported, so it’s possible to use this board with no software installs when using the online Mbed IDE.

[Zapta] has put everything you need to build this board up on his Github, and has even done a few simple ‘getting started’ tutorials, including a cool little example with a graphics library and a small OLED.