With the Saleae Logic PC software (http://https://www.saleae.com), we have a very powerfull tool which is able to decode many protocols (I2C, SPI, Async, ...).
[attachment=0]
Very useful for debugging microcontroller firmware with a small budget.
May be an approach for you can be to start with an existing firmware such as UBW which is based on the pic18f2550. Then you get all the framework (including USB) and you can quite easily add new commands according to your needs. Link to UBW site : http://www.schmalzhaus.com/UBW/
The following schematic describes the wiring that must be added to the Flash Destroyer to use it as a PID based thermostat
[attachment=0] For the output to drive the boiler or the heater, 2 possibilities are described, the first one with a static relay which is ok for an AC load, the second one with a mechanical relay which can drive any type of load. The base resistor is 2.7kOhms (as the dot is not very visible on the schema).
The power supply is a standard AC adapter able to provide more than 7v (for example 9v) and a current greater than 500mA. It can be put close to the boiler and the DC power is provided via the wire to the Flash Destroyer. I have used an old cat5 network cable between the boiler and the thermostat and have used 1 pair of wires to send DC power from the boiler to the thermostat and an other pair to drive the solid state relay.
In fact i have choosen arbitrary the values for PID coefficients. And they have provided an efficient regulation. The room radiators have now a quite constant temperature and no longer a succession of cold and warm periods as it was with a simple thermostat. It is probably possible to improve the response by tuning the PID coeffs.
In fact my first attemp, before deciding to implement a PID, had been to build a simple thermostat on which i was able to set a small hysteresis and the result was still not as good as i expected. Then i decided to implement the PID. and i am very happy with the result.
I have installed one in my home and an other one in my father's house 2 years ago and we are both happy with it.
After trying a few commercial thermostats for my central heating (hot water), i was not really satisfied. They don't provide a smooth regulation. Then i decided to build my own one reusing my flash destroyer hardware board.
It has the following features : - PID based regulation - PWM with a 5mn period cycle to drive the on/off gas boiler - Up to 8 temperature sensors (DS18B20 or DS18S20) on a 1wire bus - Auto detection, at power up time, of all the sensors and sorting them according to their internal Id - Per sensor, compute mean temp value on 8 successive samples (each is 10 bits) then providing an enhanced measurement - Select the lowest temp among all sensors and use it as "measured temp" for the regulation - Setup values are stored in the pic eeprom - Displays temp of each sensor in °C (round robin) - Displays the percentage of time the heater is on in a PWM cycle - Displays via a blinking dot when heater is on ("on" period of the PWM cycle) - Direct change of temp setting via 2 push buttons (- and +) - Access to a simple menu to change some settings (P, I and D coeff, luminosity of the display) by pressing simultaneously both buttons
Some very limited modifications of the DP Flash Destroyer board are needed : - Remove the eeprom - Pin 6 of the eeprom support is used for the 1wire bus - Pin 5 of the eeprom support is used for the + button (other side to ground) - Existing button connection is used for - button. An external one can be put in parallel if you need to group + and - in a more convenient location - Pin 17 of the PIC18f2550 is used to control the boiler (was not used on Flash Destroyer)
My boiler is controlled directly via the AC mains then i have used a solid state relay, driven via a simple npn transistor plus 2 resistors.
Other types of interface can easily be buit, for example with a mechanical relay or with a power mosfet depending of the load you want to drive.
Some pics of the thermostat : [attachment=2] [attachment=1]
The firmware, after the initializations, enters a main infinite loop in which all "tasks" are sequentially activated when needed. Most of them rely on their own timer, implemented as a counter, which is decremented via the timer interrupt until it reachs zero.
The display is driven directly from the timer interrupt which ensure the digits multiplexing. The on state duration of each digit is adjusted (a given number of timer interrupt ticks) to allow to drive the luminosity according to the value set by the user (or to the default one).
For the PID, the P_coeff and the D_coeff are used as a multiplier. The I_coeff is used as a divider as the integral is based on the sum of the previous samples.
[attachment=0]
Your Flash Destroyer was probably sleeping in your drawer since many months. You can give it a new long life :)
Have you considered using a commercial cheap router such as the tp-link tl-wr703. You can find them for around 20$ on ebay (with the AC adaptor and shipping included). Multiple hardware upgrades have already been described.
You can install an openwrt (openwrt.org) linux package and lua is already installed and used to customize the internal web server to allow remote access.
Main features : 400MHz CPU, 4M Flash, 32M RAM, 1 RJ45 100 Mbps, Wifi, 1 USB otg, very small, low power required
I had to fully reflash my PicKit3 clone programmer and had no other programmer.
After spending a lot of time trying to use the BusPirate V4 PIC programmer (doc unclear of how to use it and which firmware and PC software to use. May be i missed something ...) i decided to go an other way.
Microchip provides on its site the PicKit2 source firmware and the hardware description, based on an 18F2550, is in the user's guide.
Then i decided to try to use the LCD backpack which has the same microcontroller as the basis for a lightweight PicKit2 programmer. In fact, the LCD Backpack is a quite full PIC18F2550 breakout board with a 20 MHz quartz.
The standard PicKit2 programmer application can be used on the PC side.
Changes in the firmware : - Locate the firmware just after the Diolan bootloader used on the LCD Backpack which is smaller (2kB) than the PicKit2 Microchip one (8kB) - Invert the MClr polarity as we have a direct connection to the targer rather the one via a transistor in the PicKit2 glue - Remove the Vpp regulation within the ISR (otherwise that generate an error as we do not have all the glue to generate Vpp) - Un-comment the lines that setup a pattern at the end of flash that tells the firmware is loaded (otherwise it asks to reload the firmware and we don't want that)
As we don't have all the glue around the pic, we have some limitations: - We can only program PICs in LVP mode as we don't have Vpp. That means the LVP config bit must be = 1 (default value of new chips). A PIC whose LVP config bit = 0 can only be programmed with a high voltage (Vpp), at least to erase the whole chip (and by the way the LVP config bit). Then take care not to program the LVP config bit to 0 if you want to be able to reflash it with this lightweight PicKit2. - Only 5V PICs and those which are 5v tolerant on digital pins (see datasheets) can be programmed - The target must use its own power supply as we don't have the glue to generate Vdd. For 5v PICs we can meanwhile use the LCD Backpack 5v (Vcc pin) to power the target - PIC detection does not work as it requires the high voltage (Vpp) mode which is not available with this lightweight PicKit2. Then use manual mode (select the pic family then the device) - In tools menu, set the "Use LVP program entry"
Connections with the target (ensure there is no incompatibility with your target hw) :
MClr/Vpp : LCD Backpack R/W pin connected to the target Vpp pin PGD : LCD Backpack D6 pin PGC : LCD Backpack D7 pin Vdd : LCD Backpack D5 pin, used only to sense the target Vdd Gnd/Vss : LCD Backpack Gnd pin Aux : LCD Backpack EN pin, used to connect to the target PGM pin for some PICs (ex : target 18F2550 RB5 pin)
I have used this programmer successfully with a few PICs : 12F1840, 18F2553 (with PGM RB5 pin), 24FJ64GA002, 24FJ256GB106 (Present in BusPirate V4 and in the PicKit3)
Note : It is also possible to use this lightweight Pickit2 on an UBW hardware with a 20 MHz quartz whose bootloader (B) is also 2k. To program it, please follow the instructions provided on the UBW site (replace the D firmware by the lightweight PicKit2 firmware) http://http://www.schmalzhaus.com/UBW/ The cabling is : MClr/Vpp :UBW RA5 pin of the 18F2550 PGD : UBW RA2 pin of the 18F2550 PGC : UBW RA3 pin of the 18F2550 Vdd : UBW RA1 pin of the 18F2550, used only to sense the target Vdd Gnd/Vss : UBW Gnd pin Aux : UBW RA4 pin of the 18F2550, used to connect to the target PGM pin for some PICs (ex : target 18F2550 RB5 pin)
In fact the problem is not in the Diolan bootloader but in the fw_update program on the PC side.
It was built for pic18f24xx or 18f44xx which have less flash memory.
Then, i have then decided to recompile the fw_update program in Windows XP environement.
It has been quite difficult as i have found no explanation ...
In the fw_update directory, there are many files that look like linux ones. Then i have had a first try with mingw without success.
Thanks to a file with a vcproj extension, i have decided to try with visual C++ compiler. The Microsoft Visual C++ express 2010 package can be downloaded for free from Microsoft site.
When i try to open the fw_update.vcprog project, i have been proposed to convert it in the 2010 format. This has worked quite well. When trying to compile, i have got an error for a missing include file (hidspi.h) supposed to be in the c:WINDDK directory.
After googling i have found this directory is associated with the Microsoft driver SDK. On Microsoft site i finaly found this SDK (release 7.1) for free. Quite long download as we must get a whole CD image (.iso). Then i have installed this SDK and found that many changes in the directory tree have been made since the fw_update has been done. After localizing the 3 needed files, i have updated the relevant lines in the pic_bootloader.cpp file.
Then i also changed the "BOOT_FLASH_SIZE" to 0x8000 to allow full access to the 32k bytes of Flash of the PIC18F2550.
New attempt to compile and new problem ... in file fw_update.rc
As the fw_update program is CLI only, i decided to remove it from the project and fortunately the compilation has been OK.
A few tests and that looks ok, i can load a large firmware in the 18f2550
Attached is the new "fw_update_32k.exe" file. I have added the 32k in its name to avoid confusion with the fw_update.exe. Normally, it should also works correctly with smaller flash 18F pic's.
[attachment=0] It can also be used with other DP projects which use the Diolan Bootloader such as the Flash Destroyer, USB infrared toy, logic shrimp ...
I wanted to load in the LCD backpack a firmware which goes behond 0x5fff. Then it appears that nothing is written between 0x6000 and the end of the program memory (0x7fff). No error is reported on the PC side.
The indicator in eeprom is still present => shows that an error has occured.
Is this problem already known with the bootloader ?
Among available commercial products, the cheapest is probably the TP-Link mini router tl-wr703n which can be found for 20$ on ebay (with AC adaptor and USB cable). It has a 400Mhz mips processor, 32 Mb RAM, 4Mb Flash memory, a USB2 host port, a 100 Mhz Ethernet port, a wifi 150 Mbps
It can be reflashed with openwrt linux firmware which brings a huge software library and possibility to develop our own software.
I would like to update the Bus Pirate SVN repository with the changes i made to support a fully integrated XSVF Player for BP4 and with the Windows associated application. I published these releases a few posts upper.
Can you please send me a password in order i can get access to upload my files.
I initialy tried to start from the JTR's 7 packages release but unfortunately, the BP4 release (before trying to add xsvf) was not working correctly. It is not identified correctly on PC side.
Then i decided to start from the SVN 6.1 official package.
All the changes i made are identified in source code and it should be quite easy to port them to an other release.
Just to add the following comments about my previous message :
- This integrated XSVF Player firmware is only compatible with BPv4 hardware. An other solution with a dedicated xsvf player firmware was already available for BPv3. - Windows application has been compiled with Dev-C++ - The "official" word in the firmware package name only stands for the initial 6.1 release used to build this new one
