Solution to the issue of missing components in Eagle

Today I had this problem again: when trying to add components in Schematic view, there were no components from Eagle’s standard library. This issue sometimes shows up after an update.

The solution is very simple. All you need to do is go to Eagle’s Control Panel, scroll up to Libraries, right click, and select “Use All”.

Here’s a step by step video (in spanish, but you can ignore the narration).

Sample BSCAN_SPARTAN3 implementation

I found sample code to use the BSCAN_SPARTAN3 module in Xilinx’s FPGAs. This allows the internal design to be accessed through the JTAG chain through two registers.

Here’s a sample implementation, which uses VHDL and Python

https://groups.google.com/forum/#!original/alt.sources/zbFaKsbcPxs/CaRjMJbQ910J

To extract the file, simply copy everything from #!/bin/bash until the end. The script will extract the files. Don’t worry about the checksum errors, they are produced because Google blocks email addresses and there is one in the comments section of the file. When google alters it, it makes the checksum fail. The rest of the file is fine.

BusBlaster failing with urJtag on Debian Jessie

The error is:

usbconn_ftdi_common_open() failed: inappropriate permissions on device!

Solution:

Create a file /etc/udev/rules.d/ftdi.rules with the following contents:

#FT2232 Adapter
SUBSYSTEMS==”usb”, ACTION==”add”, ATTRS{idVendor}==”0403″, ATTRS{idProduct}==”6010″, MODE:=”0666″

Restart udev (/etc/init.d/udev restart)
Unplug your BusBlaster and plug it back in.

In case this doesn’t work, try

udevadm test /dev/bus/usb/

which will help you debug your issue.

If you have changeed your BusBlasters VID/PID, you will need to adjust the line accordingly.

Getting HDD’s serial number in Linux without hdparm

I had to test some new HDDs with badblocks. I found that the Debian installer has this utility, so you can test your disks. I started testing and one of the disks started failing. I needed to get the disk’s serial number in order to know which one I had to replace. Normally hdparm tells you this, but it’s not available in debian’s installer disk.

Thanks to this stackoverflow question I got the answer:

/sbin/udevadm info --query=property --name=sda

Compiling OpenCV with TBB and the Intel compiler

When running on an Intel system, usually the best performance is achieved by using Intel’s C compilers. Since OpenCV is all about high performance, we’ll see how to get the best performance, which isn’t enabled out of the box.

Required reading: http://opencv.willowgarage.com/wiki/InstallGuide

The TBB library

First of all: the biggest performance gains don’t come from using Intel’s compiler but actually from using the TBB libraries. (Thread Bulding Blocks). If you don’t want to use (or can’t, because of licensing issues) Intel’s compiler, you can still use TBB and get a huge difference for a lot of OpenCV’s function.

For debian users, TBB is available in a package. To install:

sudo apt-get -y install libtbb-dev

And then add the WITH_TBB=YES option to cmake:

cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_PYTHON_SUPPORT=ON -D BUILD_EXAMPLES=ON -DWITH_TBB=YES

To compile, you can use make -jN (with N being the number of CPU cores you have).

This should be enough to give you a tremendous performance boost. How much? On a single-core CPU, none. On a quad-core, a 4x gain in performance (roughly). Make sure your system is using this OpenCV install and not your system’s default, if any!

Intel’s compiler suite

Now, to squeeze even more of your CPU power, you can use Intel’s compiler, which should give even better performance. It also installs IPP (Intel Performance Primitives), which are library functions optimized for intel CPUs.

You can use Intel CC for free on Linux, for non-commercial use. You can download it from Intel’s website: http://software.intel.com/en-us/intel-compilers

Required reading: http://software.intel.com/en-us/articles/using-the-intel-compilers-for-linux-with-debian

I downloaded the one that got me the file “cpp_studio_xe_2013_update3.tgz”, which you have to install as the usual commercial software (gunzip,tar,cd,./install). After installing it, READ the screen, it will give you some commands you need to run to set up your building environment. In my case, for bash, it was:

source /opt/intel/bin/compilervars.sh intel64

This will set up the needed variables. Now, to compile OpenCV, you’ll run CMAKE with these options:

LINKFLAGS=-static-intel CFLAGS=-static-intel LDFLAGS=-static-intel CPPFLAGS=-static-intel CC=icc CXX=icpc cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_PYTHON_SUPPORT=ON -D BUILD_EXAMPLES=ON -DWITH_TBB=YES -DWITH_IPP=YES ..

You will notice we added WITH_IPP=YES, this enables th Intel Performance Primitives. We also set up CC and CXX variables, to define icc and icpc as compilers, since otherwise it will use the system’s default (GCC). We also need to add the option -static-intel to compile the libraries statically, otherwise you’ll need Intel’s libraries installed and configured on the target system. Intel also recommends you build them this way. More about this here.

Final thoughts

While the gains of using Intel’s compiler may not be significant, I think it’s a good option to make sure you’re using the full potential for your processor (you paid for it anyway!).

Also, since in an OpenCV application, the biggest number-cruncher is the OpenCV library, you shouldn’t need to use Intel CC to build your application. You can compile it with GCC (and it will Just Work and save you a lot of headaches). Since the library is compiled with Intel CC, IPP, and TBB, you’ll already have significant performance gains. But if you think you’ll gain some exta performance by using this compiler for your program, nothing keeps you from trying.

 

ejtagproxy slow for debugging? maybe it’s just you.

When compiling for ejtagproxy, make sure you are allowing writes to OSCCON.

It seems it uses that register to set the CPU frequency. If your code needs to run fast, and you’re using the PLL, it won’t be enabled by ejtagproxy by default. The solution is simple, just use this config pragma:

#pragma config FCKSM = CSECME // Clock Switching and Monitor Selection (Clock Switch Enable, FSCM Enabled)

Now you should be debugging at normal speeds.

Developing for PIC32MX using Eclipse

Just as an experiment, I tried to replace MPLAB X and friends with Eclipse, GDB and ejtagproxy/pic32prog. I can say it works, and to some point it’s even better than MPLAB, since, for some reason, MPLAB won’t let me do a backtrace. So if the program dies in some processor trap, you can’t go back and see the stack calls. With GDB, you can. I used a PICKit2, but you can do it with a PICkit3. I never tried with the PICkit3 because, apparently, this means a (permanent) downgrade that will make your PK3 become a PK2 (and you will lose ability to program PIC32s from MPLAB).

It will be good if you have a debuggable .hex file for testing. You can create one with MPLAB, just set your configuration bits to a proper value (i.e. set #pragma config DEBUG = ON). You will also need a working MPLAB project directory for testing. It’s much easier that way.

Step by step installation

First of all we need to get ejtagproxy and pic32prog running. There are no debian packages for this but this isn’t terrible since these are stand-alone binaries (no install required).

Official sites: https://code.google.com/p/ejtagproxy/ and https://code.google.com/p/pic32prog/.

apt-get -y install svn libusb1.0-dev libudev-dev
svn checkout http://ejtagproxy.googlecode.com/svn/trunk/ ejtagproxy-read-only
svn checkout http://pic32prog.googlecode.com/svn/trunk/ pic32prog-read-only
cd ejtagproxy-read-only
cd ../pic32prog-read-only

If all goes well, ejtagproxy and pic32prog should be built. If not, let me know what the errors are so I can update this post.

If you have any .hex files lying around that you can use to test your PIC32 programming, using pic32prog is dead simple. Just do:

pic32prog file.hex

And that should do it.

GDB

Now on to GDB. Debian’s GDB won’t cut it, since it’s compiled for your machine’s architecture. We need to roll our own (I don’t know hot to make a proper package, so I built from sources. It’s ok – it installs (by default) to /local so it won’t be stepping on your system’s GDB. I will update this post if I find out how to make it “the debian way”. You will need the latest sources from http://ftp.gnu.org/gnu/gdb/.

apt-get build-dep gdb
wget http://ftp.gnu.org/gnu/gdb/gdb-7.5.tar.gz
tar xvfz gdb-7.5.tar.gz
cd gdb-7.5
./configure --target=mipsel-elf32
make -j4
make install

This will take a good while – GDB pulls quite a few dependencies to build. When it’s finished, you’ll get /usr/local/bin/mipsel-elf32-gdb which is the proper version of GDB targeting the PIC32 MIPS core.

Now we can actually start debugging, just for fun. Start ejtagproxy (just call it with no arguments), step into the project’s directory (the one ending in .X), and run /usr/local/bin/mipsel-elf32-gdb (you’ll need the full path since, if you have another GDB in the system, it may call the wrong one. This will give you an error). Issue: target remote localhost:2000 and you will see activity in ejtagproxy’s window and in your Pickit2. If it says something about __reset, you got it. Press c to make it run. More details here: https://code.google.com/p/ejtagproxy/wiki/Demo_gdb_session.

Microchip XC32 Compiler

No. We cannot do without Microchip’s XC32 as of “yet”. It’s GCC-based, yes, but it’s the compiler that knows the internals of the PIC32 (vectors, pragmas, etc). So, for now, you’re still stuck with it. Get it from http://www.microchip.com/compilers (hint: bottom left) and install. If your system is 64-bit, you’ll also need the 32-bit compatibility libraries. See my previous post for how to install them, or these instructions from Microchip.

Eclipse

Now comes the ugly part. You will need to install Eclipse’s “CDT” plugin (hint: http://www.eclipse.org/cdt/downloads.php). It’s not too difficult, just go into Help, add new software, add the repo, search for CDT, and install. There are quite a few. I have no idea which ones I installed but you can use common sense (I installed the base ones, and the debug ones). I’m using Eclipse 3.8.0 (I think it’s “Juno” but I’m not sure).

Start a new project. Add the files. If you use the Microchip Application Libraries, I recommend you use New > File > Advanced > Link to file in the filesystem, and link them from there.

Go into Project > Properties > C/C++ Build > Settings. This is where you’ll be setting up the XC compiler.

  • Replace “Command” (value: gcc) with: /opt/microchip/xc32/v1.20/bin/xc32-gcc.
  • Preprocessor: enable “Do not search system directories” (not good for embedded systems!).
  • Symbols: Define the symbols you need here (-Dsomething). I use this for HardwareProfile.h when I use the TCP/IP Stack.
  • Include: You’ll need to include a few paths. I have the following:
    • /opt/microchip/xc32/v1.20/lib
    • /opt/microchip/xc32/v1.20/pic32mx/include/
    • /home/hjf/MAL/Microchip/Include
    • /home/hjf/MAL/Microchip
    • (the project’s path)
  • Optimization: Optimize (-O1) (you can’t use -03 unless you’re in trial or have the paid version).
  • Miscellaneous: I don’t know what these are, but I saw that MPLAB puts them, so I put them here: -g -x c -c -mprocessor=32MX795F512L -MMD
  • GCC Linker: set command to /opt/microchip/xc32/v1.20/bin/xc32-gcc
  • Miscellaneous: same as before. -mprocessor=32MX795F512L -Wl

With this, you should be able to build your project! Hit Ctrl-B and see if it all works! It should. But you won’t get a programmable file. So we go back to Settings > Build Steps > Post Build Steps. Add this command:

/opt/microchip/xc32/v1.20/bin/xc32-bin2hex  ${BuildArtifactFilePrefix}${BuildArtifactFileName}

This will generate the .hex file for programming as well.

Tip: You can also add a step to automatically program the pic after building. I leave that as an exercise to the reader.

Setting up GDB+Eclipse

This is the part that gave me the most trouble. You have to do this (and don’t ask questions):

  • Right click the project, Debug as, Debug Configurations…
  • Double click GDB Hardware Debugger
  • at the bottom hit “Select other…”
  • change GDB command to: /usr/local/bin/mipsel-elf32-gdb
  • Use Remote Target, generic TCP/IP, localhost port 2000 (or the address you’re using).
  • In startup, disable reset and delay, halt,  and load image (this one seems to program the PIC? I don’t know what it does, but it takes forever).
  • go to Common and check the little bug icon (Favorite).
  • Hit Debug

Now you’ll get an error, because it’s in __reset. That’s ok! It’s working now. Hit continue, and happy debugging!

You will get errors in the code editor with this configuration, but they will work with the final build. This is because the code editor uses a different compiler. To solve that, go into Project > Properties > C/C++ General > Indexer and set Build configuration for indexer: Use active build configuration. That’ll do it.

P.S.: If ejtagproxy, or your board, seem to lock up, issue pic32prog a few times. This will “reset” the PICkit2.

Installing MPLAB X 1.6 on Debian wheezy

The installation instructions for MPLAB X are rather sparse. They only say “it requires 32-bit compatibility libraries”. Assuming you already have Java installed (which I did, because I had installed Eclipse before). Prior to wheezy, all you need to do was install ia32-libs. Now, after the upgrade to “multiarch” you should:

dpkg --add-architecture i386
apt-get update
apt-get install ia32-libs-i386

Now you can install MPLAB X.

Update: Microchip’s blog says you can do it like this. I haven’t tried, so YMMV.