Patent Description:
Exemplary embodiments pertain to the art of analog to digital data transfer systems, specifically to a system to acquire analog to digital data using N2HET and HTU.

External Analog to Digital Converters (ADCs) are used due to several advantages over internal ADCs such as higher conversion speed, higher resolution, improved accuracy, etc. As the speed of ADCs increase, the faster the interface (from microcontroller side) must trigger, convert data, detect changes in the signal, etc. These system requirements are often felt in demanding applications like motor control. The traditional way of acquiring samples from external ADCs include using a serial peripheral interface (SPI) bus and external memory interface (EMIF). Since SPI is a serial transfer method, it can be slow. This speed reduction can be made worse because the SPI clock is limited to certain speed on most of the microcontrollers (around <NUM>). Although EMIF is a parallel interface, it may not be suited to interface with all ADCs. The only way to use EMIF is through DMA to save CPU time for other critical tasks. An exapmple for using DMA for the data tranfer from an ADC to the CPU is disclosed in <CIT>. DMA bandwidth for EMIF may become limited for following reasons.

Micro Controllers using Direct Memory Access (DMA) peripheral can face a bottleneck in systems with demanding applications like continuous excitation. For example, some applications require up to six channels of DMA at a rate of <NUM> per channel. Further, DMA may be needed by several peripherals like SCI, I2C, etc. for their data transfer needs. Using the central processing unit (CPU) for such tasks can result in undue system interruptions, which can also introduce system unreliability.

Disclosed is the method which overcomes the limitations of SPI and EMIF for ADC conversion and acquisition.

In one embodiment, a method of converting and acquiring external analog data without central processing unit (CPU) intervention using high-end timer unit (N2HET) and High End Timer Transfer Unit (HTU) to overcome serial peripheral interface (SPI) and external memory interface (EMIF) limitations encountered while performing high speed transfers is provided, as claimed in claim <NUM>. The method includes connecting a conversion start pin, a chip select (CS) pin, a read enable pin, a converter busy pin and data pins of an analog to digital converter (ADC) with the pins of the N2HET. The N2HET is configured to perform ADC data conversion and acquisition by performing steps of: activating a conversion start signal on the CS pin until a deactivation of the converter busy pin; and generating an HTU request to transfer data from a data N2HET pin to a N2HET random access memory (RAM) unit via a data transfer channel and then from the N2HET RAM to RAM of the CPU.

Also disclosed is a non-transitory computer readable medium storing program instructions for performing the some or all of the above method.

Before describing embodiments in detail, an overview of two technologies associated with the present invention will be briefly discussed. The first technology is a reduced instruction set micro machine called a N2HET unit or timer. Many families of microcontrollers include a specialized micro-machine that operates on timer. Along with timers, two <NUM>-bit registers and three <NUM>-bit registers are available. Information stored in these registers can be manipulated. The information may be, for example, time data, event count data, or other data types. N2HET includes instruction memory that is typically initialized by the CPU or by a direct memory access (DMA) peripheral with the desired N2HET assembly program after a system reset, before the timer machine starts execution. The N2HET is supplied with a clock from the main source. The N2HET needs to maintain counters using registers, compare them with dynamically loaded values from the CPU, and make decisions such as toggling pins, triggering its dedicated transfer unit (HTU), reading pins etc..

The timer program is a set of instructions executed sequentially. Reaching the end, the N2HET program must roll to the first instruction so that it runs in a loop. The time for a loop to execute is referred to as a loop resolution period (LRP). When the N2HET rolls over to the first instruction, the timer waits for the loop resolution clock to restart the execution of the loop to ensure that only one loop is executed for each loop resolution period. The longest path through N2HET instructions must be completed within the loop resolution is the clock (LRP). Otherwise, the program will execute unpredictably because some instructions will be left unexecuted. This constraint creates a strong link between the accuracy of the timer functions and the number of functions (instructions) the timer can perform. Using these instructions, the counter can be incremented or decremented, registers can be manipulated, general purpose pins can be activated or deactivated, values on the pins can read, HTU requests can be generated etc..

The second of the two technologies is a high-end timer transfer unit (HTU). The HTU is similar to the Direct Memory Access (DMA) module but is a special transfer unit for N2HET. The HTU is like a local DMA to the N2HET module that allows data transfer to and from main RAM from and to the N2HET RAM.

Transfers are initiated with the help of requests generated by the N2HET program and configurable control packets. Transfers between N2HET and the main memory can be triggered by eight different HTU requests by N2HET. These requests are linked to and triggered by N2HET instructions conditionally. The control packets define address and transfer information. For example, the control packet defines the start address of the source/destination buffers, the N2HET instruction address location, the PIN address and the number of elements that need to be transferred. Once a request is triggered, it starts a frame transfer.

<FIG> depicts a block diagram of a High-End Timer Transfer Unit (HTU) request and transfer scheme <NUM> (hereafter "diagram <NUM>"), according to an embodiment. As shown in <FIG>, as described above, the diagram <NUM> depicts a HTU request having a plurality of frames <NUM>, <NUM>, <NUM>, and <NUM>. Each of the frames is depicted having two elements (e.g., element <NUM> (<NUM>) and element <NUM> (<NUM>)). A frame can contain one or more elements. Each new HTU request <NUM>, <NUM>, <NUM>, and <NUM> triggers the transmission of a frame. For example, HTU request <NUM> triggers frame <NUM>, HTU request <NUM> triggers frame <NUM>, etc. Each of the frames <NUM>-<NUM>.

The elements <NUM>, <NUM>, etc., are defined as <NUM>-bit or <NUM>-bit words of data. Although two elements are shown for each of the frames <NUM>, <NUM>, <NUM>, and <NUM>, it should be appreciated that any number of elements for each frame is possible. As an example, if only one field from a single instruction should be transmitted, the count of elements in a frame would be one. But if several fields from multiple instructions should be transferred with a single HTU request, the element count should directly correspond to a number of fields to be transferred.

<FIG> is a standard parallel read access timing diagram <NUM> for parallel read access signals of an analog-to-digital (ADC) converter. The diagram of <FIG> is a known as timing of a standard off-the-shelf ADC. Although the timing requirements of ADC devices differ, the idea of acquiring ADC data can be extended to most of the external ADCs available in the market due to the highly configurable nature of N2HET's interaction with ADCs. For example, a conventional ADC can convert and give out data in serial/parallel mode. When the ADC device is configured for parallel mode, it generally functions as shown in <FIG>.

Referring now to <FIG>, signal <NUM> depicts CONVST_A, CONVST_B, and CONVST_C, of a standard ADS8557 ADC conventionally available from Texas Instruments. The signal <NUM> represents rising edges of a signal initiating simultaneous conversion of analog signals at the inputs. Signal <NUM> represents a converter busy signal from ADC. The CS signal pin <NUM> is a chip select signal, indicative of a status output of the chip select input pin of the ADC. In this example, when the CS signal pin <NUM> is enabled (high) the interface is disabled. When signal pin <NUM> is low, the parallel interface is enabled. The RD signal pin <NUM> demonstrates a signal on a read data (read enable) input pin. When the RD signal pin <NUM> is low, the parallel data output is enabled, and when high, the data output is disabled. The DB signals <NUM> show the output data signal timing of channel pairs with respect to the pin inputs described above. The DB is a conglomeration of <NUM> data lines configured in parallel.

As shown in <FIG>, A <NUM>, B <NUM>, and C <NUM> are channel pairs. For example, data streams A0 and A1 (<NUM>), data streams B0 and B1 (<NUM>), and data streams C0 and C1 (<NUM>) are shown in <FIG>, where each data stream pair would always be sampled pairwise. Although outside of the scope of the present disclosure, the timing requirements of the particular device are matched to N2HET's behavior.

<FIG> is an exemplary pin connection table of N2HET1 pins connected to ADC pins. The N2HET has a total of <NUM> independently configurable pins (direction and pull can be selected). For demonstration purpose, N2HET pin <NUM> is connected to Conversion start (CONVST) pin of ADC, N2HET pin <NUM> to BUSY pin of ADC, N2HET pin <NUM> is parallel connected to Chip Select and Read Enable pins, N2HET pins <NUM>-<NUM> are connected to ADC data pins (DB) that give the converted data in parallel.

<FIG> is a block diagram of a connection between an N2HET peripheral <NUM> and an ADC conversion unit <NUM>, according to an embodiment. The connection is configured with the pin assignment shown in <FIG>. In the embodiment of <FIG> the configuration is represented in hardware. Accordingly, embodiments of the present disclosure cause the hardware to function in a more efficient manner by utilizing the parallel interface thus speeding the data transfer rate Embodiments described herein both improve the state of the art of ADC data transfers by providing for acquiring data with both N2HET and HTU protocols, also without the need of CPU to involve in the entire process thus improving the functionality of the hardware with which it operates.

<FIG> depicts an HTU transfer simulation, according to an embodiment. By way of an example, if three streams of analog data were required to be sampled simultaneously (e.g., CONVST_A that includes and CONVST_B). the chip select <NUM> and the RD signal <NUM> pins are tied together, hence only data A0, A1, B0, B1 come out on performing read accesses as shown in <FIG>. Also, the chip select signal pin <NUM> and the read enable pin <NUM> can be tied together as no minimum delay is required. Before the B1 channel 214B can be acquired, the system will start conversion. This ends after three cycles, as demonstrated on the read pin <NUM>, where the signal goes low three times, the third time being the transfer of the B0 channel 214B. One key aspect is that the present system may selectively transfer on DMA or with an HTU transfer, and the timing of the transfer is strictly controlled as demonstrated in <FIG>. It should be noted that if DMA is chosen, the system may directly transfer data from data pins of N2HET to a system RAM buffer (not shown) according to the pin assignment chart of <FIG>. HTU however may be slower than DMA.

Requests are divided into <NUM> stages as shown in <FIG>. In the first stage, the system acquires ADC data in alternate N2HET loop resolution periods when RD is made low on three different HTU requests (channel pair A <NUM> having channel A0 and A1, and 214A having channel B0). The transfer acquires data to N2HET RAM. The other stage is where previously acquired data is transferred from N2HET RAM to Microcontroller RAM this happens buffer <NUM> loop cycles later.

<FIG> is a flow diagram of the proposed method <NUM> for acquiring ADC data using N2HET and HTU, according to an embodiment. The transfer triggering scheme described with respect to <FIG> provides ample time for HTU transfers hence certainty in transfers.

The entire flow depicted in <FIG> will be run over and over again. After an initial starting step <NUM>, the counter A starts from <NUM>, as shown in block <NUM>.

As shown in block <NUM>, the processor increments a counter A by <NUM>, and resets counter A to <NUM> when it reaches <NUM>. This is done to start a new conversion and also as a safety measure so that if ADC takes too long to respond at block <NUM>, the N2HET can start a conversion request over again.

At the decision block <NUM>, the processor determines whether the counter A is equal to <NUM>. If it is greater than equal to <NUM>, the system activates the conversion, as shown in block <NUM>. By activating the conversion, data conversion from analog to digital begins.

The N2HET processor determines whether the counter A is equal to <NUM>, as shown in block <NUM>. When the counter A is equal to <NUM>, the processor generates an HTU request to transfer data from N2HET RAM to the system RAM buffer (actual microcontroller RAM), as shown in block <NUM>. This is the previously acquired data from ADC pins collected while executing the blocks <NUM>, <NUM>, <NUM>.

At decision block <NUM> the processor determines whether the counter A is equal to <NUM>, then deactivates conversion signal when A is equal to <NUM> (as shown in block <NUM>).

At decision block <NUM>, the N2HET determines whether the busy signal <NUM> is inactive (i.e., low voltage on the busy pin <NUM>). When the busy signal pin <NUM> is inactive, the system goes to the acquiring phase <NUM>. While the busy signal pin <NUM> continues to be active, the system continues to increment the counter A by <NUM> (block <NUM>).

At the acquiring phase <NUM>, the processor increments a second counter T by <NUM>, as shown in block <NUM>. Alternatively, at block <NUM>, the same incrementing instruction resets the counter T to <NUM> when it reaches <NUM> so that <NUM> counts account for activating Read alternatively, <NUM> counts account for deactivating Read alternatively and <NUM> for resetting A.

At decision block <NUM>, the system determines whether the counter T is equal to <NUM>, and resets counter T back to <NUM>.

At decision block <NUM> the system determines whether the counter T is equal to <NUM>, and returns to the reset block <NUM> if the determination is "yes".

When the system determines that the counter T is not equal to <NUM>, the system increments a third counter B by <NUM>. The same instruction resets counter B to be equal to <NUM> next time it is executed at block <NUM>.

At block <NUM>, the system determines whether the counter B is equal to <NUM> when B becomes <NUM>, the Read pin will be activated, which makes the external ADC output the converted data on the parallel pins (DB), then at block <NUM>, activates the read enable pin <NUM> if B is equal to <NUM>(by making the RD pin go low), and deactivates the read enable pin if B is equal to <NUM> (by making the RD pin go high).

At decision block <NUM> the system determines whether T is equal to <NUM>, and triggers the HTU REQ1 pin when T is equal to <NUM> (as shown in block <NUM>). During this step, the system transfers data between data from ADC pins to N2HET RAM. This will fetch the ADC Channel A0 converted data from N2HET data pins (same as DB pins of ADC) into the N2HET RAM.

At block <NUM>, when T is equal to <NUM>, the system triggers the high end transfer unit (HTU) REQ2 (fetching Channel A1 converted data) pin as shown in block <NUM>. If not, the system determines whether the counter T is equal to <NUM> at decision block <NUM>. When yes, the system triggers HTU REQ3 (fetching Channel B0 converted data), as shown in block <NUM>.

<FIG> depicts an exemplary output according to embodiments described herein. Referring now to <FIG>, signal <NUM> is a conversion signal, signal <NUM> is a busy signal, and signal <NUM> is a read enable signal. The conversion signal <NUM> is low until it is activated (signal high). At this point of going high, the conversion starts. After the conversion signal <NUM> goes high, it can be noticed that HTU transfers the data from N2HET RAM (same as external ADC data from previously acquired loops) gets transferred to system RAM.

The busy signal then goes high indicating that the ADC conversion is active. After a period of time, the busy signal goes low, meaning that the conversion is ready for transfer. Notably the conversion signal is still kept high as a safe measure at this point.

After the BUSY signal goes low, indicating that conversion by ADC device has finished, it can be noticed that Read Enable pin is toggled multiple times to acquire data and separate HTU requests are generated after the converted data is available on the N2HET pins.

Claim 1:
A method of converting and acquiring external analog data without central processing unit, CPU, intervention using high-end timer unit, N2HET (<NUM>), and High End Timer Transfer Unit, HTU, the method comprising:
connecting a conversion start pin (<NUM>), a chip select, CS, pin (<NUM>), a read enable pin (<NUM>), a converter busy pin (<NUM>) and data pins of an analog to digital converter, ADC (<NUM>), with the pins of the N2HET;
outputting a conversion start signal until a deactivation of a converter busy pin signal associated with the converter busy pin;
after the deactivation of the converter busy pin signal, toggling a signal on the read enable pin multiple times, each toggle making the ADC output converted data on its data pins;
generating a separate HTU request for each toggle of the signal on the read enable pin to transfer the converted data through data N2HET pins associated with the N2HET to a N2HET random access memory, RAM, unit, each data N2HET pin being connected to a corresponding data pin of the ADC;
transferring the data from the ADC through the data N2HET pins associated with the N2HET to the N2HET RAM unit with a data transfer channel (<NUM>); and following a subsequent activation of the conversion start signal
transferring the data from the N2HET RAM to RAM of the CPU.