Archive for category Howto’s

Observing internal FPGA signals

By Werner Almesberger

Sometimes, when debugging some firmware or hardware, it is necessary to see how the internal state of a chip changes in response to external signals.

With microcontrollers, this can be accomplished by adding code that toggles some pin that is then used for debugging, and watching that pin with an oscilloscope. Such a pin can also serve as sophisticated trigger, e.g., to capture some input signal only when an error is detected.

With M1, we can do the same, e.g., make LM32 or Navre toggle an I/O under software control. But we can do better: we can also route “hardware” signals directly, without involving software.

Here are three ways to do this:

  1. Change the Verilog to properly route the signal to the output pad. This is nice and clean but has the following disadvantages:
    • need to run the full build process for each change of taps,
    • need to edit the sources (and remember to undo all the changes once the problem is fixed),
    • the signals need to be propagated step by step up the module hierarchy (*), which means a lot of small changes in many files,

      (*) Verilog should support also direct references that “jump” the hierarchy, but this doesn’t seem to be properly implemented in the Xilinx tools.

  2. The pros just edit the FPGA with a WYSIWYG editor (Part three shows how to route signals to a pad). What I don’t like about this is that it’s not script-friendly. I’d also suspect that the changes are lost or at least in danger when re-synthesizing.
  3. Like above, but edit non-interactively. This is an experimental hack I’ve now implemented.

Read the rest from the Milkymist mailing list

No Comments

Milkymist One software updates

Software updates are available for the Milkymist One. This update mainly fixes a number of bugs – if you experience freezes or other issues, install the update, and let us know if you still have problems (devel at lists dot milkymist dot org).

Updating is easy – just connect the M1 to the Internet (booting it with the Ethernet cable connected to a network with DHCP should do, or use the system settings to configure the network) and then press the first push button (labeled L) for a few seconds. It should display this:

Update in progress

Then, power off and on again your M1. The “About” dialog box will display the new versions (Flickernoise 1.0 + SoC 1.0.1):

New versions

No Comments

SoC Milkymist: le développement logiciel en pratique

Cet article a été publié dans Linux Magazine 130 (septembre 2010) et est disponible sous licence CC-BY-NC-ND. Depuis, la situation a évolué. Il existe un portage OpenWrt automatisant de nombreuses manipulations décrites dans l’article. Une partie du chargeur d’exécutable et de nombreux bugs Linux ont été corrigés. QEMU ne nécessite plus de patch et la version 0.15 supporte directement Milkymist. Enfin, les Milkymist One sont disponibles à la vente et viennent avec une version bien plus aboutie de Flickernoise ainsi que tout un “packaging”.

Le numéro 124 de février vous a donné une présentation générale et assez théorique du System-on-Chip (SoC) libre Milkymist. Maintenant, nous allons nous orienter vers la pratique en détaillant les différentes opérations nécessaires au développement de logiciels fonctionannt sur cette plate-forme: installation des outils de compilation, construction d’un noyau Linux compatible, compilation d’applications et utilisation de l’émulateur QEMU, pour finir avec la configuration d’une carte de développement FPGA permettant de prototyper le SoC et le déploiement du logiciel sur cette dernière.

Read the rest of this entry »

No Comments

M1 with MIDI

By Werner Almesberger

You haven’t really seen what the Milkymist One (M1) really can do if you haven’t used it with some MIDI controls.

Here’s how it’s done:

  • first, you need some MIDI controller. For now, it has to be one that has the old-style MIDI connectors, not USB-MIDI. I used a Korg Kaossilator Pro.
  • next, you need to define which of the controller functions you want to map to variables for your patch. This is done in the M1’s control panel, Interfaces > MIDI > Controller mapping.

    “midi1″ through “midi8″ are the variables you can set. The value on the right side is the controller number. E.g., for my Kaossilator, I assigned:

    midi1 12 touch pad, X axis
    midi2 13 touch pad, Y axis
    midi3 91 gate arpeggiator slider
    midi4 94 program volume knob

    This is for using the Kaossilator both as an instrument and as a MIDI controller. If I had switched it to be only a controller, I would have had more controls to play with and some of the numbers would have changed.

  • you can now use Patches > Variable monitor to see how the controls affect the midi1 … midi4 variables. Each gets assigned a value between 0 to 1, corresponding to the setting of the control. (MIDI transmits values from 0 to 127.)
  • finally, you need to modify a patch to use the MIDI variables. I took a simple one, “Geiss – Tornado”, and made the following tweaks:
    1. per_frame=t=time+midi2*100;

      and then changed all the wave_
      settings to use “t” instead of “time”. This way, I can modulate the color by moving along the Y axis on the pad.

    2. per_frame=rot=midi1*2;

      I put this after the last assignment to “rot”, effectively overriding it. Now rotation is entirely under my control, with no rotation when touching the pad on the left edge, and rapid spinning on the right edge.

    3. per_frame=move_x=0.5+midi3/5;

      This controls the distance of the point being drawn from the center. With rotation, this becomes the radius at which things appear. I assigned it to the slider.

    4. per_frame=zoom=0.9+midi4/5;

      This controls how quickly we “travel into” the image. I assigned it to the volume knob.

  • these settings are lost when powering down or restarting the M1. To keep them, save with Performance > Save and, after booting, load with Performance > Load. Be careful to save under the directory /ssd/, not the root directory. The latter is also lost when booting.

Read the rest of this entry »

2 Comments

How to make conductive silver ink for ballpoint pens

“Materials researchers at the University of Illinois, Urbana-Champaign have developed a highly conductive silver ink. In this video, Analisa Russo, a graduate student in the research group of Professor Jennifer Lewis shows exactly how to make this amazing ink, which could be used for a wide variety of hobby projects and in advanced electronics hardware.”

2 Comments

Testing the DIY triode from PWL

I was curious to see how well the PWL triode performed. So I made a little test to measure cathode emission and amplification.

The first step was to build a variable high voltage power supply, since I’m under-equipped enough not to have one laying around. So I used a 20V power supply transformer connected to a 120V variable autotransformer scavenged from a 70’s American-built X-ray machine that happened to have a permanent tap within the first turns, allowing it to step-up the voltage to a nice 180V. For turning it into DC, I simply took the switching power supply PCB from a discarded fax machine, cut it right after the filtering capacitor, and hooked it to the variac. There are easier options, but I did with what I found in my pile of junk :)

The grid voltage is provided by a 9V battery and a potentiometer, and the filament voltage by my (single!) lab power supply. I then used cheap DMMs to measure anode voltage, anode current and grid voltage.

This resulted in this little kludge:

Experimental setup


Schematics of the above little mess

Emission tests
The first test was to see how many electrons the hot filament is capable of sending into the tube. I connected together the anode and the grid and brought them to a 176V potential, while I varied the filament voltage.
This led to this plot:

Cathode emission versus filament voltage


Clearly, the tungsten cathode only begins to work at very high temperatures! Wikipedia lists an efficiency of 5mA/W for a tungsten cathode (oxide-coated cathodes, used in commercial tubes, are 100 times better). At 4V, the filament current is 280mA, which represents a power of 1.1W. The emission, however, is only 2.2mA. Perhaps it works better with more filament voltage, but I did not dare cranking it up for fear of damaging the filament.

The second test was to see how much the anode potential influenced the anode current. I set the grid to the ground potential, and varied the anode voltage. The plot shows a quite linear dependence:

Anode current versus anode voltage

Amplification test
Now, let’s see how good this triode is at doing its job: amplifying signals! With the anode potential set to 176V and a filament voltage of 4V, I sweeped the grid voltage and plotted the anode current:

Anode current versus grid voltage


Clearly, the tube is working! It is not the best triode in the world, as the grid apparently struggles to stop all electrons (and because of the low emission efficiency of the tungsten cathode). But it definitely does some amplification and it certainly is a usable tube. Impressive work!

2 Comments

Upgrading from Flickernoise 0.1 without a JTAG cable

Since Flickernoise 0.1 does not support software flashing, the procedure is a little more complex than normal. The trick is to boot a newer version of Flickernoise (>= 0.2) from the network, and use that one to reflash the board.

STEP 1: Install a TFTP server
Install the TFTP server package for your distribution, and configure it.

STEP 2: Prepare the boot image
Take the Flickernoise FBI (Flash Boot Image) file from the MSD archive, and remove its FBI header.
$ dd if=flickernoise.fbi of=boot.bin bs=1 skip=8
Then, move it to the TFTP server directory:
$ mv boot.bin /var/lib/tftpboot

STEP 3: Boot the board from the network
Set up your computer to have the IP address 192.168.0.14, and connect it to the board. Boot the board (press the middle pushbutton) with a USB keyboard connected to it, and when you see the BIOS splash screen, press the F8 key to boot from the network.

BIOS splash screen

STEP 4: Erase the old flash filesystem
Flickernoise 0.1 uses a read-only FAT filesystem on the flash, while Flickernoise 0.2 introduced full YAFFS2 support. You will therefore need to format (erase) the flash disk partition.

For this, you will need to obtain a shell on the board. This can be simply done by enabling the telnet server and connecting to it. You need to set up a login and password to enable telnet access. Click the “Settings” button at the bottom of the control panel, and enter a login and password in the dialog box.

System settings dialog box

Once this is done, you can use telnet to connect to the board:
telnet 192.168.0.42
Enter the following commands at the RTEMS shell prompt:
# unmount /flash
# erase /dev/flash5
# mount -t yaffs /dev/flash5 /flash

Telnet session

STEP 5: Transfer the new flash images to the board
Simply use an FTP client to connect to the board (192.168.0.42), and upload the contents of the MSD archive, e.g. in the /ramdisk folder. Use the login and password you just set up to authenticate to the FTP server.

STEP 6: Flash
In the control panel, click “About”, then “Flash”. Select the images you have just uploaded, and click the “Program flash” button.

Flickernoise flash programmer

You’re done! If you have upgraded the bitstream, you need to select “Shutdown” (in the control panel), then “Power off” and then power the board on again. Since a disk cache is used by the RTEMS operating system, always use “Shutdown” to turn off the board to prevent data loss.

And while you have the FTP connection open, you can also use it to upload the default Flickernoise patches to the flash…

No Comments