General Prop guidance for newbie
Dr.Digital
Posts: 15
Hello all. I've recently started a project that has motivated me to look beyond PIC, and I was (extremely) fascinated when my research brought me across the Propeller. As a hopeful future user, I'd be very grateful to hear from anyone who has tackled some of the concerns/goals Ive briefly laid out below. Overall, Im mostly interested in determining if Prop is the right chip for *this* particular job (before I embark on a retooling + learning curve).
1) My first question is in regards to VGA output. I've read quite a few posts (and examples) demonstrating the Prop's VGA output capabilities. My interest lies more along the lines of performance boundaries. I'll need something to support 640x480 with just a minimal color palette, even 16 would be fine, but I need to calculate the graphics in real time. I havent been able to find any coherent guideline on Props built-in video capabilities. I know it has some Im just not sure how far it can go. So, is this within range of the built-in processing, or am I in the land of custom routines (bit bangs)? And, should this fall outside the built-in capabilities, how much of the chip's "power" will reasonably be left over for processing of sensors/IO?
2) I've seen several posts allude to external RAM interfacing not being much help where Video rendering is concerned, seemingly due to the timing requirements of moving data to/from. Any thoughts or battle-hardened advice?
3) If I've read correctly, Props central memory space is only accessible via a type of time-slice process, is that correct? Does that mean that a COG can only access central memory on every 1/8th cycle (as in 8 cogs)? Is this a deal killer in time-sensitive processes, or is there something available along the lines of DMA to sidestep a hub-induced bottleneck?
Thanks in advance for any feedback or suggestions.
-mike
1) My first question is in regards to VGA output. I've read quite a few posts (and examples) demonstrating the Prop's VGA output capabilities. My interest lies more along the lines of performance boundaries. I'll need something to support 640x480 with just a minimal color palette, even 16 would be fine, but I need to calculate the graphics in real time. I havent been able to find any coherent guideline on Props built-in video capabilities. I know it has some Im just not sure how far it can go. So, is this within range of the built-in processing, or am I in the land of custom routines (bit bangs)? And, should this fall outside the built-in capabilities, how much of the chip's "power" will reasonably be left over for processing of sensors/IO?
2) I've seen several posts allude to external RAM interfacing not being much help where Video rendering is concerned, seemingly due to the timing requirements of moving data to/from. Any thoughts or battle-hardened advice?
3) If I've read correctly, Props central memory space is only accessible via a type of time-slice process, is that correct? Does that mean that a COG can only access central memory on every 1/8th cycle (as in 8 cogs)? Is this a deal killer in time-sensitive processes, or is there something available along the lines of DMA to sidestep a hub-induced bottleneck?
Thanks in advance for any feedback or suggestions.
-mike
Comments
The video hardware supports either one or two bits per pixel, but uses those as lookup values into a 4 entry table of what pins to enable on the output pin bank, which is in turn connected to a dac which produces the actual voltage levels for the device. So you will be limited to either 4 unique colors per 16 pixels, or two unique colors per 32 pixels, depending on which mode you choose. You could theoretically merge the output of multiple cogs to overcome this limit.
External RAM can be used, but to make it fast enough requires parallel access, which eats up pins quickly.
Hub ram (main ram) is accessible in time slices as you mention. I believe it's every 16 clock cycles, which translates to 4 instructions between accesses. (1 prop instruction takes 4 cycles). It's worth mentioning that the Prop has been run reliably at 100MHz using. 6.25MHz crystal. The extra speed might be useful for you.
The limited window for main ram access is generally not as big an issue as the limited amount of main ram, at least as far as video applications are concerned.
[FONT="]This probably sounds silly, but does Props built-in video processing require a dedicated COG to drive it?[/FONT]
yes it includes one or more cogs to create a TV or a VGA-signal. You don't have a complete GPU-section on the propeller-die.
As you have 8 cogs in most applications this doesn't matter. If you need more cogs use another propeller-chip as the $8 GPU
best regards
Stefan
clk | 0 ......... 32 |
hub | 0 ........ 16 | 0 ........... 16 |
cog 1 | inc tbl_ptr | write RAM data @ tbl_ptr | repeat....
cog 2 | inc tlb_ptr | write RAM data @ tbl_ptr | repeat...
so, within 32 clicks, the 2 cogs combine to write 2 sequential data segments? Surely I'm missing something on what would normally be a mutex lock on tbl_ptr?
My apologies for being so techincal...I'm just trying to get a good grip on how much of the prop is going to necessarily be dedicated to producing a 25MHz pixel-data throughput. This is probably one of the those cases were things become clear once you've actually gone "hands on" -- I just want to make sure I don't invest a lot of time/money retooling for prop only to find out my assumptions have been incorrect!
I'm not sure I'd have enough pins left over to pull that off. (I'm not even sure I'll have enough the way things stand). I'm going to have to use ext. ram somehow. Even at 2 bbp, there's just no way to fit 640x480 screen data into the prop.Depending upon the type of external ram (determined by throughput speed) I could be look at anywhere from 16 to 20+ pins. It seems Prop needs 5 to function, 8 for VGA display and I need some for sensor lines (at least 8, unless I multiplex them)....
Then again, using 8 cogs: 1 cog for vga display, 2 for ext. ram write, 2 for ext. ram read, just leaves 1 for handling the full sensot load (or chaining to a secondary Prop if pin-count allows). At least that's how I'm seeing things...but not have experience on prop, I'm probably missing something. Aside, this has got to be one of the most helpful forums I've come acrosss, so I'm not too worreid about lack of information.
Thanks again for your input.
If You have lots of bread boards, then maybe You could have a look at the Propeller DIP plus kit, $25.00
And to make that work, You would also need a Prop Plug, $15.00
The upper end is the Hydra or My favorite, the Propeller Pro Development Board.
Lots of choices depending on budget..
You should be able to meet your video needs (including external SRAM Read and Write) in 2 cogs. 25MHz pixel clock with an 80Mhz Prop is slow enough that the access speed should not be two much of an issue, especially as almost half of the time at 640x480 is spent in the blanking periods (though you do still have to remember to push out the sync pulses).
As to the HUB access each cog gets two out of 16 clocks (this is only enough time to write or read a single value of up to 1 LONG = 4 BYTES), so cog 0 gets the first two, cog 1 the next two and so on.
If you want to use two cogs, you could have memory for two scanlines. One cog writes a line, another cog reads / displays it while the first cog is generating the next line. Repeat until done.
It also depends a lot on what you're trying to display. Text is easy because you can store character definitions in ram and have a screen buffer that's just which character goes where. You can do graphics the same way by devoting certain "tiles" on screen to certain blocks in ram - you just pick and choose where you want "graphics" on the display.
After really looking into this thing, I'm starting to lean towards using a mid-high PIC for the VGA (since some of the Pics have ram interfacing onboard...not to mention a pretty significant bank of RAM to start with) and then utililize Prop's strong point of parallel processing (in a non-mutex fashion) to drive the sensors and UI logic.
Maybe I'm off base here, by it just appears that the Prop currently has 2 key limitations: pin count and rather large performance hit when needing to interprocess Hub memory. I can't see that those factors would necessarily be a detrement for most projects (at least that I've done), but its a rough combination to deal with when needing to do VGA (beyond 2bbp) and external RAM *on top of* facing the limited pin constraint...
http://www.xgamestation.com/view_product.php?id=52
It uses the Propeller for VGA and video, though. They don't seem to be very popular.
Aside, I came across some rather detailed posts regarding some bit-skewing some forms of mutex operrations. Not fully understanding how Prop works internal, only part of the discussion actually made sense, but is that something that you guys have seen/witnessed?
1) VGA in 640x480 at 16 colors
2) realtime vector graphics (estimate ~75%), text rendering (25%)
3) external RAM interfacing (I'd like to at least get enough headroom for double buffering)
4) at least 8 lines of sensor input/logic
5) 4 lines of user-interface controls (although this could be multiplexed if necessary)
Dr.Digital,
I only now had a bit of time to take a look at your thread.
Quick answer:
You cannot do what you want with a single propeller; something close to it is possible with two
Longer answer:
It will require a large effort on your part (as in many many man months of very specialized finiky driver and hardware development)
Even after it works, you may not receive the results you desire, as the line drawing speed to external memory will be limited by memory bandwidth; which greatly depends on how you design your external memory interface, and how good your PASM coding skills are with extremely touchy tight synchronization between probably all eight cogs on the graphics prop.
Cheap answer:
Buy a mini-ITX Intel Atom 330 / 510 / 525 based motherboard, it can easily handle your requirements.
Thoughtful answer:
I am assuming this is for embedding into future commercial designs of yours. For a project like this, the correct solution depends on many factors, one of which is your initial expected production volume, your projected yearly production volume, time available to develop and bring to market, and your budget.
You also need to quantify the performance requirements for the vector graphics; it may be beyond the means of the current propeller even if an entire propeller was dedicated to it.
The above factors will determine which solution is best for you - mini-ITX off the shelf motherboard, custom propeller board design by yourself, or having someone design a custom or semi-custom board using a Propeller or other appropriate electronics that meets your needs.
If you can't find any VRAM, fast page mode DRAM will work, you just need to address the output pixels yourself and multiplex between reading and writing. You'll need more than one chip, so you can output from one and change another.
I am banking on Propeller 2 providing me with an appropriate VGA and hopefully at least DVI output, with external SDRAM providing the frame buffer
Finally more pins!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Thanks again to all for the insight and guidance.
Cheers,
-mike
I've developed a commercial product that does bitmapped high rez graphics on the prop, but it was an insane PITA to get the drivers running and debugged.
Your desired specs, 640x480 with 16 colors per pixel, are not quite impossible on the latest revision of my board, however it would require 25ns or faster SRAM, crazy code, and there may not be enough cogs left over to do the vector drawing... which would not be very fast. Which is why I did not recommend you buying my board and embedding it in your designs.
FYI, 640x480, 16 colors, fast vector graphics, will be a piece of cake on Propeller 2 with some external SRAM.
The PIC24 doesn't have built-in VGA and I don't think that it can be implemented easily in software to meet your requirements. I'd use an FPGA with external RAM. You might as well implement a soft MCU in the FPGA, and dispense with the Propeller, if you go down that route. The whole thing can be prototyped on a low-cost FPGA board using free IP from OpenCores. You will end up with a cheap two-chip solution (plus FPGA configuration memory).
The biggest problem is the limited pin count, though I have had good results with using multiple Props to overcome this issue.
single chip video generator that can be easily controlled by any uC. I have
used the Propeller to fill this need even though it is not a single chip solution
as it needs an eeprom, some resistors and a xtal. If someone would develop
a true single chip VGA device that has everything it needs integrated within itself
and can be controlled by I2C or other similar simple protocol it would find a
market. It would need enough fast ram and flash to be practical.
Another useful tool for developers would be a cheap external video device that any
project could control. I developed a small device at my last workplace that contained
a prop and just a few other parts... resistors, micro-sd etc. It had a vga cable coming
out one end of the small case and power and data cable exiting from the other. It is
being used to provide a vga display for a few different data analyzer devices. It is a
video adapter with an internal data log that stores data on the sd card. The card
also holds a bunch of display data and depending on what device it is connected to
it conjures up the appropriate video displays. It is a smart video dongle.
While the prop is a not a perfect solution for this sort of thing it is cheap and can
be useful.
That said, when v2 comes out I'll probably eat 2-dimensional foods for a week and have to leave post-it note reminders to (occasionally) go to bed. I'm really looking forward to seeing what v2 can really do.
Holly - I think you're market assessment is spot on. I can just imagine a whole new breed of devices that it would make possible. It's no so much that it can't be done w/o said widget, because Bill's devices (and others) have done some amazing things, and could certainly be integrated as an add-on at some level. But, for those (like me) whose forte really isn't embedded design, it really does leave a pretty big void to stretch across.
Bill - I feel your pain. I needed an "introduction" to PIC to get me up to speed with its asm instruction set, dev tools, timing mechanisms and the likes, so I (laughingly) decided the BEST way I could learn would be to hammer out a PIC VGA driver. I can now say two things about that experience: 1) "OUCH" and 2) I should have known better. But, it's still nothing compared to what you must have gone through...and you (all) are certainly more talented at programming these little gizmos than I am.
Cheers,
-mike
You're right on both accounts...I stand corrected. I guess I'll be using FPGA, or waiting for PROP v2.
Perhaps I am a bit overly optimistic, but it seems the only additional hardware needed would be the resistor dacs for RGB and external memory to support the higher resolution and color depths.
After perusing the registers and other programming data I am pretty sure the software rather than the hardware where the alligators appear.
Leon may be right that an FPGA solution would be the simpler approach. If you go that route I would suggest including the pixel clock and data write signal so that it can be used for both VGA and direct connection to an LCD panel. If possible I would even suggest making all the standard resolutions available even if only at lower color depths for the higher resolutions.
Anyway, I'm toying with the idea of just bit-banging the signal (once again) using one of the 40-mips PIC. I did come across a project based out of Asia (called Elm or Eln?) that was a straightforward FPGA add-on for an MCU, so I'm sure it's a sound strategy. But, the more I think about it the more I feel like its going too far out of my comfort zone as I don't readily have the envirnoment set up to program one. I guess I'd rather spend the time getting hands-on with Prop (which I'll use for the signal I/O) than I would getting reaquanted with FPGA.
I know what you mean about spending time outside your comfort zone. In most cases better to work with what you know if possible.
I used to service terminals (VT100, ADDS, etc.) way back when, and there was a terminal that used one of the 8 bit micros to generate the video. The design was so elegant that I still remember the essence if not the details. Essentially it used an 8 bit micro to execute a series of NOP instructions that produced the addresses that scanned a horizontal line of pixels, and then the instructions that produced the horizontal sync, incremented the video line counter, and inserted any received character into the display buffer. The display buffer was an external memory chip(s) that held the data to be displayed.
I wonder if the prop video circuitry could be used in a similar manner to produce the least significant bits of a video memory address while an external counter that is incremented by the prop is used for the rest of the video address.
http://www.milkymist.org/
http://www.milkymist.org/socdoc/paper_overview.pdf
The code is all open-source, and could be adapted for a high-performance VGA controller.
Leon, that's an impressive system, however after looking at the price of the FPGA (spartan xc6slx45) the cost of the finished board would be at least a hundred dollars and possibly twice that in small quantities. It is overkill for what most of us want to do.
For myself I would be happy to have 8 colors at the commonly used 4x3 and 16x9 resolutions. A controller that provided 256 colors at the same resolutions the prop is capable of would be very useful to a lot of people. Being able to build it using a prop as the controller would be icing on the cake as far as I am concerned. As creative as the folks on this forum are I am sure the hardware design and software would improve rapidly.