paul@148 | 1 | = VGA Output Example (Dual-Channel DMA Transfers) = |
paul@148 | 2 | |
paul@149 | 3 | This example demonstrates the generation of an analogue [[VGA Signal Output| |
paul@149 | 4 | VGA]] signal from a PIC32 microcontroller using general output pins. It |
paul@149 | 5 | follows on from the work done in the VGAPIC32 project. The result is not |
paul@149 | 6 | entirely satisfactory: |
paul@148 | 7 | |
paul@148 | 8 | * Every fourth pixel is wider than the others, this apparently being an |
paul@148 | 9 | artefact of the DMA transfer mechanism. |
paul@148 | 10 | |
paul@148 | 11 | It might be possible to introduce some kind of delay and even out the pixel |
paul@148 | 12 | widths, but this has not been investigated with hardware. However, unlike the |
paul@148 | 13 | [[../vga-pmp|vga-pmp]] example, there is no accompanying signal to potentially |
paul@148 | 14 | orchestrate the staging of individual pixels at a slightly delayed rate. |
paul@148 | 15 | Potentially, the peripheral clock signal might be generated and processed to |
paul@148 | 16 | make such a signal. |
paul@148 | 17 | |
paul@148 | 18 | Unlike the [[../vga|vga]] example, this example employs two DMA channels for |
paul@148 | 19 | pixel data which are interleaved to investigate a potential remedy for the |
paul@148 | 20 | wide pixel effect. Unfortunately, despite each channel contributing every |
paul@148 | 21 | other word (or group of four pixels), the effect persists. However, the |
paul@148 | 22 | picture is perhaps more stable than in the [[../vga|vga]] example. |
paul@148 | 23 | |
paul@148 | 24 | One significant problem with this example is that scrolling causes the DMA |
paul@148 | 25 | channels to become ordered incorrectly. This does not affect the |
paul@148 | 26 | [[../vga-timer|vga-timer]] example which also employs two DMA channels. |
paul@148 | 27 | |
paul@148 | 28 | == Hardware Details == |
paul@148 | 29 | |
paul@148 | 30 | The pin usage of this solution is documented below. |
paul@148 | 31 | |
paul@148 | 32 | === PIC32MX270F256B-50I/SP Pin Assignments === |
paul@148 | 33 | |
paul@148 | 34 | {{{ |
paul@148 | 35 | MCLR# 1 \/ 28 |
paul@148 | 36 | HSYNC/OC1/RA0 2 27 |
paul@148 | 37 | VSYNC/OC2/RA1 3 26 RB15/U1TX |
paul@148 | 38 | D0/RB0 4 25 RB14 |
paul@148 | 39 | D1/RB1 5 24 RB13/U1RX |
paul@148 | 40 | D2/RB2 6 23 |
paul@148 | 41 | D3/RB3 7 22 RB11/PGEC2 |
paul@148 | 42 | 8 21 RB10/PGEC3 |
paul@148 | 43 | RA2 9 20 |
paul@148 | 44 | RA3 10 19 |
paul@148 | 45 | D4/RB4 11 18 RB9 |
paul@148 | 46 | 12 17 RB8 |
paul@148 | 47 | 13 16 RB7/D7 |
paul@148 | 48 | D5/RB5 14 15 |
paul@148 | 49 | }}} |
paul@148 | 50 | |
paul@148 | 51 | Note that RB6 is not available on pin 15 on this device (it is needed for VBUS |
paul@148 | 52 | unlike the MX170 variant). |
paul@148 | 53 | |
paul@148 | 54 | === UART Connections === |
paul@148 | 55 | |
paul@148 | 56 | UART1 is exposed by the RB13 and RB15 pins. |
paul@148 | 57 | |
paul@148 | 58 | === Data Signal Routing === |
paul@148 | 59 | |
paul@148 | 60 | For one bit of intensity, two bits per colour channel: |
paul@148 | 61 | |
paul@148 | 62 | {{{ |
paul@148 | 63 | D7 -> 2200R -> I |
paul@148 | 64 | |
paul@148 | 65 | I -> diode -> R |
paul@148 | 66 | I -> diode -> G |
paul@148 | 67 | I -> diode -> B |
paul@148 | 68 | |
paul@148 | 69 | D6 (not connected) |
paul@148 | 70 | |
paul@148 | 71 | D5 -> 470R -> R |
paul@148 | 72 | D4 -> 1000R -> R |
paul@148 | 73 | D3 -> 470R -> G |
paul@148 | 74 | D2 -> 1000R -> G |
paul@148 | 75 | D1 -> 470R -> B |
paul@148 | 76 | D0 -> 1000R -> B |
paul@148 | 77 | |
paul@148 | 78 | HSYNC -> HS |
paul@148 | 79 | VSYNC -> VS |
paul@148 | 80 | }}} |