Hello all,
here is a somewhat functional preview-version of the firmware that i am working on. It generally works already, but a few things are still missing, most importantly the menu/UI handling and structure. While i already have a menu system ready from other PIC projects, i still have to add it to this one.
Note that this is purely a preview thingy, meant to let you see in what general direction i am going with this. This also means that virtually none of the code is documented yet. Of cpurse it also means that certain things are rather messed up right now (for example the main() loop), and that other things will undergo quite some changes. One example of that is the state-machine logic of the power-manager. As explained in my previous post, i had too high supply voltages in use. That resulted in having to do some things in a rather messy way since i got only very small changes in the readouts (no surprise, since the tip was way too hot). Now that these issues are fixed, some parts of the power-manager stuff will get reworked.
That said, here are some of the main features of the firmware:
- Multi-language support (currently only English and German)
- Extensive logging output through the RS232 port
- Manual control or automatic (power-managed) control
- Up to 8 different setups can be defined and stored in the internal EEPROM. Each setting can be given it's own name up to 16 characters long
- Virtually every aspect of the firmware is configurable with these setups
The used micro is a PIC18F2620 running off the internal oscillator. The project is done using MPLAB-X, the used compiler is microchips C18. The IDE and compiler can be downloaded from the Microchip website free of charge.
The power-management is freely configurable and allows for a variety of power handling. For example, during initial startup the power output can be set to limited, normal or boosted. Exiting the startup phase can be done either by time, actual SWR reading or by monitoring the changes in the readouts and use a threshold for them. After startup it enters a heating/heated phase that monitors changes in the readouts. If those changes are below a given threshold after a given time, it will enter an idle state. It exits that idle state if a given threshold in changes in the readouts is reached and re-enters the heating/heated state.
After some time in the idle state, and with changes in the readouts below the threshold, it can enter a sleep state. In that state the output power is limited. It will wakeup once a defined change in the readouts is reached. If it wakes up, it can wakeup in normal mode or in boost mode, the latter speeding up thermal recovery. The boost-mode wakeup can be either timed, SWR dependant or again depending on a threshold in the readouts. If it stays in sleep, it can enter power-down mode after a given time. In that mode the RF output is turned off completely. In that state, using the rotary encoder/button will restart the power-manager by enetring the initial startup-phase.
Normal operation, sleep and powerdown can be indicated by the LCD's backlight. Indication can be either a fixed backlight level, a contnous fade-in/fade-out cycling of the backling, or by flashing it. The levels and times of these modes are, of course, configurable as well.
Besides these config-sets, there is a single main config that defines in which mode to startup, which language to use and which config-set to use.
One might ask why so many parameters, some of them with little relevance to the overall operation like the backlight stuff, are configurable. Well, because we can, that's why
I mean, it's always the same. Not making them runtime-configurable makes some people complain that they need to recompile the code to make changes to them. Making them configurable in turn makes other people complain that there are so many parameters...
In any case, there will be a nice menu-system that allows for easy configuration. Only a rotary encoder with pushbutton-function is then needed to control everything. The UI interaction can be either through the LCD or through the RS232. The latter will then allow for configuration as well. This way the configuration will be portable between units: export them by dumping it through the RS232, import them by feeding back that dumped data into the RS232.
Alright, that's all for now. Back to working on the code...
Greetings,
Chris