coding » embarcado

Opcode stats

Tiago Maluta — Fri, 25 Jun 2010 00:09:50 +0000

I was trying some GCC options and decided see how they affect assembly code generated. I’ve created a simple Python script that parses .s output and put in a human readable way. Suppose the classical Hello World program. The output will be something like:

$ python stats_opcodes.py file

For Cortex-m3 (check previous post):

At my laptop (x86):

Download the script here.

Cortex-M3 and Qemu

Tiago Maluta — Wed, 23 Jun 2010 15:08:10 +0000

Just a small tip to test code generated for ARM Cortex-M3 using QEmu:

$ arm-none-eabi-gcc main.c -ggdb -mcpu=cortex-m3 -mthumb -T generic-m-hosted.ld
$ qemu-arm -cpu cortex-m3 ./a.out

You can download Code Sourcery toolchain here and QEmu here (also available from package management system of your favorite Linux distribution). Just unpack the toolchain associating the arm-201XqX/bin with your $PATH and run qemu.

NFS errors

Tiago Maluta — Tue, 08 Jun 2010 20:04:36 +0000

If you use NFS to mount your root filesystem you should probably faced with this problem:

Root-NFS: Unable to get mountd port number from server, using default
Root-NFS: Server returned error -5 while mounting /my/nfs/server/path/
VFS: Unable to mount root fs via NFS, trying floppy.

The -5 and -13 are the most common on my daily usage, but I always forgot what this number means… So, I decided to get it from source by checking nfs-utils package. The following values where extracted from utils/mount/error.c.

EPERM  ........................................ -1

ENOENT ........................................ -2

EIO ........................................... -3

ENXIO ......................................... -4

EACCESS ....................................... -5 

EEXIST ........................................ -6

ENODEV ........................................ -7

ENOTDIR ....................................... -8

EISDIR ........................................ -9

EINVAL ........................................ -10

EFBIG ......................................... -11

ENOSPC  ....................................... -12

EROFS ......................................... -13

ENAMETOOLONG .................................. -14

ENOTEMPTY ..................................... -15

EDQUOT ........................................ -16

ESTALE ........................................ -17

EWFLUSH ....................................... -18

Knowing what each error status means allow you quick fix the problems.

MyHDL: trazendo o Python para o mundo das FPGAs

Tiago Maluta — Mon, 12 Apr 2010 03:38:01 +0000

From Python to silicon

Depois de uma longa história estou participando de dois um curso aberto sobre hardware: um abordando VHDL e outro Verilog. Até aí nada de novo, quando… descobri algo interessante. Algo que realmente motivou a mudar minha rotina de trabalho para (durante alguns dias) levantar as 7h. a escrever sobre o assunto aqui no blog. :p

MyHDL

Em poucas palavras, é um pacote para o Python que permite utilizá-lo para descrever e verificar uma linguagem de descrição de hardware. Além disso você pode converter seu código Pyhton em Verilog ou VHDL, automaticamente, para gravar numa CPLD ou FPGA. Para quem quiser aprender, o tutorial mais completo está na documentação oficial do projeto. Há também uma introdução muito boa em português feito pela UFPE.

Não vou fazer um tutorial, apenas transcreverei os exemplos utilizados em sala de aula para Pythom, produzir os testes e os equivalentes em VHDL e Verilog. Um dos primeiros exercícios era descrever um multiplexador de 4 entradas.

from myhdl import *  
 
def Mux(dout, din_1, din_2, din_3, din_4, sel):
 
	@always_comb
	def muxLogic():
 
		if sel == 0x0:
			 dout.next = din_1
		if sel == 0x1:
			 dout.next = din_2
		if sel == 0x2:
			 dout.next = din_3
		if sel == 0x3:
			 dout.next = din_4
 
	return muxLogic
 
def convert():
	dout, din_1, din_2, din_3, din_4  = [Signal(intbv(0)[8:]) for i in range(5)]
	sel =   Signal(intbv(0)[2:])
	toVHDL(Mux, din_1, din_2, din_3, din_4, dout, sel)
	toVerilog(Mux, din_1, din_2, din_3, din_4, dout, sel)
 
convert()

As funções toVHDL() e toVerilog() produzem arquivos Mux.vhd ou Mux.v respectivamente (o nome é o mesmo da função definida).

Aguardem os próximos posts onde vou apresentar o test case para este e os novos exercícios que forem sugeridos em sala.

Stellaris EKK-LM3S9b96 Evaluation Kit (1)

Tiago Maluta — Tue, 06 Apr 2010 03:15:21 +0000

O blog do Jê foi um dos canais brasileiros que anunciou o concurso promovido pela Texas Instruments e a revista Circuit Cellar. Como sempre tive curiosidade nos microcontroladores de 32bits da ARM resolvi me inscrever no concurso para receber o KIT. Com uma proposta semelhante (mas sem o concurso) a NXP, a um tempo atrás, distribuiu alguns microcontroladores da família LPC. Conheço muitos “hobbistas” que pediram as amostras mas assim que chegaram os custos para fazer uma placa (mesmo que um design simples para testar a funcionalidade) tornou o projeto inviável. A idéia do kit de desenvolvimento, na minha opinião, tende a popularizar melhor o uso (principalmente para quem gosta de fuçar).

Sinceramente já tinha esquecido da inscrição quando chegou na minha casa na semana passada… e só consegui fazer o hands on neste final de semana.

Veio com todas o itens para você começar a desenvolver, a placa principal com a MCU fabricada pela Luminary é a maior na foto, sendo a outra basicamente a interface USB com o computador (utiliza o chip da FTDI). Imagino que seja possível aproveitar em outros projetos. No kit há essencialmente:

80-MHz LM3S9B96 MCU
Ethernet MAC+PHY
CAN
USB OTG,
SafeRTOS na ROM, com uma cópia limitada do Keil RealView Microcontroller Development Kit
cables (USB e rede)
CD com documentação e software
Pendrive de 256MB

Vou descrever aqui as novidades que for aprendendo. A meta é testar no final de semana o SafeRTOS. Acredito que a presença do PHY Ethernet vai permitir implementações interessantes. Se você tiver alguma idéia sugira nos comentários.

Welcome back NGW100!

Tiago Maluta — Tue, 09 Mar 2010 14:08:19 +0000

A some time ago I’ve bricked my NGW100 board by overwritten the U-boot from flash. To fix it was necessary using a JTAG interface, so I check some alternatives.

AVR JTAGICE mkII (US$ 299) [official] http://atmel.com/dyn/products/tools_card.asp?tool_id=3353
AVR JTAG ICE mkii CN (US$ 99) http://enshop.avrvi.com/avrjtagicemkiicn.html
AT AVR JTAGICE mkII clone (US$ 159) http://enshop.avrvi.com/jtagicemkiiclone.html

Considering that NGW100 itself costs about US$ 89.00 could be more cheaper get another board than buying a JTAG device. Note that I looking for way to allow a programming Interface to flash and not other features available in a JTAG like source level debugging.

The bootloader for the NGW is stored in the parallell flash

Searching for a inexpensive solution I found this AVR Freaks thread teaching how to use cable wiggler or byteblaster to flash NGW. Everyone that used Altera FPGA at least one time know about Byteblaster cable, was easy found one at university and try (thanks Prof. Robson Moreno)

I’m using Byteblaser I

I’ve compiled a new u-boot binary from BSP code and used a too called avr32prog (it’s windows-only) to record.

avr32prog.exe -c byteblaster -p LPT1 -f u-boot.img prog

The process is extremely slow, about 35 minutes to flash a 100kbyte binary (~ 50bps)

I have not had success the first time due some kind of “writing error”. I noted that if I use the computer (i.e.: browsing) when avr32prog is running the error happens faster, so I started the program a let flash the board “alone”. After finished just turn off the board, unplug JTAG connector and turn on the board again. It’s nice to see serial working again

U-Boot 1.1.4-at0 (Mar 9 2010 – 01:55:04)

U-Boot code: 00000000 -> 000149cf data: 24000000 -> 24002d80
SDRAM: 32 MB at address 0×10000000
Testing SDRAM…OK
malloc: Using memory from 0×11fc0000 to 0×12000000
Flash: 8 MB at address 0×00000000
DRAM Configuration:
Bank #0: 10000000 32 MB

In: serial
Out: serial
Err: serial

Net: macb0, macb1
Press SPACE to abort autoboot in 1 seconds
Uboot>

ipconfig over usb ethernet

Tiago Maluta — Wed, 24 Feb 2010 14:29:09 +0000

I guess this post apply only if you are using Linux v.2.6.33-rc3 or above.

You would have noted that kernel IP auto-configuration is not usable for some USB-Ethenet dongles on newer kernel because it starts before the USB devices are found. This was already discussed on LKML. I proposed a workaround adding a section on menuconfig to user increase delay (patch) but other developer proposed another patch to configure this delay at runtime rather than at compile time. This patches weren’ t applied to mainline (to further information check link). I decided post here because I take some time to configure my NFS rootfs due this delay. My tests were made using BeagleBoard and USB-Ethernet dongle based on ASIX 8877x.

First prototype for Beagle Board box

Tiago Maluta — Sat, 30 Jan 2010 15:14:51 +0000

After drawing a sketch for BeagleBoard this week I coud try something real. The board fit perfectly inside the box.

The whole for DVI-D would be a little bigger, the way it is the user need stick the connector well to don’t loose image quality.

The entries for USB and MMC fits together in the same whole. I put RS232 output because it’s a prototype, if you are developing something for an end-user you don’t need that. The box in my tests don’t heated

I’m using this box to show a “general purpose” computer to others. Inside the memory card I had some GNU/Linux distributions like: Angstron, Ubuntu and Gentoo. But Symbian and Maemo are in the roadmap. Other tests include running linus-git kernel done with CodeSourcery toolchain (2009q1 and 2009q3) and playing with armv7a instructions.

Check more photos on Flickr!

First sketch for Beagle Board box

Tiago Maluta — Thu, 14 Jan 2010 22:59:24 +0000

This is my first approach to make a case for Beagle Board. I used a plastic one that fits almost perfect, needed basically a 12 mm. spacer to height adjust. The box would be like this picture:

And the BB would fit, inside the box, more or less like that:

I still need consider some points:

Even with an “natural” exhaust ventilation (no fan, not visible in picture) the heat influence on “heavy” use.
Check all connectors and see if they fit properly.

I hope for the next weeks post more about this box and great ideas with Beagle Board.

Stay tuned!

Changes on kernel cross compiling

Tiago Maluta — Wed, 28 Oct 2009 22:32:01 +0000

Probably if you compile – many times – Linux for embedded hardware you change Makefile to your specific architecture and compiler. An example:

# Set the ARCH and CROSS_COMPILE default values
ARCH            ?= arm
CROSS_COMPILE   ?= arm-unknown-linux-gnu-

Latest Linux (~2.6.31) turns it deprecated (commit 575543347b5baed0ca927cb90ba8807396fe9cc9). Now the settings are saved in two files named:

include/generated/kernel.arch
include/generated/kernel.cross

What changes?

Using the new way you don’t edit Makefile anymore, just need set once your definitions for cross compiling:

$ make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu-

And for next builds just run make

$ make

This works both for plain builds and for O=… builds.