|
The software operates in a single loop which polls for serial data from the mic and parses it into actions (either tones or GPIO pulses).
It depends heavily on interrupts to allow a simple polling loop, real-time control system. The software supports UP, DOWN, and 4 “function” buttons as well as the standard 4x4 DTMF key layout. A 1KHz tone function is also provided. The status LED blinks when a key is pressed and is turned off when the microphone is muted.
There are three timer interrupts, and one Programmable Counter/timer Array (PCA) interrupt. The timer interrupts are all configured in a similar manner with timer 0 providing part of the bit-bang SPI function, timer 1 handles the code to process the DDS tone generator, and timer 2 provides a series of count-down-from-N-and-halt application timers. The PCA captures MDATA edges and parses them into a 32-bit result which contains information on mode and key-ID.
Timers 0 and 2 are not particularly engaging, they perform a simple task, in a simple manner. Timer 1 is a little more interesting but is still relatively straightforward. It implements a simple, 2-tone DDS generator that is phase-accumulator based (see NXP's AN1771 for a detailed treatise on the subject). For the DAC, one of the PCA PWMs is used, but not as an interrupt. The idea is that since timer 1 and the PCA run off of the same clock base, they will remain synchronized. This allows the DDS algorithm to write updates to the PWM without worrying about pop-noise that can occur if the update isn’t precisely aligned to the DDS sample clock.
The PCA interrupt is the most complicated ISR in this project. It captures timing edges and then parses them into 1’s or 0’s which are shifted into the result register.
The ICOM protocol uses a sync header to signify the start of a frame. For simplicity, the bit timing is hard-coded. A better solution would be to use the sync frame to
establish the timing reference and calculate the bit gates from the sync timing. While three microphones is not a fair sample, I am 3 for 3 at present, so dynamic sync frame
timing is penciled-in for a future embellishment.
A three-deep buffer is used to communicate the captured MDATA register up to the application level. This is a vestige of the original ARM application which featured a much deeper buffer. Three keys is likely overkill, but takes just a little memory and provides some leeway for unforeseen key-press scenarios.
The main application initializes the GPIO and peripherals, and then enters the main process loop (MPL). Actually, there are two nested loops in main(). The outer loop holds the initialization code, which is followed by the MPL. This allows the MPL to break out and essentially restart the main() function, facilitating a software reset. This is performed whenever the microphone detect signal indicates that the microphone has been removed. The most important artifact of this is that the PTT will be reset preventing the radio from being inadvertently locked into the TX state with the microphone no longer present.
Since this is a real-time system, it is important to limit how much time a particular operation can take. The judicious use of interrupts has off-loaded much of the low-level operations. The MPL must take the various inputs and act upon them. Some use of local timing loops is employed, but only where the time value is an isolated and short one, or there is some other means for breaking out of the timing operation. Since the application is relatively straightforward, the use of an RTOS was not viewed as an efficient option for such a small (8K) MCU.
The code is a bit complicated in the MPL. This is largely due to the fact that the system must accommodate two sources of PTT (a logic input, in the case of the HM-151, and
an MDATA message in the case of the HM-133) and also the behavior of the HM-133 when sending DTMF key codes. Oh, and the up to 8 different operating modes. Getting the HM-133
DTMF-S mode to work with the HM-151 hard-wired PTT was a bit of a challenge.
In addition, the microphone mute needed to be “sticky”, with a timer to cancel the mute after the appropriate span of time had elapsed from the last key release.
The logic PTT and microphone detect are processed at the top layer of the MPL. If a keypress is detected (as signaled by a new keycode being present in the input buffer),
the second layer is entered. This is where the key is processed. All of the keys on the HM-133/151 microphones repeat except for the HM-133 PTT. This fact is employed in the
software to detect when a key has been released.
For the purposes of this application, the keys on the microphone are grouped into two categories: DTMF keys, and function keys. The DTMF keys have multiple functions, depending on the state of the system. If the PTT is active, a DTMF key will issue the appropriate tone. If PTT is inactive, numeric digits are entered into an “accumulator” that can accommodate two digits that represent 99 or less. “*” or “#” set the status LED to be bright or dim. “*”, “#”, or the 4th DTMF row all clear the accumulator.
In the case of the HM-133, the microphone must be in “DTMF-S” mode to generate DTMF tones. In this case, PTT is not needed. The software detects the key and issues the tone. When finished, PTT is released, even if it is still pressed. Unfortunately, this is how the HM-133 works, to the best I can tell, so I haven’t found any way to improve upon the behavior. This isn’t an issue with the HM-151.
The accumulator is used when the UP or DOWN buttons are pressed. The system will pulse the appropriate logic output by the number of times defined in the accumulator (if the accumulator is “0”, 1 pulse occurs).
The object code for the adapter is available here. The "SiLabs Programming guide" describes
the steps and items needed to program the project MCU. The source code page describes where and how to access the source repo.
|
