Binary Pin Referencing

CumQuaT · 2011-07-19 17:18

Hi all,

I'm having a bit of difficulty understanding binary pin references. It's a problem I've had before and it's a problem I'd like to not have anymore, so perhaps someone could help me out a little.

I'm trying to re-work some code to run the gadget gangster 4.3" LCD touchscreen. Currently it works by connecting the VGA pins on the device into pins 16 to 23 on my propeller, and in the code, that is referenced with '%010_111, and it has the following notes attached to it on how to change the pins around:

CON
  'Here is where you define the pins you use to control the 3.5" LCD

  BackLightPin=26
  ResetPin=12    'reset
  PixelClockPin=25
  DataEnablePin=24
  TouchIrqPin=27   'This pin is really optional, but touchscreen sets this whenever screen is touched 
  VgaPins=%010_111  'Pins 16..23  This is the same syntax as used by the VGA driver

  
''  vga_pins
''
''    bits 5..3 select pin group:
''      %000: pins 7..0
''      %001: pins 15..8
''      %010: pins 23..16
''      %011: pins 31..24
''      %100: pins 39..32
''      %101: pins 47..40
''      %110: pins 55..48
''      %111: pins 63..56
''
''    bits 2..0 select top pin within group
''    for example: %01111 (15) will use pins %01000-%01111 (8-15)

I want the LCD to be connected to pins 8 to 15 (which is what they've done in the example there) but for some reason, when I change it to have the code VgaPins=%01111 it still won't work... Am I doing something wrong? The original code has an underscore in there, and the new one doesn't...

I feel a bit silly asking about this, but it's been driving me up the wall...

kuroneko · 2011-07-19 17:24

The reset pin is currently defined as 12 (8 < 12 < 15). Could that be an issue?

CumQuaT · 2011-07-19 17:27

I'm actually changing all of the pins, so that will now be pin 26

sorry about that. Should have updated that first. Nothing else will be assigned from 8 to 15.

Mark_T · 2011-07-19 17:42

Have you made sure DIRA is being changed accordingly?

CumQuaT · 2011-07-19 17:54

That is an excellent point... I might try that. Though the pins aren't used for anything else before this point, won't the Propeller assign that to them automatically upon first use?

Mark_T · 2011-07-19 17:58

I believe nothing sets bits in dira behind your back, and no pin can output till its relevant bit is set to 1 in your cog's dir register.

CumQuaT · 2011-07-19 18:05

I'll give that a go then.

So can I infer from your reply that by setting VgaPins to equal %01111 it will make it use pins 8 to 15?

kuroneko · 2011-07-19 18:05

The driver looks OK and generates the correct vcfg value for the pins you want to use. Can you provide your complete changes (especially pin numbers)?

CumQuaT · 2011-07-19 18:43

I'd actually prefer it if I could have binary pin referencing explained to me so that I can learn from this, rather than just be given an answer. How do they get pins 8 to 15 from a number like %01111?

kuroneko · 2011-07-19 19:05

CumQuaT wrote: »

I'd actually prefer it if I could have binary pin referencing explained to me so that I can learn from this, rather than just be given an answer. How do they get pins 8 to 15 from a number like %01111?

That's perfectly OK. But usually we find some clues in the surrounding bits (currently not shown). That said, what do your SPI pins look like? Anyway, the top 3 bits indicate the pin group (the current prop has 4 of them each holding 8 bits). The pin group is something required for video configuration. From your value we extract %001_111 which is pin group 1 (covering pins 8..15). The lower 3 bits (%001_111) indicate the top pin in the group, index runs from 0..7 which gives us base + 0..7 which in turn is 8..15.

CumQuaT · 2011-07-19 19:12

I think I see it... So rather than putting in %01111 like the example says, I should put %001_111 to clearly define the pin group and the head pin?

kuroneko · 2011-07-19 19:18

%01111 is the same as %001_111. The underscore just helps with grouping specific pins and usually increases readability, e.g.

%00000000000010000000000000000000          ' vs
%00000000_00001000_00000000_00000000

So where did you put your SPI pins (which is the only other interference I can see so far)?

CumQuaT · 2011-07-19 19:30

I'm at work at the moment and the project's at home, so I couldn't tell you off the top of my head. But I can tell you that no other pins have been assigned between 8 and 15 inclusive.

StefanL38 · 2011-07-20 02:39

for constant numbers you should define constants in the CON-section.

This is a little more work when coding first but pays off as soon as you have to change the value. Yiu change it only in one single place (the constant-definition) and everything is done.
Otherwise you have to go through the whole code changing it and you are in danger of forgetting some of them or put it to different values.

keep the questions coming
best regards

Stefan

Rayman · 2011-07-20 03:42

I think the problem may be the order of the pins... You cannot directly plug in the rayslogic.com (I'm assuming) 4.3" breakout board to the lower set of pins...

The reason is that the sync signals HS and VS are on the lower pins (16,17) and on the lower row that would be (8,9). But, you can see it won't connect that way...

You could make it work by either running jumper wires to the right spot, or changing the driver. I think either one is a pain, sorry.

CumQuaT · 2011-07-20 07:08

@Rayman - But couldn't I just re-code the LcdDriver module to reference the correct pins? That's what I'm trying to do. The default way of hooking that board up leaves the LCD board sticking out over the edge of the Gadget Gangster board, and I need it to stack neatly on top, so to do that it needs to use pins 8 to 15 for the VGA signals, rather than pins 16 to 23

Rayman · 2011-07-20 08:09

I think you could connect it to the upper row upside down, so it doesn't go over the edge.

But, the driver would require significant modification to use the lower row...

KMyers · 2011-07-20 09:04

Don't mean to hijack this but wanted to say good info here! I was a little unsure about the groups and start pins. Thanks for posting this..

CumQuaT · 2011-07-20 22:08

That really sucks... My entire project is built around the ability for the boards to be able to stack like they do in the picture on Gadget Gangster, but now I find out that the LCD driver is so hard-coded that you can't have the board wired up in any other way than hanging awkwardly off the side of the development board? It'll probably just be easier to rat-nest rewire it...

But surely there is someone who knows enough about the board or assembly to be able to help out here?

Rayman · 2011-07-21 06:31

Is using the board upside down an option for you?

CumQuaT · 2011-07-21 18:51

No, unfortunately. I think I'm fairly resigned to just re-wiring the 8 VGA pins in reverse order with a bit of rat-nesting... It seems to easiest way out of this jam

Rayman · 2011-07-22 06:11

Ok, sorry about that. If you don't mind, just out of curiousity, can you say why having the breakout board mounted upside down wouldn't work for you?

I may take another look to see how difficult it would be to change the driver...

CumQuaT · 2011-07-24 21:44

In a bit of a fail move, I assumed that I would be able to specify which pins I use for what purpose (since having the LCD driver board hanging off the side of the protoboard made no sense to me, logically) so I assembled the whole thing and custom-made the chassis before I found out about the mandatory pin alignment. So putting it in upside-down would leave the power pins hanging out of the end of the board which would stop the electronics fitting properly into the custom chassis I built

ericball · 2011-07-25 07:09

For the standard vga.spin driver you need to modify vmask & hmask along with your vga_colors table.

vmask                   long    $80808080
hmask                   long    $40404040

''  vga_colors
''
''    pointer to longs which define colorsets
''      number of longs must be 1..64
''      each long has four 8-bit fields which define colors for 2-bit (four color) pixels
''      first long's bottom color is also used as the screen background color
''      8-bit color fields are as follows:
''        bits 0..5: actual state of pins 0..5 within pin group*
''        bits 6..7: don't care (used within driver for hsync and vsync)
''
''    * it is suggested that:
''        bits/pins 0..1 are used for red
''        bits/pins 2..3 are used for green
''        bits/pins 4..5 are used for blue
''      for each bit/pin set, sum 240 and 470-ohm resistors to form 75-ohm 1V signals
''      connect signal sets to RED, GREEN, and BLUE on VGA connector
''      always connect group pin 6 to HSYNC on VGA connector via 240-ohm resistor
''      always connect group pin 7 to VSYNC on VGA connector via 240-ohm resistor

It is probably possible to modify other VGA drivers (although maybe not as easily).

Rayman · 2011-07-25 12:31

CumQuat, I'm working on a lower pin driver for you...

There's one main issue... The SCL and SDA signals are then on P2 and P3. You can't use the PropPlatforms SD card, if you have one, due to pin conflict.

<strike>Also, you'll have to add 10k pull-up resistors to SDA and maybe SCL.</strike>

It might be better to jumper SCL and SDA back over to pins P28 and P29.

Rayman · 2011-07-25 13:04

Ok, try this one and please let me know how it works for you.

Just don't try to use an SD card on P0..P3 at the same time...

Also, you may not need to add pull-up resistors in the I2C pins (but it would still be a good idea).

CumQuaT · 2011-07-25 17:12

Hi Rayman! Wow, thanks for that. I'm actually using the old model board (through hole), so there is no SD card slot on it and it is free. I'm at work at the moment, but I'll give it a while when I get back home and let you know how I go.

CumQuaT · 2011-07-26 02:05

Hi again, Rayman. That's works beautifully. Thank you so very much. You have saved me many headaches!

Binary Pin Referencing

Comments