Running GCC VGA Demo on ASC+ Board

Lombard · 2014-05-24 16:01

I'm trying to get the VGA functionality to work on my propeller eval board (ASC+) in pure C. One demo I see using VGA that seems to use no PASM libraries is "pong" (from PropGCC demos), so I set out to make the seemingly simple code modifications to get it running on my hardware.

I changed the #define PINGROUP to 0, as I have my VGA SIP Adapter connected on pingroup 7..0, which is the only contiguous group of pins as specified in the VGroup section of _VCFG.

The VCFG register is set thusly:

_VCFG = 0x300000FF | (PINGROUP<<9); //where PINGROUP is 0

Resulting in a value of 0x300000FF ... VMode will be 0x01, the PLLA is expected to come from cog 0, VGroup is 7..0, and finally, FF for VGA mode. Beautiful! (as far as I can tell)

I went and investigated how the PLLA is set, which is

_CTRA = (0xD << 23);

CTRMODE (MSB of 0xD) becomes 0b00001, PLL internal, video mode, looks good to me. And PLLDIV becomes 0b101, so the PLL is going to end up being VCO/4 - I suppose I trust the author of this software, it sounds great to me.

So I've sort of reached the extent of my abilities in troubleshooting this. I don't see anything blatantly wrong, but I also don't understand everything I see. Could someone point out what other things are likely to need attention in porting the Pong demo to the ASC board?

kuroneko · 2014-05-24 17:54

Does SPIN/PASM based stuff work on the board, e.g. VGA_Text_Demo.spin using text.start(0)?

Lombard · 2014-05-24 20:20

I haven't gotten those demos to work either, although I haven't spent as much time looking through the code to make sure the hardware stuff is right. Do you think it would be a meaningful troubleshooting measure to try to get them running?

kuroneko · 2014-05-24 20:31

Lombard wrote: »

I haven't gotten those demos to work either, although I haven't spent as much time looking through the code to make sure the hardware stuff is right. Do you think it would be a meaningful troubleshooting measure to try to get them running?

I certainly do. I myself have the VGA adapter (16..23) so I know it works. Speaking of SIP and pin group 0, how did you connect it to the ASC+ (I can't see a clear way to plug it in directly)?

Do you see any LED response?

Martin Hodge · 2014-05-25 00:45

Remember that the ASC has current limiting resistors on the arduino headers. You'll need to solder blob the bypass pads for those pins on the bottom of the board.

LoopyByteloose · 2014-05-25 00:53

I realize this might seem frustrating, but the PropellerASC+ was created to work with Arduinio shields that use and expect 5VDC.

The Propeller video is set up for 3.3volt resistor ladders to provide the correct video output.

You can by-pass the resistors as suggested, but then your next Arduino shield might damage the board by providing 5VDC directly to the Propeller i/o.

It is up to you, but be careful with changing the PropellerASC+ and what you might desire in the future. There are better boards for studying video output of the Propeller in C, or Spin. Even a 40pin DIP Propeller might be a wiser choice.

IMO, save the PropellerASC+ for your Arduino shields.

Lombard · 2014-05-25 06:26

I bypassed the current limiters (should be easy enough to undo - thanks, ASC board designer!). Now when I run pong, the H and V sync lights on the VGA SIP light up briefly and then go out. My connected VGA monitor doesn't respond. So it would seem to me that the VGA SIP is happy, the code is pointing to the right pingroup, but... what should I look into next?

And Kuroneko, to connect the VGA SIP to the ASC board I had to create a funky ribbon cable with a header for the i/o pins, and two long flying leads for 3.3V and ground.

Martin Hodge · 2014-05-25 09:27

An alternative that will leave the Arduino headers alone is to use the AUX pins on the ASC. They do not have current limiting resistors and are intended to be used with pin group 16 - 23. See here for the pinout. (You can leave off the 3.3v connection if you don't need the LEDs on the SIP adapter to light.)

You can also get this which is an easy to assemble, all through-hole kit that provides VGA and stacks on top of the ASC without blocking the arduino pins.

Lombard · 2014-05-25 12:48

Those are some cool products! I wish I had seen them when I was making my orders originally! But at the moment I should have everything I need to get this to work, hardware-wise.

I have a DE-15 with a valid resistor ladder, that is connected to a pingroup that is also set in the VCFG register. Are there any other hardware considerations I need to make? I'm starting to think the issue is with this part of the video initialization routine, that is, setting up the Counter A frequency:

testval = (25175000 + 1600) / 4;
frequency = 1;
for (i = 0; i < 32; i++) {
  testval = testval << 1;
  frequency = (frequency << 1) | (frequency >> 31);
  if (testval >= clkfreq) {
    testval -= clkfreq;
    frequency++;
  }
}
 _FRQA = frequency;

Could someone point me to somewhere I can read what the rationale is behind why the FRQA is being set this way? Is there anything about this code that is hardware-dependent?

kuroneko · 2014-05-25 16:18

Lombard wrote: »

Now when I run pong, the H and V sync lights on the VGA SIP light up briefly and then go out. My connected VGA monitor doesn't respond.

What do you see when you run VGA_Text_Demo on pingroup 0? This demo really only has the pingroup dependency.

Lombard · 2014-05-25 16:44

Hm, I put in text.start(0), and gave it a whirl with

bstc ./VGA_Text_Demo.spin -L /opt/parallax/spin/VGA_Text.spin -p0

I don't have full confidence in using spin/bst(c,l), so there's the command I used, in case there may be other problems.

But the result is nil, I see no LED's on the VGA SIP adapter. :?

kuroneko · 2014-05-25 17:01

Try this (no space between -L and path):

bstc ./VGA_Text_Demo.spin -L/opt/parallax/spin -p0

You're basically using the wrong file as top level object.

When this works we can have a look at pong (in case it still doesn't work).

Lombard · 2014-05-25 17:22

I ran your suggested command and the result is better than nil, as before. With my naked eye, I see the V, H, and B0 (pin 0..2) LED's pulse on for a very short instant upon load, and then stay quiet until I run it again. The monitor doesn't respond.

kuroneko · 2014-05-25 17:36

Lombard wrote: »

I ran your suggested command and the result is better than nil, as before. With my naked eye, I see the V, H, and B0 (pin 0..2) LED's pulse on for a very short instant upon load, and then stay quiet until I run it again.

Odd, the command/program certainly works here (only ASC but basically the same). What I'm worried about is the short pulse (LEDs should stay on).

Does something like this work:

PUB null

  dira[0..7]~~
  repeat
    outa[0..7]++

Did you ever manage to run anything on the ASC+?

Lombard · 2014-05-25 17:59

I've gotten the propeller-load interactive terminal working, I can see serial traffic & send commands. The board isn't hosed in that respect.

The code you posted, if I slow it down with a

    waitcnt(8_000_000 + cnt)

Counts in a somewhat binary-like fashion, although the numbers are not valid binary (once it gets past 4, the numbers are actually wrong). The led's stop lighting up entirely after the 15th "count," at which point the led's are displaying 0b11000000, then they all go off for good.

kuroneko · 2014-05-25 18:02

Lombard wrote: »

Counts in a somewhat binary-like fashion, although the numbers are not valid binary (once it gets past 4, the numbers are actually wrong). The led's stop lighting up entirely after the 15th "count," at which point the led's are displaying 0b11000000, then they all go off for good.

That doesn't sound too good. Would explain the VGA failure though. Time to review the cable?

Lombard · 2014-05-25 18:27

Everything is groovy as hell as far as I can see. I measured continuity from the via's behind the solder blobs (on the ASC) to the solder joints of the VGA SIP header, and they are all as desired.

The way the counting takes place is very odd. I verified all of the led's with this code as well:

PUB null

  dira[0..7]~~

  outa[0] := 1
  waitcnt(8_000_000 + cnt)

  repeat
    outa[0..7] := outa[0..7] >> 1
    waitcnt(8_000_000 + cnt)

Not quite sure what I needed to use >> instead of <<, since we're taking 0b0000001, and turning it into 0b0000010, 0b0000100, etc.

But this code will light V, then H, then B0 (...), all the way up, in order.

kuroneko · 2014-05-25 18:32

Lombard wrote: »
PUB null

  dira[0..7]~~

  outa[0] := 1
  waitcnt(8_000_000 + cnt)

  repeat
    outa[0..7] := outa[0..7] >> 1
    waitcnt(8_000_000 + cnt)
Not quite sure what I needed to use >> instead of <<, since we're taking 0b0000001, and turning it into 0b0000010, 0b0000100, etc.

This is due the bit order being 0..7 instead of 7..0. Habit I guess, bit 23 (16..23) is right the way my boards are positioned.

So if single LEDs work why doesn't the counter (outa[7..0]++) work properly (regardless of bit order)?

Can you just light all of them (to eliminate a power issue):

dira[0..7] := outa[0..7] := -1
  waitpne(0, 0, 0)

kuroneko · 2014-05-25 18:41

See edit in #18, also, is your PLL still OK, i.e. does the test above run with _clkmode/_xinfreq set for 80MHz?

Lombard · 2014-05-25 18:45

Ah, I think you've found it. When I try to light all of them, only R1 and R0 are lit, and several of the others are only bright enough to see with the lights out.

Setting the PLL for 80MHz (I'm going to post the code below, it may be wrong) doesn't change the behavior.

CON 
  _CLKMODE = XTAL1 + PLL8x
  _XINFREQ = 80_000_000

kuroneko · 2014-05-25 19:00

Lombard wrote: »
Setting the PLL for 80MHz (I'm going to post the code below, it may be wrong) doesn't change the behavior.
CON 
  _CLKMODE = XTAL1 + PLL8x
  _XINFREQ = 80_000_000

Make that:

_CLKMODE = XTAL1 + PLL16x
  _XINFREQ = 5_000_000

or

_CLKMODE = XTAL1 + PLL16x
  _CLKFREQ = 80_000_000

Anyway, apart from messing up any clkfreq based delay you'd end up with 40MHz (assuming 5MHz crystal).

Lombard · 2014-05-26 06:10

So what is going on with my lacking power? I read that VGA signaling requires 63mA, VGA signaling and LED's together require 95mA. I have the VGA cable disconnected from the adapter, so lighting up all of the LED's should only take 32mA. I'm powering the board from USB, and I don't have any other power adapters to test. Could that really be the problem?

kuroneko · 2014-05-26 06:18

Lombard wrote: »

I'm powering the board from USB, and I don't have any other power adapters to test. Could that really be the problem?

Have you tried lighting different pairs of LEDs, then triplets etc? Just wondering what the connection here is (you mentioned R1/R0 are bright everything else is dim).

re: USB power, I use a QuickStart with human interface board (that's 16+2 LEDs) powered from USB and don't have any issues here (VGA work). Not sure what else to suggest except using a power supply (to eliminate a weak USB connection).

You could also run some I'm-alive code over serial and keep all cogs busy (this gives you about 60~80mA). If that's too much I'd expect some effect on the former.

Lombard · 2014-05-26 07:07

I can't figure out the pattern of what LED's can be lit with what other LED's. For example, I can light 0..1 and 2..3, but not 1..2. When I set 1..2 high, only pin 1 (H) LED lights up.

Also, if I poke the solder joint on the adapter with a piece of loose wire for either H or V, (while in sitting in indefinite waitpne) the corresponding led will light. This does not work for the other ones. There's no intermittence in the connection, so I'm not sure what's causing that, but there seems to be some electrical problems on the adapter for sure.

Lombard · 2014-05-26 11:16

Since this is starting to look like a hardware issue, I'm going to make another thread to continue the discussion and get it out of the GCC subforum. Thanks for your awesome troubleshooting guidance!

kuroneko · 2014-05-26 17:16

Now that this seems sorted make sure you move the paddle pins out of pingroup 0.

// INPUT PINS
#define LPINUP 7   /* if high, move left paddle up */
#define LPINDN 6   /* if high, move left paddle down */
/* if right pins are not defined, computer controls it */
//#define RPINUP 5
//#define RPINDN 4

Running GCC VGA Demo on ASC+ Board

Comments