Archive for category Milkymist
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:
- 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.
- 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.
- Like above, but edit non-interactively. This is an experimental hack I’ve now implemented.
Read the rest from the Milkymist mailing list…
We are currently working on a software upgrade that will allow USB MIDI controllers such as the Faderfox LV3 to be used with the Milkymist One. The update will be compatible with all existing Milkymist devices, and will be installable easily.
Right now, you can already use traditional MIDI devices to control Milkymist One visuals. The update will make it possible to use those MIDI devices that only provide USB connectivity as well.
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:
Then, power off and on again your M1. The “About” dialog box will display the new versions (Flickernoise 1.0 + SoC 1.0.1):
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.
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:
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.
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.
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.
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.