Loading
Summer Hacking
It is summer on the northern hemisphere, and I've decided to target a smaller system than I've been used to in the last couple of years. In particular, I've decided to finally open my dear old PICkit II. The goal is to be able to work with this board from within a Linux environment.
The PICkit II sports a PIC16F690 device. The debug dongle supplied supports many more devices and is a very handy tool to have around if you work with PIC processors. The PIC16F690 comes with 7kB of program FLASH, 256B of RAM and 256B of EEPROM; hardly enough to run Linux, but just right to do small monitoring or automation tasks.
To my joy, the PICkit II is now supported on Linux by Microchip (the makers of the PIC processors). The tools are supplied "as-is," and do not expect to be popular in the support department for not following the main road, but still, it is better than nothing. Also, they are free, but only as in free beer. To download the tool, look for PK2CMD for Linux (simply search for Linux) on the PICkit II page.
The recommended file to download is the source code package, as the binary was built back in 2009 on CentOS 4.7. To build the binary, untar the source code package, enter the resulting directory and run make linux, followed by sudo make install. On my Debian system, I needed to have build-essential and libusb-dev installed to get the compilation to succeed. The resulting installation ends up in /usr/local/bin/ and /usr/share/pk2/. You will also have to setup a couple of udev rules for the USB device to be properly detected, as shown in this blog. The only issue not discussed there that I ran into was updating the software of the PICkit II programmer itself, i.e. the OS Firmware Version returned from pk2cmd -?V. I had to surrender and used the Windows version to get that updated properly (and it took three attempts there as well). Rest assured - I did not brick the device by trying - more than once.
The pk2cmd tool lets me interface the PICkit II programmer, i.e. to download software to the PIC device. Now, all that is missing are the tools to actually create software. Here, a fully open source toolchain is available. To my joy, it was already packaged for Debian, so a simple apt-get install gputils gpsim takes care of that.
The gputils package contains gpasm and gplink - an assembler and linker compatible with the PIC16F690 device. The gpsim package contains a simulator for PIC circuits. However, it does not support our specific PIC device. Still, it is great for experimentation and detailed debugging in a controlled environment (no reality present to bite you).
The PIC instruction set can be described as, let's be kind, odd. It is very far from symmetrical, and exposes the bare metal in various ways. If you have studied microprocessor architecture 101 or something similar, you will see many familiar concepts in the flesh. Still, for those of us who cannot stand this, there is the SDCC - Small Device C Compiler.
The SDCC also comes prepackaged for Debian and other distros. It supports the PIC device in question, but also MCS51, DS80, Z80 and HC08. The PIC support is divided into PIC14 and PIC16, where the number indicates the bits in each instruction. Just to amuse themselves, the Microchip engineers made the PIC16F690 device a PIC14 processor.
Well, the summer weather is great and I've got my LED flashing here, so I leave you with a list of tools and hopefully you will be able to use this to take the next leap in automation and PIC-based development.
______________________
Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Developer Poll
- Dart: a New Web Programming Experience
- What's the tweeting protocol?
- New Products
- Linux is good
1 hour 46 min ago - Reply to comment | Linux Journal
2 hours 3 min ago - Web Hosting IQ
2 hours 33 min ago - Web Hosting IQ
2 hours 34 min ago - Web Hosting IQ
2 hours 35 min ago - Reply to comment | Linux Journal
5 hours 35 min ago - play with linux? i think you mean work-around linux
14 hours 1 min ago - Where is Epistle?
14 hours 7 min ago - You forgot OwnCloud
14 hours 37 min ago - aplikasi free
17 hours 51 min ago
Comments
Consider AVR as an alternative
If you have no real reason to choose the PIC I recommend the AVR as an alternative.
GCC and friends are ported to the AVR and there is a very helpful community available when you need help.
From my understanding, the
From my understanding, the AVRs are nicer from multiple perspectives - primarily ISA and tooling (from a FLOSS viewpoint). So, what hw do you recommend using to get started? Is Arduino the way to go, or are there other cheap boards out there?
Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.
An old fan
of AVR since the early 2000s, which I chose originally over PIC because the devices were well supported in Linux and didn't require a high voltage programmer. They were originally programmed through a simple cable from the PC parallel port. However I have gone to the PICs for DSP power and also USB support. There are a couple of opensource programmers for them: the OpenProgrammer project by Alberto Maccione I built on a prototyping board for in-circuit programming, and it works fine. The programming voltage and algorithm variations among the PICSs, even of the same family, are bewildering. Some later PICs use low voltage programming. Microchip's IDE also runs well under WINE in Linux, as does their C compiler. A bit sad that we don't have true opensource for these as they have crippled the optimization in the freeware versions, but I imagine it would be a nightmare dealing with all the variations among the PIC instruction sets.
The main reason for
The main reason for mentioning the AVR is the very helpful community and good Linux support.
I have used PICs in the past, really liked them until they introduced the PIC18Fxxx. The instruction set and architecture of the original PICs (PIC1652?) was wonderful in a very weird way. When I stopped using PICs I promised myself to never touch them again, but about 6 months ago I had to help a customer with some PIC stuff and had to use the original Microchip compiler. Compared to PICC from Hi-Tech it's a disaster. The smart guys at Microchip realised that and bought Hi-Tech. Smart move. Another smart move was to base PIC32 on the MIPS processor.
Today I mostly use ARM for obvious reasons with some AVR (because of GCC) when needed. I think PIC32 could be interesting because of it's low price and GCC-support.
PIC32 also
I'm using my old PICkitII and a clone to program the PIC32MX795 on the UBW32 Schmalz board, http://www.sparkfun.com/products/9713. MPLAB-X's projects create a Makefile that you can make from Linux command line. MPLAB-X runs on ubuntu 32bit just fine.
PIC32 also
I'm using my old PICkitII and a clone to program the PIC32MX795 on the UBW32 Schmalz board, http://www.sparkfun.com/products/9713. MPLAB-X's projects create a Makefile that you can make from Linux command line. MPLAB-X runs on ubuntu 32bit just fine.
Set me up!
Johan,
I'd like to get the PIC experience... would you help me with some questions?
Your PIC programmer in the above picture is not shown on the MicroShip Direct website. I'm assuming it's an old version? Would you know Which of the current models is Linux friendly? Also, is the interface USB or serial?
I'm just getting mu ducks lined up... Also, as side note, my company works with equipment that have PIC's included into soem of the display assemblies. I ahve access to the old, dead assemblies and may have a prime source for use, old PIC's...
This could be fun.
Thank you
---- Jerry McBride
Let me start by saying that I
Let me start by saying that I only have first hand experience with PK2 on Linux.
PK3, which is being pushed right now is reported not to be as good as PK2. For instance, there are no Linux divers.
OTOH, the Mplab X project seems promissing - an official, cross platform IDE for pic development.
If you want true openess, you could try the open programmer (http://openprog.altervista.org/).
Johan Thelin is a consultant working with Qt, embedded and free
software. On-line, he is known as e8johan.
Johan, Thanks for the
Johan,
Thanks for the information... The pics I have access to are PIC16F387A... not having a good time finding data sheets.
Thank you again.
---- Jerry McBride
Linux and PICs
With the the new MPLAB X IDE (based on NetBeans), all of Microchip's current debug/program tools are now well supported under Linux. I regularly use the PICkit 2, PICkit 3, ICD 2, ICD 3, and Real ICE while running MPLAB X on Linux. MPLAB X may be downloaded from here:
http://www.microchip.com/en_US/family/mplabx/index.html
Jerry - you are probably having difficulty finding data sheets because there is no such device as a PIC16F387A. You most likely have the PIC16F873A, which is a hugely popular part. Data sheets may be found here:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010236
--Rob
udev rules
There is no real need to create a new group for the udev rules. I chose to simply use dialout.
$ cat /etc/udev/rules.d/00-mcu-programmers.rules# See also /lib/udev/rules.d/40-avarice.rules
SUBSYSTEM!="usb_device", ACTION!="add|change", GOTO="mcu-programmers-end"# Atmel devicesATTR{idVendor}=="03eb", ATTR{idProduct}=="2104", GROUP="dialout", SYMLINK+="avrispmkII"
#ATTR{idVendor}=="03eb", ATTR{idProduct}=="2103", GROUP="dialout", SYMLINK+="avrunknown-%n"
#ATTR{idVendor}=="03eb", ATTR{idProduct}=="2107", GROUP="dialout", SYMLINK+="avrdragon-%n"
# Microchip devicesATTR{idVendor}=="04d8", ATTR{idProduct}=="0033", GROUP="dialout", SYMLINK+="pickit2"
LABEL="mcu-programmers-end"
The symlink is not really necessary, I used it for debugging my rules and chose to keep it. It allows me to see if the device is plugged in and properly recognized.