Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Advice for SMD board design

  1. #11
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Re: Advice for SMD board design

    @JHinkle I never thought of an FPGA - it seemed like such an overkill. I just checked, and the smallest SPARTAN-6 looks like it's only $13 quantity 1. That's not ridiculous, probably 2x the cost of my simple design now. But I've never used Xilinx (but will some day). My board is so terribly simple it seems I should be able to do it with discrete logic. I have one clock that runs in very short bursts of 50MHz 50% duty cycle square wave (but of course the length of the burst doesn't matter, just the max freq), which is immediately scaled down to provide four clock phases (again, in bursts) of 12.5 MHz. Those four clock phases just drive octal DFF banks. It's so simple it's crazy - but I am not a high-speed (or medium-speed for that matter) board designer by trade so it's all a gamble. I bet there are patterns that a skilled board designer would recognize as to how to route an 8-bit bus to four octal DFF chips with minimal vias and crosstalk. I have to experiment and think a long while about how to best do that. So I just need to get it designed and assembled and try it and see how it goes.

  2. #12
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    484
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Quote Originally Posted by ags0000 View Post
    I was really surprised when I first looked at the original Octoscroller source, and found that it was using all GPIO lines. I really don't know how it worked reliably at all.
    This is easy.... the HUB75 uses a specific clock line. You set all the bits, then toggle the clock to latch them, set all the bits for the next pixel, toggle the clock, etc... There is no timing dependent part in any of it as long as the order can be maintained. If there is a delay, it doesn't really matter. The refresh rate drops a little, but for the most part the output isn't affected at all.

    Back to your BBB work - did you consider making any changes to the connectors/cables, or leave it as-is ("if it's not broke, don't fix it")?
    Not something I worried about at all. Since it was all working with the original Octoscroller design, I didn't bother changing it. That said, Ron did a new Octo design that buffered all the signals. In theory, that would allow longer cable lengths, but not something I've really seen needed. For the most part, for our case, the BBB is in the same enclosure as the P# panels so cables don't need to worry about the weather or anything.
    Dan Kulp

  3. #13
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Re: Advice for SMD board design

    @dkulp I haven't found a useful description of the HUB75 protocol. What I read made it sound like it's actually quite difficult and sensitive - only one row of pixels is lit at a time, and PWM has to be done manually by the controller/driver for blending all but the pure RGB colors.

    What is the maximum data rate (loosely clock rate) down the ribbon cables? Is it correct they are all single-ended (not differential/balanced) and is there a ground line (or more than one) in each cable? The info I saw indicated R1/G1/B1/R2/G2/B2/CLK/LATCH/A/B/C/D lines only.

  4. #14
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    484
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Quote Originally Posted by ags0000 View Post
    @dkulp I haven't found a useful description of the HUB75 protocol. What I read made it sound like it's actually quite difficult and sensitive - only one row of pixels is lit at a time, and PWM has to be done manually by the controller/driver for blending all but the pure RGB colors.

    What is the maximum data rate (loosely clock rate) down the ribbon cables? Is it correct they are all single-ended (not differential/balanced) and is there a ground line (or more than one) in each cable? The info I saw indicated R1/G1/B1/R2/G2/B2/CLK/LATCH/A/B/C/D lines only.
    You missed the OE (Output enable) line and a potential E line for 1:32 scan panels. That's 14 pins. The other two are ground. (and for panels that don't use C/D/E, they are likely tied to ground in the panel).

    No idea on the maximum data rate on the cable to be honest. Right now, we generally are hitting maximum rates of the chips on the panels. If we push things out too fast, the panels are ghosting. More recent panels purchased this year have actually been worse than panels in years past. I think the vendors are trying to drive costs way down and are using cheaper and cheaper chips that just cannot handle the higher speeds.

    From a protocol standpoint, it's relatively simple. The R1/G1/B1/R2/G2/B2/CLK lines are used as shift registers to clock out two rows of data, 1 bit per pixel. You then "latch" the row with the latch line. You then (if the row changes), set the row address with the A-E lines. Then turn on the row with the OE line and start a timer for a certain amount of time depending if it's the "high" bit or low bit or whatever. While the row is "On", you can start clocking out the next set of bits. That COULD be either the next bit for the same row or the high bit for the next row. When the timer triggers, turn off the OE to turn the row off. If you clock out the row before the timer triggers, you have to wait. The LATCH and ROW settings must be done when output is disabled. Repeat...

    What's interesting about it is that you can control the brightness by adjusting the times of the "On" triggers and keep all 256 shades. Actually, you can go to 10bit color or drop to 7 or 6 bit by outputting more or fewer sets of bits per row. (at the expense of refresh rates). I know the Pi code we use actually defaults to 12 bit color with a gamma adjustment table, but we set it at 8bit to keep decent refresh rates on larger panel counts.
    Dan Kulp

  5. #15
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    484
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Quote Originally Posted by dkulp View Post
    The R1/G1/B1/R2/G2/B2/CLK lines are used as shift registers to clock out two rows of data, 1 bit per pixel.
    One thought.... this part of the protocol we do at full speed with no delays. The shift registers seem to take the data as fast as I can set the GPIO's and toggle the clock. Due to the number of pins needed, this is obviously done via GPIO memory location writes so it's not the speed of the r30 stuff. It also has to check the timer, pull in the data, setup the GPIO writes and such so a lot more than just setting pins. I just checked the timing and its working at 24 PRU clock cycles per bit which includes the toggling of the clock line hi and lo.
    Dan Kulp

  6. #16
    Join Date
    Dec 2010
    Location
    SF Bay Area
    Posts
    782
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Well 8+ MHz is not to shabby. And the cables and connectors don’t seem to suffer from or cause signal problems? That’s a good sign. I’m surprised you can clock out bits that fast with all the processing that’s needed- particularly if I understood correctly that you need to sense the GPIO lines to see if they are set before clocking.

    It’s not as bad as I first thought though. I thought there was just one bit per color and for any non-primary you had to do the blending with bit-bang PWM. That would be a mess.

    Although only one row is enabled (lit) at a time, since each color has two signal pins (i.e. R1/R2,G1/G2...) does each on control a row, so actually two rows are lit at a time?

  7. #17
    Join Date
    Dec 2012
    Location
    Framingham, MA
    Posts
    484
    Post Thanks / Like

    Default Re: Advice for SMD board design

    Quote Originally Posted by ags0000 View Post
    Well 8+ MHz is not to shabby. And the cables and connectors don’t seem to suffer from or cause signal problems? That’s a good sign. I’m surprised you can clock out bits that fast with all the processing that’s needed- particularly if I understood correctly that you need to sense the GPIO lines to see if they are set before clocking.
    No need to sense the GPIO in this case. If you only use the gpio memory addresses, they go out in order, just may have slightly longer or shorter gaps. Thus, the clock is easy. The HARD part is the LATCH line to latch the row. If that is too close to the clock, not all the bits have cycled down the shift register or something and we get strange ghosting. Thus, for that one, I do the read just to make sure the clock has been fully output and then do the set. On the Pi, they "fixed" it by writing each GPIO write 2 or 3 times which creates enough of a delay.

    It’s not as bad as I first thought though. I thought there was just one bit per color and for any non-primary you had to do the blending with bit-bang PWM. That would be a mess.

    Although only one row is enabled (lit) at a time, since each color has two signal pins (i.e. R1/R2,G1/G2...) does each on control a row, so actually two rows are lit at a time?
    Kind of... depends on the panel type, but generally yes. 2 rows. For 1:8 scan panels, that means 1/8 of the rows are "on". So for 16 row panels, that's 2 rows. However, there are 1:8 scan P5 panels with 32 rows, so for those, it's 4 rows on at a time. There are 1:4 scan P10s (4 rows), 1:2 P10's (8 rows), etc... Those panels are all really tricky as you shift out multiple rows of data, and each panel vendor has there own way of doing it. Some do 8 pixels from one row, then 8 from the other, then back to the first row. Others do groups of 16, 32, or 64. I just recently found 1:2 scan panels that "zig zag" down 8 pixels of the 4 rows in a strange back and forth manner. This is where the main complication comes from in trying to support multiple panel types. That said, none of that affects the PRU code that shifts out the bits. That's all in the C++ code that sets up the data array for the PRU.
    Dan Kulp

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •