Pages

Total Pageviews

Thursday, October 30, 2014

I have been working on interfacing the PIC32MX250F128B with a small 2.2" TFT display from Adafruit. It's a nice little display that is fairly easy to communicate with, using SPI communication. The display I'm using is: http://www.adafruit.com/product/1480

Adafruit provides nice open-source libraries for their products. However, they are for Arduino and thus cannot be directly reused for the PIC32. I went through the library and ported it over for the PIC32, in C. I have attached my project file as a .zip file and you can download it to go through the library header and source files, as well as the demo code. I've tried heavily commenting the code so that it is self-explanatory.

As far as hardware goes, with the demo code, the pin connections for the display are:

BL (backlight): I left it unconnected, but you can connect it to 3.3V for backlight.
SCK: connected to RB14 on the PIC
MISO: left unconnected, since I'm not reading anything from the screen
MOSI: connected to RB11 on the PIC
CS: connected to RB1 on the PIC
SDCS: left unconnected as I'm not using the microSD card for this
RST: connected to RB2 on the PIC
D/C: connected to RB0 on the PIC
VIN: connected to 3.3V supply
GND: connected to gnd

The pins I used are defined in the code and you can easily change them as required.

So, the simple way of offloading the SPI update to the DMA module would be to let the DMA channel transfer data to the SPI buffer. The SPI module is configured for 16-bit data transfer (since the MCP4822 write command requires 2 bytes). This means that the cell size for the DMA channel has been set to 2 (2 bytes to transfer once triggered). The DMA transfer is triggered by a timer interrupt. Unlike the previous example where I used Timer 1 and its interrupt for the SPI transfer, here I use Timer 2. The reason for this is that, if I want the entire process to be offloaded from the CPU, the SS (Slave Select) or CS (Chip Select) also has to be done entirely in hardware. For that I used the Output Compare 1 module. To use the OC1 module, either Timer 2 or Timer 3 (or the combined 32-bit timer) has to be used. So, I just went with Timer 2.

Configuring the DMA module for transferring data to the SPI buffer was the simple part. I found the configuration of the SS/CS pin the more challenging part. The idea here was to use the OC module in "dual compare mode continuous output pulses" mode. The OC module in this mode generates continuous pulses - the output pin OC1 - which I used as CS/SS - is set high one PBCLK (peripheral bus clock) after the Timer value reaches OC1R; the OC1 pin is cleared one PBCLK after the Timer value reaches OC1RS. Since SS/CS is active low, I set ( (period register) - 4) to be OC1RS and a variable CSlength to be OC1R. CSlength was chosen to be 80% of the period register. What this meant was that. One PBCLK after the Timer reached the (period register - 4), the OC1 pin went low (CS/SS went low) "selecting" the DAC. After about 0.80*(period register) from there, the OC1 pin went high. This means that the CS pin is low for 80% of the period - it goes low a small time right before the DMA transfer happens and is raised high late enough, after the DMA transfer occurs. I determined that 80% the period was enough time since that is higher than the time required to shift out 16 bits of data at 20MHz SPI clock. See Fig. 2 below for an illustration of the operation of the output compare module in the "dual compare mode continuous output pulses" mode:

Beyond that, the idea is simple. There is a sine table that is the DMA source. The key thing to remember here is that the 12-bit data must be OR-ed with 0x3000 since that is required for the DAC (to set gain=1, shutdown = 0 and channel = A):

Since the entries in the sine table are of "short" data type (each element occupies two bytes), the source size (in bytes) is twice the number of elements. The destination source size is two bytes since I'm transferring two bytes to the SPI buffer register. The cell size is two bytes since the DMA channel has to transfer two bytes (16 bits) at a time to the SPI buffer register. The DMA configuration is:

A point of note is that, the DmaChnSetTxfer( ) takes in the virtual addresses of the source and destination, not the physical addresses. The virtual-to-physical address conversion is done by the function itself as opposed to it being required manually when doing register level operations (as done in my previous DMA example article).

To demonstrate that the DAC control is done with no CPU overhead, in the main( ) function, I have an infinite loop that is just toggling RA0. The output is checked on an oscilloscope:

Fig. 3 - RA0 toggle being demonstrated

Observe that the frequency of the square wave is 4.0MHz - the same that would be observed if all the PIC was doing was the pin toggling.

This also gave better performance than my previous experiment where I did not use DMA. The output sine wave has a higher frequency than observed before and this matches exactly as expected: 400kHz/32 = 12.5kHz as seen (see Fig. 1).

The rest should be very easy to understand and self-explanatory. If you have any questions or suggestions, feel free to comment!

Saturday, October 11, 2014

I found them to be neat little devices. In a small 8-pin PDIP package, the MCP4822 comes with 2 12-bit DACs, which you can easily configure over SPI. This was a great opportunity to get a simple PIC32 SPI application going. I worked on this today to see how fast I can get the DAC output going.

Here's the pinout of the MCP4822:

Fig. 1 - MCP4822 pinout (taken from datasheet)

The MCP4822 can be supplied a voltage in the range of 2.7V to 5.5V. Since I use 3.3V for my PIC32, I used the same 3.3V supply for the VDD for the MCP4822. Pin 5 is the active low signal LDAC that is used to synchronize the two DAC channels. When this pin is brought low, the data in the DAC's input register is copied to the output and both outputs are updated at the same time. I just had this tied to ground. VoutA and VoutB are the two output pins. The other pins are the regular pins for SPI communication - CS (active low) chip select, SCK serial clk, SDI serial data in.

The datasheet provides a nice diagram explaining the timing and pin functions very nicely:

Fig. 2 - Write command for MCP4822 (taken from datasheet)

The write command to the MCP4822 is a 16-bit wide command sent over SPI. Bit 15 (A/B) selects which channel you're sending data to: 1 signifies channel B, 0 signifies channel A. Bit 13 (GA) selects the gain. The MCP4822 has an internal 2.048V reference it uses for the DAC. So, that means that with a gain of 1, the maximum possible output voltage is 2.04975V (4095/4096 * Vref). If a higher output is required, the gain can be increased. The MCP4822 has a configurable gain of 1 or 2. When GA = 1, gain = 1; when GA = 0, gain = 2. Bit 12 SHDN is the shutdown signal. When SHDN is low, the output of the DAC is shut down. The 12 data bits from there on: D11 to D0 ([D11:D0], [bit11:bit0]) are the 12 data bits for the digital to analog conversion.

While I typically use the registers and configure them manually, I decided to use the Microchip plib (peripheral library) here for the SPI module. The peripheral library consists of a lot of low-level functions and macros that essentially require understanding the peripheral but just make the code nicer and easier to read.

I decided to clock the MCP4822 at 20MHz (max for MCP4822) to get quick data transfers.

The SPI module can be initialized using one of 2 options:
1) Using the OpenSPIx(config1, config2) and SpiChnSetBrg(spi_channel, spi_brg) functions
2) Using the SpiChnOpen(spi_channel, config, spi_divider) function

The code block above has code written using both the initialization functions (one is commented out). Essentially, the configuration is that SPI channel 2 is enabled as a master, it is configured for 16-bit data transmission, the SDI pin is disabled, it is configured for serial output change from active high (1) to active low (0) as required by the MCP4822 (see Fig. 2) and the clock divisor is set to 2 so that SPI clock = 20MHz.

The SCK pins for the PIC32 are mapped physically to the RB15 (SCK2) and RB14 (SCK1) pins (check pinout on page 4 in datasheet). The SDO and SDI pins are remappable pins and thus require you to map them to physical pins. The SDI pin here is unused since the PIC32-to-MCP4822 is a one way communication with the PIC32 as the master and the MCP4822 as the slave.

The datasheet provides the table for all the PPS (peripheral pin select) mappings. The relevant section for the SDO is:

Table 1 - PPS configuration for SDO

I decided to use RPB5:

PPSOutput(2, RPB5, SDO2); // map SDO2 to RB5

The connections I used for the MCP4822 are:

Fig. 3 - MCP4822 connections

The chip select / slave select line (CS as shown on the MCP4822 pinout, see Fig. 1) has to be controlled manually. (For a hardware-based processor-free control scheme, see PIC32 DMA+SPI+DAC : Analog output synthesis with zero CPU overhead.) This is an active low chip select signal. When data is being sent to the MCP4822, while the SPI transaction is occurring, the CS pin must be kept low. Initially I checked to see if there was a way the hardware would take care of that. I looked into the framed SPI mode. However, this did not serve my purpose. From what I've read, the framed SPI mode is an SPI mode where the clock is always output (instead of only during transactions as traditionally done). However, the hardware generates a low sync signal (by pulling CS low) before the data is transmitted from the PIC32. The problem here was that the CS pin was pulled low and kept low for one SPI clock period before raising CS high as data is transmitted out from SDO. This isn't going to work for the MCP4822 since the chip requires that CS be held low during the entirety of data transmission (see Fig. 2). So I just decided to use RA4 as the pin for CS. Before starting any transmission, I pull CS low in software and raise it high at the end.

Since I called this function from the ISR in my code, I decided to make it an inline function to eliminate function call overhead.

In my test code, I just wanted to see how fast an output I can get. So I clocked the MCP4822 at 20MHz and tried to maximize the frequency of the output signal I generate: I used channel A to generate a sine wave output and channel B to generate a triangle wave output. I used a timer (Timer 1) to control the timing and in the ISR, I just called the writeDAC inline function to generate outputs as required from two pre-generated tables.

You can clearly see the SPI clock during transmission here. From the measurement panel on the right you can see that the SPI clock is 20MHz. There are also 16 pulses you can count - since a write command to the DAC consists of 16 bit transfers. CH2, on the bottom, shows the data being transmitted. Since the first signal (leftmost) is a 1, and since this corresponds to bit 15, this is a snapshot of data being transmitted to DAC channel B.

While this was a quick test I did to test the PIC32 SPI and the MCP4822, this is in no means a complete evaluation of the MCP4822. For example, I updated the DAC more quickly than I should have, to push for speed, as this didn't give enough of a settling time. However, I was satisfied with the results and so, stuck with that. I will do some further testing on this later.

For more details of the PIC32MX250F128B SPI module, refer to the datasheet and reference manual. For more details on the MCP4822, refer to its datasheet.

If you have any questions, feel free to ask. Let me know what you think, in the comments section below!

Monday, June 23, 2014

I started working on a pure sine wave inverter based on the PIC32MX250F128B. The first stage was to just get the SPWM working and test that before proceeding to add the power stage, feedback and other control, etc.

This led me to some interesting observations regarding the PIC32MX250F128B interrupts, especially the use of the shadow register set and a related problem.

I set up Timer 2 to be the time base for sine wave generation
(DDS/SPWM) using OC1. In the Timer 2 interrupt, the duty cycle update request
is performed (OC1RS is updated). Timer 2 interrupt priority was set to
7.

This all worked fine. The initial ISR definition was:

void __ISR(_TIMER_2_VECTOR, ipl7) T2int(void) {.....}

However, when I used the ADC
(input from potentiometer for amplitude control - a start at implementing feedback), accessing any of the
ADC registers in the while (1) loop in main stopped the PIC32 from
working.

I then added a line of code in main to continuously toggle RA0 (PORTA bit 0). This would stop when trying to access the ADC registers as well. (It worked fine if I removed the code that accessed the ADC.) This meant that the core was being stopped. So, I thought that it might be some kind
of exception being thrown (?).

However, changing the timer 2 interrupt priority from 7 (which
I had initially) to anything else fixes the problem. My guess was that
something went wrong when the shadow register set was being used for
interrupt priority level 7 (?).

So I did some more tests and came up with this:

The
way I have the ISR defined initially selects the "AUTO" mode of selection where, I
believe, the compiler decides whether to use the shadow register set or
software for context save/restore.

Forcing the compiler to use the software context save/restore instead of the shadow register set seems to fix it:

void __ISR(_TIMER_2_VECTOR, ipl7SOFT) T2int(void) {.....}

I forced the shadow register set just to confirm:

void __ISR(_TIMER_2_VECTOR, ipl7SRS) T2int(void) {.....}

and sure enough it didn't work.

So,
since it worked with ipl6, my guess was that for ipl6 (and for any ipl
except 7), the compiler chooses software for AUTO, whereas for ipl7, the
compiler chooses SRS.

So, I forced the shadow register set on ipl6:

void __ISR(_TIMER_2_VECTOR, ipl6SRS) T2int(void) {.....}

and sure enough, it didn't work.

Forcing software for ipl6 fixes it (as does AUTO).

I looked through the errata of the chip and couldn't find
anything. (The errata is an interesting read.) I am also a little
surprised since I did have ipl7 running fine previously. Maybe something weird happens with a certain combination of peripherals
(?) that I unfortunately happened to use. I'll still see if I can find
this documented, and I'll have to check whether an exception is thrown and if so, what type. If nothing else, at least it was a nice, albeit frustrating,
lesson. Hopefully, it'll help someone else who might run into a similar problem.

UPDATE/SOLUTION: It turns out that the PIC32MX250F128B does not have a shadow register set, as mentioned in the datasheet. I seemed to have missed that while concentrating on the reference manual which talks about the shadow register set for the PIC32 series. Thus, from the point of view of my 'experiments', the lesson learnt could very well just be that when using ipl7, force the compiler to use software instead of the default AUTO mode (which may make the compiler try to use the shadow register set, which doesn't exist - explaining the problem I faced earlier).

Tuesday, June 17, 2014

I had long been thinking of designing a simple AC voltmeter but had
somehow never gotten to it. However, with school just ending, and me
going back to electronics, this was a neat simple yet useful circuit
that I felt I could just get done with in a day or two.

The
concept is fairly straight forward. Since I needed this only to measure
the mains AC voltage and the output voltage of the sine wave inverter I
was working on (based on the PIC32MX250F128B - more on this later), I
didn't need to do any "true RMS" measurement. All I had to do was to
convert the mains AC to DC, filter it and measure the peak voltage. Of
course this had to be scaled down to a safe range for the
microcontroller. The RMS voltage for a sine wave is equal to 0.707 (to 3
decimal places) the peak voltage.

The design was based
on the Microchip PIC16F676. However I realized that I didn't have any
in stock with me. So, I just used the pin-compatible PIC16F684. On the
software side of things, the difference between the code for PIC16F676
and PIC16F684 is just one line. (See source file attached below.)

The
variable resistor is adjusted so that the reading of my AC voltmeter
matches that of a commercial voltmeter (Extech MA640 DMM). This is a sort of calibration.

CAUTION: THIS CIRCUIT IS NOT ISOLATED FROM THE MAINS AC AND HAS THE POTENTIAL TO BE LETHAL. YOU MUST BE VERY CAREFUL IF YOU ARE GOING TO USE THIS DESIGN. DO NOT ATTEMPT IF INEXPERIENCED. I CANNOT AND WILL NOT BE HELD RESPONSIBLE FOR ANY DAMAGE DONE WHILE USING THIS CIRCUIT.

Tuesday, May 13, 2014

I've been testing the PIC32 DMA recently. The PIC32 has a DMA (direct memory access) module that allows the data transfer in the PIC32 without CPU intervention during data transfer - thus freeing up CPU to perform other tasks while the data is transferred).

First, I did a simple test to just see if it works (I've also done some DMA timing testing - I'll talk about them soon in another article). The first test was to just use the DMA module to transfer data from a constant array (from FLASH) to PORTA (LATA for output). This would be visually seen as LEDs connected to PORTA blinking.

The DMA module allows data transfer from a source to a destination without CPU intervention during data transfer. The data transfer can be triggered by any interrupt request within the PIC. An interesting point of note is that the DMA module maintains its own flags for detecting interrupt requests for data transfer start/abort requests. This is completely independent of the INT interrupt controller enable and flag settings/configuration.

Points of note on the DMA:

Data is transferred from the source register to the destination register upon a transfer request.

The source size and destination size registers define the size of the source and destination to which you want to transfer data. For example, LATA is a 32-bit register (typical for the PIC32). However, since I'm only planning to transfer data to the lowest byte in LATA (see code above), my destination size is one byte.

The cell size describes the number of bytes to transfer upon one DMA transfer request. For example, in my code I was transferring just one byte every DMA request (either 0x05 or 0x0A) - so the cell size is 1 byte.

The DMA transfer is complete when either a block transfer occurs or you abort the transfer. A block transfer occurs when the number of bytes equal to the size of the larger of the source and destination register sizes is transferred. So, in my code, a block transfer is when both byte 0x05 and 0x0A are transferred. So, that's two DMA cell transfers upon two interrupt requests (only one cell transfer occurs upon one interrupt request).

The source and destination addresses are PHYSICAL ADDRESSES, NOT VIRTUAL ADDRESSES used by the MIPS core. The reference manual mentions the easy translation between physical and virtual addresses: (Physical address) = (Virutal address) & 0x1FFFFFFF. Remember that when you point to a register address (eg &LATA), that returns the virtual address and not the physical address.

The DMA transfer is triggered by an interrupt request (IRQ). So, in the DMA event control register, you must specify which IRQ is to trigger the data transfer. To ensure that this IRQ triggers a DMA transfer, the SIRQEN (Channel Start IRQ Enable bit) bit (bit 4 of the DCHxECON register) must be set. Additionally, when you specify the IRQ in the event control register, make sure you use the IRQ # and not the vector #.

The maximum source size, destination size and cell size are all 65,535 bytes (wow!). You can transfer that many bytes on an event.

Saturday, April 5, 2014

The
PIC32MX250F128B has a myriad of peripheral features that makes this cheap little
28-pin 32-bit microcontroller extremely powerful. However, it does lack a
digital-to-analog converter (DAC). A simple approach to digital-to-analog conversion
is to use one of the PWM channels and then to use an RC low-pass filter at the
output.However, there
is another neat little feature of the device that can be exploited or rather
utilized to obtain a rather crude DAC – the analog comparator module. Rather,
the analog comparator reference module. The PIC32MX250F128B contains an
internal voltage reference module that was created to be used as a reference voltage
for the internal analog comparator module. However, it does allow you to output
this reference voltage to an output pin. Analog voltage output with digital control? Sounds like a DAC.The voltage
reference module is built off of a 16-tap resistor ladder network with two
selectable ranges – from 0 to 0.67 CVREF or from 0.25 to 0.75 CVREF. CVREF is
the reference voltage for the module and can be connected to VDD (or an external VREF+). Thus there
are 32 possible voltage combinations. However, there are some voltages present
in both ranges, and additionally, “interleaving” the two ranges does not give
a linear set of 32 values. Thus this cannot be used to achieve a full 5-bit
resolution DAC. Cleverly selecting the values from the two ranges can, however,
lead to more than 16 steps. 16 steps is the number of steps achievable from
either range.The stabilizing
time for the internal reference module is listed in the datasheet as 10µs.
However, this is defined as the time required to stabilize for a transition from 0000 to 1111
in the voltage selection bits (4bits = 16steps). This means that this can be
pushed to relatively high speeds (in the tens of kilohertz) pretty easily
depending on the range of the swing of the voltage.I have received
good results with frequencies in the tens of kilohertz. At about 100kHz
(10µs
between samples), I can see the waveform “curve” a bit but even then it doesn’t
look too bad and is definitely useable.Why use this as
a DAC? Well, it’s a nice little tool available to you. Consider the fact that
this outputs an analog value with no required additional filtering. Additionally,
if you don’t need anything that requires a high resolution (ie no need for a
high resolution DAC), this will allow you to leave a valuable output compare /
PWM channel to use for something else. If not for anything else, it’s just a
fun thing to explore.I have written a sample piece of code to test this. There are four modes of operation here:

DAC_Out mode - Output all the values of the DAC full range (32 steps) - this clearly illustrates the non-linearity I was talking about. (see Fig. 2 below) Observe the apparently linear region in the middle.

Recent Posts

Translate this blog

Search This Blog

Follow by Email

About Me

I am Syed Tahmid Mahbub, from Dhaka, Bangladesh, born on August 1, 1994.
Electronics is my passion and from class V, I have been learning electronics. I learnt and worked mostly on SMPS, power electronics, microcontrollers and integration of microcontrollers with SMPS and power electronics. I've used PIC and AVR microcontrollers - PIC 10F, 12F, 16F, 18F, 24F, dsPIC 30F, 33F, PIC32, ATmega and ATtiny, integrating them with various SMPS and power electronics circuits.
I have completed my Bachelor's degree from Cornell University (Class of 2017) in Ithaca, New York, USA, majoring in Electrical and Computer Engineering (ECE).
I am a member of the forum www.edaboard.com, where I am an "Advanced Member Level 5" (the highest level attainable) and also the forum allaboutcircuits.com, where I am a "Senior Member". I post to help solve electronics-related problems of engineers and engineering students from all over the world.
I love watching and playing cricket and football (soccer), and listening to music.
I am now a hardware engineer at Apple in Silicon Valley, California, USA.