J-Tech Engineering - Software and Firmware Expertise

Firmware Expertise

By working closeley with our customers and selecting the right device(s) for a given job, J-Tech can, and does, produce first-class firmware solutions. Some of the 'criteria' typically considered in the choice of microcontroller, DSP or FPGA are:

Is a true firmware solution required? If so, a programmable logic device (PLD), or a programmable gate array must be used. The nature of designs using gate arrays is such that unlike software, many things can, and do, happen simultaneously. The fastest possible solution is usually achieved by this approach.
Would a microcontroller or DSP based solution do in place of the above hardware solution? This requires pseudo-firmware, in the sense that although the code ultimately resides within the hardware, it is written in either assembly language, or higher level languages like C, or both. The down-side is that execution is linear, in that only one instruction can be executed at any given time. In the case of a DSP, several operations can happen simultaneously, however, what is written is software, as there is a thread of execution being performed by a processor. In the former case (of the FPGA), there is no program counter stepping through instructions, and instead data is processed in real-time. The upside to the processor based approach is that the code can generally be maintained more easily, and development can in many cases be less expensive.
Does the application require extensive computation, or is it limited to simple math such as addition, subtraction, and bit shifting? If the answer yes to extensive computation, a DSP may be better suited to the application. If, on the other hand, the application does not require more than simple arithmetic and doesn't require a large data space, a microcontroller will be a better fit. Microcontrollers come out the winner in a surprising number of applications. They are cheaper in their own right, plus they tend to be less expensive to develop with.

An illustration of low-level firmware code is shown below. The example depicts design expertise typically employed in our development cycle.

LRXRATE                       ;Generate counter values for bulk transfer mode.
  btfsc   _bulkrateflag       ;If the bulk channel flag was set,
  goto    LRXSTARTSTOP        ;then we come here.  This should
                              ;be the sample-rate setting byte.
  movf    _rxholdreg,w          
  sublw   _maxtxrate          ;If request out of bounds, reject.
  btfss   _c                  ;---bit set if result is positive.
  goto    LRXDATAEND			  

  movlw   HIGH(LRXRATE)       ;Setup pclath register for computed
  movwf   _pclath             ;goto.

  bcf     _c                  ;Ensure when we rotate, the lsb
  rlf     _rxholdreg,w        ;is clear.
  andlw   _lonibble >> 1      ;Mask off the three lsbs.
  addwf   _pcl,f              
  movlw   ((_adcsr * 3) / 1)  
  goto    LRXSTORERATE		  
  movlw   ((_adcsr * 3) / 2)  
  goto    LRXSTORERATE		  
  movlw   ((_adcsr * 3) / 5)  
  goto    LRXSTORERATE		  
  movlw   ((_adcsr * 3) / D'10')
LRXSTORERATE
  movwf   _bulkrate			  
  bsf     _bulkrateflag       
  return

A block of code from an embedded control application.

The code is written for a Microchip PIC processor. Comments are detailed enough that it may be interpreted without further reading. Documentation, as always, is critical to the success, portability and reusability of firmware developed for any project.

The above code shows a configuration function for an embedded control application. In the case shown, when this code executes, a decision as to whether valid data is present is made, followed by verification of whether or not the data is within bounds of what is expected. If all is well, the result is manipulated into a program branch offset. Once this has been done, the value offset is added to the program counter, and the branch is thus 'taken'. When the destination of the branch is reached, the desired value for the original calling function is loaded into the processor's accumulator, and a second branch is unconditionally taken to an exit point for the block. At the exit point, the freshly obtained results are stored, and the program returns to the main thread of execution.

The reader may notice that a little higher-level math appears to be taking place in the operand of some of the assembly language instructions. This arithmetic is computed at assembly time. The code that is actually programmed into the device will have a fixed number in place of the computation. The result of the above methodology is that the code is highly portable, and can easily be moved between processors in the Microchip family. A simple re-compile is all that is required to accomodate changes in processor clock-speed as well.

J-Tech Engineering is available to discuss any special coding requirements for your products. We find partnering closely with our customers produces the most effective designs possible. Our customers' successes are viewed as our successes. Please see the company information page for contact information.

<back>