Last week a rumor started spreading about Eagle, the popular schematic capture and PCB drawing package used by thousands of electronics enthusiasts, switching to a text-based file format. We at Elektor asked CadSoft, the editor of Eagle, about this rumour and got it confirmed. Somewhere in the hopefully near future Eagle will start using an XML-based file format for storing its drawings. The reason for this change is, according to CadSoft, that the binary format has reached its limits.
I find this reason a bit strange. Why would a text format be more flexible than a binary format? I mean, text is just limited binary, right?
Of course a text-based format is human readable, which is an advantage when trying to debug a broken file. But will this help in real life with a multi-megabyte sized file? (BTW, I have never yet had to debug a PCB file.)
A text-based format will be cross-platform as it avoids byte ordering issues, a good thing. Using XML is probably a good idea too, because it is a well known format and many tools & libraries for fiddling with XML files are readily available.
For the user a text-based format is interesting as it may help speed up certain repetitive tasks like net labeling or copying blocks. Users will start writing utilities for manipulating Eagle files.
Will they? Probably. They always do.
But Eagle already offers a powerful scripting language that lets you do lots of things without learning the file format first, so why bother? By writing a script you can already export everything yourself to a human readable format. And that is exactly what RS did for DesignSpark, the competitor of Eagle Freemium by Farnell (who bought CadSoft some time ago). RS offers scripts that allow you to export Eagle files as ASCII data. This is what it looks like:
EAGLE_INTERMEDIATE_ASCII "my_board.brd"
(asciiHeader
(fileUnits IN)
)
(library Library_1
(padStyleDef "Oval1"
(holeDiam 0.0314961)
(padShape (layerNumRef 1) (padShapeType Oval) (shapeWidth 0.0514961) (shapeHeight 0.102992))
)
(padStyleDef "Round1"
(holeDiam 0.125984)
(padShape (layerNumRef 1) (padShapeType Ellipse) (shapeWidth 0.133984) (shapeHeight 0.133984))
)
(padStyleDef "Rectangle1"
(holeDiam 0)
(padShape (layerNumRef 1) (padShapeType Rect) (shapeWidth 0.07) (shapeHeight 0.1))
(padShape (layerNumRef 16) (padShapeType Ellipse) (shapeWidth 0) (shapeHeight 0))
)
…
That is not so different from XML, is it?
The only reason I can think of why Farnell/CadSoft wants to switch to XML is that they hope that the heavyweights like Cadence or Pads will start writing Eagle import filters for their products. These products already know XML, it would be easy enough to add Eagle support. And that would be a good sales argument for Eagle. Start simple and low-budget with Eagle and when you’re ready to move on to something more serious you won’t lose your work.
It is all about compatibility.
Wednesday, October 20, 2010
Thursday, October 7, 2010
Build a dishwashing surveillance system
Every once in while I spend an afternoon or evening just browsing eBay. I do some searches on keywords concerning things that may interest me and I look through the results. When I find something interesting I click on the item for more details. Often I come across items that are sold by Chinese companies that sell lots of other things too. These are my favorite sellers. There are many Chinese eBay shops that sell exactly the same products, they probably are all related, but every once in a while I discover a new “family” of shops with different products.
My latest find is a series of cheap microcontroller boards equipped with a small camera and a 2.8” color TFT display. The camera, 640x320 pixels, is actually a small module that is plugged on top of the board, while the display (320x240 pixels, 262K colors) sits on the other side. You can make a camcorder out of it, because it has a micro SD card connector for storage.
I bought the ATmega32 board including a USBasp ISP programming cable for less than 35 euros (shipping included). It is a complete development system with full documentation and source code in C (with comments in garbage characters, probably Chinese). When it arrived I discovered that the display even has a resistive touchpad on it.
Here is a sneak preview of my killer app for this board: a dishwashing surveillance system that checks my dishwashing qualities. It will detect dirt on the dishes and sound an alarm when everything is dry. Pretty cool, huh?
So, what will you do with it?
My latest find is a series of cheap microcontroller boards equipped with a small camera and a 2.8” color TFT display. The camera, 640x320 pixels, is actually a small module that is plugged on top of the board, while the display (320x240 pixels, 262K colors) sits on the other side. You can make a camcorder out of it, because it has a micro SD card connector for storage.
I bought the ATmega32 board including a USBasp ISP programming cable for less than 35 euros (shipping included). It is a complete development system with full documentation and source code in C (with comments in garbage characters, probably Chinese). When it arrived I discovered that the display even has a resistive touchpad on it.
Here is a sneak preview of my killer app for this board: a dishwashing surveillance system that checks my dishwashing qualities. It will detect dirt on the dishes and sound an alarm when everything is dry. Pretty cool, huh?
So, what will you do with it?
Monday, September 13, 2010
RFID made simple
More and more people are using the Sceptre ARM7 board from Elektor, which is good. The Sceptre is supported with an open source library in C and I am currently working on adding new functionality to it. As I wrote in a previous article I spent quite some time understanding the BTM222/112 Bluetooth modules and this will soon be included in the library.
I also received a request for RFID support and so I implemented a driver for the EM4095 transceiver (EM Microelectronic) that can read the tags you can buy for cheap on eBay (for instance).
To get me started I bought in Hong-Kong (through eBay of course) for 17.50 euros (shipping included!) a fully functional RFID proximity door entry access system with 10 tags and 5 badges. Only a week later the kit arrived.
This turned out to be a pretty nice product actually; its only downside is its cheap plastic housing that will probably not survive very long outdoors. Rain and intruders will not have a very hard time getting to the electronics.
Top side of PCB
Bottom side of PCB
The antenna is slightly larger than the PCB
Interesting about this unit is that it uses a "discrete" (well, sort of, compared to a single chip solution) radio, built around a 4069 and a 74393. I traced the circuit (see below), but I didn’t measure the capacitors (all SMD) except for C3 which has 2.2 nF (222J) printed on it. It seems hard to believe that this solution is cheaper than using a dedicated chip like the EM4095, but it probably is. Or maybe the design is older?
The processor is a W78E052DDG, a pretty standard 8051-clone by Nuvoton (formerly known as Winbond).
I only used the antenna from the kit (and of course the tags) for my experiments since I had the EM4095 chip on a break-out board and now that I am done, I am looking for an application for my "RFID proximity door entry access system". What about a cat door opener? Hmmm…
P.S. The RFID driver will be included in the Sceptre library. An update is scheduled with the December issue of Elektor (available half of Novembre). If you can't wait that long, just drop me a line.
I also received a request for RFID support and so I implemented a driver for the EM4095 transceiver (EM Microelectronic) that can read the tags you can buy for cheap on eBay (for instance).
To get me started I bought in Hong-Kong (through eBay of course) for 17.50 euros (shipping included!) a fully functional RFID proximity door entry access system with 10 tags and 5 badges. Only a week later the kit arrived.
This turned out to be a pretty nice product actually; its only downside is its cheap plastic housing that will probably not survive very long outdoors. Rain and intruders will not have a very hard time getting to the electronics.
Interesting about this unit is that it uses a "discrete" (well, sort of, compared to a single chip solution) radio, built around a 4069 and a 74393. I traced the circuit (see below), but I didn’t measure the capacitors (all SMD) except for C3 which has 2.2 nF (222J) printed on it. It seems hard to believe that this solution is cheaper than using a dedicated chip like the EM4095, but it probably is. Or maybe the design is older?
The processor is a W78E052DDG, a pretty standard 8051-clone by Nuvoton (formerly known as Winbond).
I only used the antenna from the kit (and of course the tags) for my experiments since I had the EM4095 chip on a break-out board and now that I am done, I am looking for an application for my "RFID proximity door entry access system". What about a cat door opener? Hmmm…
P.S. The RFID driver will be included in the Sceptre library. An update is scheduled with the December issue of Elektor (available half of Novembre). If you can't wait that long, just drop me a line.
Wednesday, August 25, 2010
Rayson BTM222 & BTM112 Bluetooth modules
The Sceptre has a Bluetooth module; in fact it was designed for using a BTM222 or BTM112 Bluetooth module from Rayson. These modules are cheap and easy to find on the internet. They do have one problem though and that is the lack of documentation. The official datasheet only shows one table with AT commands and that’s it. When I did my initial experiments with the modules, I managed to get them going, but I was never quite satisfied with how they were working. A few days ago I decided to give them another go and improve my driver. I spent quite some time googling and I did find some new information. The official documentation is still limited to the single table, but now I know that it is incomplete too!
The BTM222 & BTM112 are part of a large family of modules that are all very similar. Differences are mainly in TX power and integrated antennas or not. It is possible to find some more information by studying the datasheets of the related modules.
Commands not listed in the BTM112/BTM222 dataheet I know of so far are:
+++ – Switch from data mode to command mode (valid only when connected)
AT – Doesn’t do anything but should return “OK”
ATCx, x = [0,1,?] – Flow control (RTS/CTS) disable (0) or enable (1, default)
ATH – Drop current connection (valid only when connected)
ATIx, x = [0,1,2,?] – Information, 0: firmware version, 1: current settings, 2: RSSI (valid only when connected)
(Strictly speaking the ATI command was not undocumented completely, but it was partly lost when the PDF was made.)
ATLx, x = [#,*,8] – Baud rate, #: 1200, *: 2400, 8: 921.6k (0-7 were already documented)
ATO – Switch from command mode to data mode (valid only when connected)
ATSx, x = [0,1,?] – RS232 powerdown disable (0) or enable (1, default)
ATXx, x = [0,1,?] – Escape sequence disable (0) or enable (1, default)
Sparkfun sells the BTM182 which is supposed to have the same firmware as the BTM112. The accompanying documents on their web site list most of the above commands.
A delay of at least 50 ms is needed after each command before the module will accept a new one. This delay is much longer for the commands that reboot the module; after ATR0 for instance the module needs at least 3.5 seconds to recover. Several other commands cause module reboots too: ATC(0,1), ATH(0,1), ATO(0,1), ATZ0.
It is possible that the module gets stuck in some undefined state (try ATZ1) or that the serial port parameters are wrong and you do not know them. The only way to get the module out of there is to pull pin PIO4 high for at least three seconds.
My BTM112 gets stuck in master mode when the connection is broken and it will only respond to the AT command. The only way to get it going again quickly is to restore the connection or to use the PIO4 reset. It seems to become available again after a pretty long wait too. I did not observe this behaviour on the BTM222 even though both modules have the same firmware version 4.22 (which doesn't mean that they have the same firmware).
A typical master mode sequence for a virgin device could look like this (I’ve set de waits a bit long):
ATN=my device (16 characters max, space is allowed)
Wait 100 ms
ATP=6587 (set a PIN code of 4 to 8 digits)
Wait 100 ms
ATR0 – switch to master mode
Wait 3500 ms
ATO1 – disable autoconnect (only available in master mode)
Wait 3500 ms
ATF? – scan for remote devices (this only works when autoconnect is off)
Wait at least 60 s or until you receive "Inquiry End."
ATA1 – connect to the first device found
Wait until you receive “CONNECT 'xxxx-xx-xxxxxx'”
Do data transfer
+++ – switch to command mode
Wait 100 ms
ATI2 – get RSSI for remote device
Wait 100 ms
ATO – switch back to data mode
Wait 100 ms
Do data transfer
+++ – switch to command mode
ATH – disconnect
Wait until you receive “DISCONNECT 'xxxx-xx-xxxxxx'”
Etc.
Note that when you are in autoconnect mode (ATO0) the module may reconnect to the same remote device almost immediately after disconnecting with ATH.
This photo shows two Sceptre boards, one with a BTM112, the other with a BTM222. They are connected (both PIO7 LEDs are on continuously) and the BTM112 is the master. I connected a push button to PIO4 for reset testing.
ATZ0 does not reset all parameters, it resets only C, E, H, O, Q, R & X (I did not check the serial port parameters). RS232 powerdown, remote device addresses, friendly name & PIN code remain unchanged. They also survive power cycles, meaning that if the last used slave device has the same PIN code as the master and autoconnect is on then the master will connect automatically to the last used slave device. No commands to issue at all. This will also work if the modules swapped roles.
PIO5 pulses high when data is being transmitted, it is fixed high during reception. PIO7 provides status information. An LED may be used to visualize the status, but it may also be useful to connect them to your processor. Issuing an ATZ0 will make PIO5 & PIO 7 flash three times, but PIO8 only two before resuming normal operation. PIO8 seems to remain high during normal operation. This is what I observed for PIO7:
- Master idle (autoconnect on) – toggling at about 0.4 Hz (BTM222) or 0.5 Hz (BTM112)
- Master idle (autoconnect off) – fixed low
- Slave idle – toggling at 1.7 Hz (BTM222) or 4.6 Hz (BTM112)
- Connected – fixed high
Besides restoring the factory defaults (3 s press) PIO4 can also be used to reset/reboot the module with a short pulse. An even shorter pulse (6 ms) on PIO4 will cause a disconnect.
If you have any information not listed here, please let me know!
The BTM222 & BTM112 are part of a large family of modules that are all very similar. Differences are mainly in TX power and integrated antennas or not. It is possible to find some more information by studying the datasheets of the related modules.
Commands not listed in the BTM112/BTM222 dataheet I know of so far are:
+++ – Switch from data mode to command mode (valid only when connected)
AT – Doesn’t do anything but should return “OK”
ATCx, x = [0,1,?] – Flow control (RTS/CTS) disable (0) or enable (1, default)
ATH – Drop current connection (valid only when connected)
ATIx, x = [0,1,2,?] – Information, 0: firmware version, 1: current settings, 2: RSSI (valid only when connected)
(Strictly speaking the ATI command was not undocumented completely, but it was partly lost when the PDF was made.)
ATLx, x = [#,*,8] – Baud rate, #: 1200, *: 2400, 8: 921.6k (0-7 were already documented)
ATO – Switch from command mode to data mode (valid only when connected)
ATSx, x = [0,1,?] – RS232 powerdown disable (0) or enable (1, default)
ATXx, x = [0,1,?] – Escape sequence disable (0) or enable (1, default)
Sparkfun sells the BTM182 which is supposed to have the same firmware as the BTM112. The accompanying documents on their web site list most of the above commands.
A delay of at least 50 ms is needed after each command before the module will accept a new one. This delay is much longer for the commands that reboot the module; after ATR0 for instance the module needs at least 3.5 seconds to recover. Several other commands cause module reboots too: ATC(0,1), ATH(0,1), ATO(0,1), ATZ0.
It is possible that the module gets stuck in some undefined state (try ATZ1) or that the serial port parameters are wrong and you do not know them. The only way to get the module out of there is to pull pin PIO4 high for at least three seconds.
My BTM112 gets stuck in master mode when the connection is broken and it will only respond to the AT command. The only way to get it going again quickly is to restore the connection or to use the PIO4 reset. It seems to become available again after a pretty long wait too. I did not observe this behaviour on the BTM222 even though both modules have the same firmware version 4.22 (which doesn't mean that they have the same firmware).
A typical master mode sequence for a virgin device could look like this (I’ve set de waits a bit long):
ATN=my device (16 characters max, space is allowed)
Wait 100 ms
ATP=6587 (set a PIN code of 4 to 8 digits)
Wait 100 ms
ATR0 – switch to master mode
Wait 3500 ms
ATO1 – disable autoconnect (only available in master mode)
Wait 3500 ms
ATF? – scan for remote devices (this only works when autoconnect is off)
Wait at least 60 s or until you receive "Inquiry End."
ATA1 – connect to the first device found
Wait until you receive “CONNECT 'xxxx-xx-xxxxxx'”
Do data transfer
+++ – switch to command mode
Wait 100 ms
ATI2 – get RSSI for remote device
Wait 100 ms
ATO – switch back to data mode
Wait 100 ms
Do data transfer
+++ – switch to command mode
ATH – disconnect
Wait until you receive “DISCONNECT 'xxxx-xx-xxxxxx'”
Etc.
Note that when you are in autoconnect mode (ATO0) the module may reconnect to the same remote device almost immediately after disconnecting with ATH.
This photo shows two Sceptre boards, one with a BTM112, the other with a BTM222. They are connected (both PIO7 LEDs are on continuously) and the BTM112 is the master. I connected a push button to PIO4 for reset testing.
ATZ0 does not reset all parameters, it resets only C, E, H, O, Q, R & X (I did not check the serial port parameters). RS232 powerdown, remote device addresses, friendly name & PIN code remain unchanged. They also survive power cycles, meaning that if the last used slave device has the same PIN code as the master and autoconnect is on then the master will connect automatically to the last used slave device. No commands to issue at all. This will also work if the modules swapped roles.
PIO5 pulses high when data is being transmitted, it is fixed high during reception. PIO7 provides status information. An LED may be used to visualize the status, but it may also be useful to connect them to your processor. Issuing an ATZ0 will make PIO5 & PIO 7 flash three times, but PIO8 only two before resuming normal operation. PIO8 seems to remain high during normal operation. This is what I observed for PIO7:
- Master idle (autoconnect on) – toggling at about 0.4 Hz (BTM222) or 0.5 Hz (BTM112)
- Master idle (autoconnect off) – fixed low
- Slave idle – toggling at 1.7 Hz (BTM222) or 4.6 Hz (BTM112)
- Connected – fixed high
Besides restoring the factory defaults (3 s press) PIO4 can also be used to reset/reboot the module with a short pulse. An even shorter pulse (6 ms) on PIO4 will cause a disconnect.
If you have any information not listed here, please let me know!
Wednesday, August 11, 2010
Forget about the hardware and learn C
Many people are afraid of 32-bit microcontrollers, or even 16-bit ones. Why? Because they have lots of pins? Lots of registers? If you are an 8-bit PIC assembly language programmer, why do you think it would be more difficult to program a 32-bit controller in assembler? Or is it that the more powerful controllers are meant to be programmed in C instead of assembler? Many people are afraid of C (let’s not even talk about C++). I have been programming in C for too long now to understand why you would be afraid of C, but I do know that it scares many 8-bit developers and newbie programmers.
This is a shame because new controllers nowadays always come with a free C-compiler. It may be limited in some way, but it is free and gets you started. Also, these new controllers come with evaluation kits that are cheaper and cheaper. The MSP-EXP430G2 kit from Texas Instruments for instance costs only $4.30 and includes two (2) 16-bit RISC processors, a PCB with programmer/debugger and a USB cable. Now that’s value for money. Or what about the STM8S-Discovery kit from STMicroelectronics. True, that is a kit for an 8-bit controller, but it costs less than $10 and includes a programmer and a breakaway controller board with capacitive touch sensor.
Hardware is becoming so cheap that it is becoming much like the paper you write on. Unless you’re an artist, you hardly ever care about your paper, the back of an envelope is often good enough. And it will be the same with hardware. You should no longer care about the platform you are working on as long as you can get your application to work. If you learn a language that is supported by all platforms, you can use whatever processor you like instantly and you’re application will be ready much sooner. The language is the pen, write your article and when it is ready send it off to the printer. They will then reproduce your design in the best and cheapest way. They may even decide to change the microcontroller, which is not a problem as your code was written to be portable.
This is a shame because new controllers nowadays always come with a free C-compiler. It may be limited in some way, but it is free and gets you started. Also, these new controllers come with evaluation kits that are cheaper and cheaper. The MSP-EXP430G2 kit from Texas Instruments for instance costs only $4.30 and includes two (2) 16-bit RISC processors, a PCB with programmer/debugger and a USB cable. Now that’s value for money. Or what about the STM8S-Discovery kit from STMicroelectronics. True, that is a kit for an 8-bit controller, but it costs less than $10 and includes a programmer and a breakaway controller board with capacitive touch sensor.
Hardware is becoming so cheap that it is becoming much like the paper you write on. Unless you’re an artist, you hardly ever care about your paper, the back of an envelope is often good enough. And it will be the same with hardware. You should no longer care about the platform you are working on as long as you can get your application to work. If you learn a language that is supported by all platforms, you can use whatever processor you like instantly and you’re application will be ready much sooner. The language is the pen, write your article and when it is ready send it off to the printer. They will then reproduce your design in the best and cheapest way. They may even decide to change the microcontroller, which is not a problem as your code was written to be portable.
Thursday, July 29, 2010
Add a smartphone to your application
One of the biggest hypes of the moment is of course (or should I say still?) the Apple iPhone. I do not have one, so I do not have an opinion about it, but it seems that many users are crazy about it. This is due to all the non-phone things you can do with it. Recently several electronics related apps have come to my attention but I have my doubts about the usefulness of those. Reading a datasheet on a smartphone? Usually when I need a datasheet I also have a proper computer nearby so why bother using a smartphone for that? I must be missing something here.
But now I heard about an electronics app for iPhone that seems pretty cool, even to me. It is more than an app as it needs a piece of hardware to function. Actually, it is the other way around: it is a piece of hardware that needs the iPhone app to function. Now that is not exactly right either as it is a piece of hardware that can be controlled by the app. Let me rephrase this properly: it is a small computer module that uses the iPhone as a display.
That’s right, the DIL/NetPC DNP/9265 from SSV is an embeddable ARM9-module (Atmel AT91SAM9263) with 32 MB flash and RAM. If you need more, just add an SD card. To connect the module to its environment 3 UARTs, an I2C, an SPI, a CAN, a USB Host interface and several GPIOs are available. Smartphone access is over a 10/100 Mbps Ethernet port. The board runs embedded Linux with extensions developed by SSV.
The smartphone app is developed as a web application using only established Web standards such as HTML, CSS, JavaScript and AJAX. The Apple iPhone SDK based on (proprietary) Objective-C is not needed, meaning that the app can also work on smartphones running Android. Furthermore, installing the app on the phone does not involve Apple’s App Store, but uses simply the on-board Web server. This of course makes life much easier.
An OEM integration kit including the DNP/9265 with lots of tools and documentation is available for application developers. An example application that visualizes system resources and that lets you play with configuration data is preloaded. Communication between the module and the phone is over a 2.4 GHz Wi-Fi connection. In case you didn’t have one already, a WLAN access point is included in the kit.
I can’t wait to get one of these kits for evaluation. Ho, wait a minute, I don’t have an iPhone…
But now I heard about an electronics app for iPhone that seems pretty cool, even to me. It is more than an app as it needs a piece of hardware to function. Actually, it is the other way around: it is a piece of hardware that needs the iPhone app to function. Now that is not exactly right either as it is a piece of hardware that can be controlled by the app. Let me rephrase this properly: it is a small computer module that uses the iPhone as a display.
That’s right, the DIL/NetPC DNP/9265 from SSV is an embeddable ARM9-module (Atmel AT91SAM9263) with 32 MB flash and RAM. If you need more, just add an SD card. To connect the module to its environment 3 UARTs, an I2C, an SPI, a CAN, a USB Host interface and several GPIOs are available. Smartphone access is over a 10/100 Mbps Ethernet port. The board runs embedded Linux with extensions developed by SSV.
The smartphone app is developed as a web application using only established Web standards such as HTML, CSS, JavaScript and AJAX. The Apple iPhone SDK based on (proprietary) Objective-C is not needed, meaning that the app can also work on smartphones running Android. Furthermore, installing the app on the phone does not involve Apple’s App Store, but uses simply the on-board Web server. This of course makes life much easier.
An OEM integration kit including the DNP/9265 with lots of tools and documentation is available for application developers. An example application that visualizes system resources and that lets you play with configuration data is preloaded. Communication between the module and the phone is over a 2.4 GHz Wi-Fi connection. In case you didn’t have one already, a WLAN access point is included in the kit.
I can’t wait to get one of these kits for evaluation. Ho, wait a minute, I don’t have an iPhone…
Thursday, July 15, 2010
Microchip Application Library: GOL trouble
In a previous article I discussed the PIC32 Multi Media Board (MMB) from Mikroelektronika. Looking around a bit on the web searching for PIC32 related projects I came across the PIC32 Audio spectrum analyzer project by Andrei Mehiläinen. He used a PIC32MX360F512L on a TechToys PIC24 evaluation board (PIC24-Eval-Board, this board supports 100-pin PIC24 & PIC32) with an additional 320x240 TFT display board with resistive touchscreen and an SSD1928 graphics driver. Andrei’s system is very close to the MMB, the main differences are the processor (the MMB has a 460F512L), the graphics chip (an HX8347D on the MMB) and the way the pins are used. I therefore decided to port Andrei’s code to the MMB. This would be a good summer holiday project (being a nerd I always take a development system to the beach). This summer was going to be dedicated to PIC32 projects.
Studying Andrei’s code I soon felt the urge to improve it a bit, especially the user interface as Andrei’s system didn’t really have one. I first started drawing a grid based on MMB example code and then became serious about it by deciding to develop some generic user interface for measurement systems in the style of modern oscilloscopes. So I downloaded and installed the latest Microchip Applications Library (MAL) (v2010-04-28). Having never used them before, I also watched the web seminar about the GUI architecture of the graphics library. In the help files I found a tutorial explaining how to start a new graphics project and off I went.
In the beginning all went well, but when I wanted to add the library C-source files to the project I discovered that I was apparently not doing things the right way as the project would only accept assembler files. So I started all over again but this time using MPLAB’s Project Wizard and now I could go all the way up to trying to build the project. This is where things started to go really wrong: the tutorial code would not compile at all. Of course this was to be expected as the tutorial is for a PIC24 on an Explorer 16 board (yes it is, read the last sentence of the tutorial) and I had modified it a bit to use with a third party PIC32 board.
The first step to glory would be to get the Hardware Profile right. That was easy enough as I used one from the MMB example code. As mentioned before the MMB has an HX8347D (note the D) graphics chip and the Microchip library seems to support it (it knows the A and D version). It won’t compile however as brackets are missing all over the place (DeviceSelect/DeviceDeselect). Clearly this part of the graphics library was not tested properly before releasing it. I fixed this, but only to find out that I was now missing a definition somewhere and compilation would therefore still not complete. Comparing the new library to the (working) one that came with the MMB I noticed that the new library had some changes that required a definition that has something to do with GFX(E)PMP (now what is that again?). There are two possibilities that I tried both, and both gave me other (but different) errors. This is where I gave up (for the moment, I will continue since my holidays aren’t over yet).
Microchip has put a lot of effort in developing their Applications Library, but it is a shame that I am to dumb to use it. It would have been nice if they would have tested it better and if they had provided a working tutorial. Now I have wasted lots of time without getting anywhere. I now know the ins and outs of the graphics driver selection and other low-level GOL details, but I still haven’t been able to draw a single button. Surely it is all very easy, but why didn’t they explain it a bit better? Or maybe it only works properly on Microchip evaluation boards?
At the time of writing I have not figured it out yet, so if you know what I am doing wrong, please let me know. Also, if you happen to know where the API description is that is mentioned in the web seminar, drop me a line.
Studying Andrei’s code I soon felt the urge to improve it a bit, especially the user interface as Andrei’s system didn’t really have one. I first started drawing a grid based on MMB example code and then became serious about it by deciding to develop some generic user interface for measurement systems in the style of modern oscilloscopes. So I downloaded and installed the latest Microchip Applications Library (MAL) (v2010-04-28). Having never used them before, I also watched the web seminar about the GUI architecture of the graphics library. In the help files I found a tutorial explaining how to start a new graphics project and off I went.
In the beginning all went well, but when I wanted to add the library C-source files to the project I discovered that I was apparently not doing things the right way as the project would only accept assembler files. So I started all over again but this time using MPLAB’s Project Wizard and now I could go all the way up to trying to build the project. This is where things started to go really wrong: the tutorial code would not compile at all. Of course this was to be expected as the tutorial is for a PIC24 on an Explorer 16 board (yes it is, read the last sentence of the tutorial) and I had modified it a bit to use with a third party PIC32 board.
The first step to glory would be to get the Hardware Profile right. That was easy enough as I used one from the MMB example code. As mentioned before the MMB has an HX8347D (note the D) graphics chip and the Microchip library seems to support it (it knows the A and D version). It won’t compile however as brackets are missing all over the place (DeviceSelect/DeviceDeselect). Clearly this part of the graphics library was not tested properly before releasing it. I fixed this, but only to find out that I was now missing a definition somewhere and compilation would therefore still not complete. Comparing the new library to the (working) one that came with the MMB I noticed that the new library had some changes that required a definition that has something to do with GFX(E)PMP (now what is that again?). There are two possibilities that I tried both, and both gave me other (but different) errors. This is where I gave up (for the moment, I will continue since my holidays aren’t over yet).
Microchip has put a lot of effort in developing their Applications Library, but it is a shame that I am to dumb to use it. It would have been nice if they would have tested it better and if they had provided a working tutorial. Now I have wasted lots of time without getting anywhere. I now know the ins and outs of the graphics driver selection and other low-level GOL details, but I still haven’t been able to draw a single button. Surely it is all very easy, but why didn’t they explain it a bit better? Or maybe it only works properly on Microchip evaluation boards?
At the time of writing I have not figured it out yet, so if you know what I am doing wrong, please let me know. Also, if you happen to know where the API description is that is mentioned in the web seminar, drop me a line.
Subscribe to:
Posts (Atom)
