Micro with DMA output engine?

larwe wrote:
> Ulf Samuelsson wrote:
>
>>>> AT91SAM9261 has LCD controller and built in 160 kB SRAM
>>
>> It has been in the lab since May last year.
>
> If it isn't at Digi-Key, I can't consider it. Sorry.

Pity, think it would do the job excellently.

>
>> Maybe it would make more sense to go with a CPU module
>> than to design your own H/W.
>
> I've got form factor constraints, unfortunately - I have to design my
> own board to fit a very unusual shape.

AT91FR40162 is at Digikey.
Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate SRAM.
If you run the FIQ + some kind of external buffer, you might be able to do
it.
Also contains a 2 MB Flash.
If you don't like BGA, then the AT91R40008 is the same part without the
Flash in TQFP-100.

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Jim Granville wrote:

>   You could try
> www.Altera.com
> www.Xilinx.com
> www.Lattice.com
>   and look there for FREE tools, and CPLD sections ?

I didn't think of Altera, but I started with Xilinx and Lattice, and
remember it's not quite as simple as just free software tools - I need
a reasonably priced JTAG pod (or whatever) also.

>   There are other solutions to your display problem, but I'll
> leave you to work that out yourself...

There are many solutions to any problem. Particularly when considering
my form factor, the "right" way to do it is to put everything in an
FPGA, but I don't have the skills and experience to do it this way. I'm
only considering a CPLD as a replacement for the discrete logic I'm
going to need (counters and misc. gates), which is how I've used them
in the past. Yes, it could all be done elegantly in VHDL but I'm only
at a rudimentary level of familiarity with the language; I think I can
get the project done faster using other methods.

larwe wrote:
> I didn't think of Altera, but I started with Xilinx and Lattice, and
> remember it's not quite as simple as just free software tools - I need
> a reasonably priced JTAG pod (or whatever) also.

I think Xilinx and Altera are the #1 and #2 respectively for FPGAs and
CPLDs.  The Xilinx tools are very good, I think.  They just released
version 8.1i of their Webpack free development suite.

In terms of configuration, Digilent (who make development boards for
Xilinx) sell a $12 cable:

http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable

Or Xilinx provide instructions and 'C' code to enable devices to be
programmed directly from a microprocessor (i.e. you could wire the ARM
to the CPLD's JTAG pins and program the CPLD from the ARM... if you can
fit the bitfile in the ARM flash).

See:
http://www.xilinx.com/isp/microprocessor.htm


FPGAs and CPLDs are a lot of fun.  I find verilog incredibly easy and
interesting (coming from a 'C' and assembly background with a
university digital systems education).

I develop my verilog with the Icarus verilog simulator and gtkwave vcd
viewer on Linux.  Then I migrate onto the Xilinx tools when I'm ready
to do more hardcore simulation and synthesis.


Good luck!

Paul.

In article <dqs24h$77g$1@domitilla.aioe.org>, ulf@a-t-m-e-l.com says...
> larwe wrote:
> > Ulf Samuelsson wrote:
> >
> >>>> AT91SAM9261 has LCD controller and built in 160 kB SRAM
> >>
> >> It has been in the lab since May last year.
> >
> > If it isn't at Digi-Key, I can't consider it. Sorry.
> 
> Pity, think it would do the job excellently.
> 
> >
> >> Maybe it would make more sense to go with a CPU module
> >> than to design your own H/W.
> >
> > I've got form factor constraints, unfortunately - I have to design my
> > own board to fit a very unusual shape.
> 
> AT91FR40162 is at Digikey.
> Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate SRAM.
> If you run the FIQ + some kind of external buffer, you might be able to do
> it.
> Also contains a 2 MB Flash.
> If you don't like BGA, then the AT91R40008 is the same part without the
> Flash in TQFP-100.

Perhaps you can answer this question for me:   Why does the part with
the internal flash   end up in the 121-pin BGA while the part with
external flash ends up in the 100-pin qfp?  That seems backwards to
me.   If you can put all the Flash and RAM in the same package, why
do you need the extra 21 pins?


Mark Borgerson
> 
> 

>> AT91FR40162 is at Digikey.

A later check says that while they have it in the catalogue, there i no
stock at the moment.

>> Contains ARM7 running at 66 Mhz from 256 kB 32 bit zero waitstate
>> SRAM. If you run the FIQ + some kind of external buffer, you might
>> be able to do it.
>> Also contains a 2 MB Flash.
>> If you don't like BGA, then the AT91R40008 is the same part without
>> the Flash in TQFP-100.
>
> Perhaps you can answer this question for me:   Why does the part with
> the internal flash   end up in the 121-pin BGA while the part with
> external flash ends up in the 100-pin qfp?  That seems backwards to
> me.   If you can put all the Flash and RAM in the same package, why
> do you need the extra 21 pins?
>

The Flash needs some specific signals.
VPP    If below 0.4V , then this is a write protect
NCSF    Flash Chip Select.    Ths chip select between CPU and Flash is not
internally connected
              This allows you to put the flash on any chip select.
NBUSY    Flash RDY/Busy
NRSTF    Flash Reset

So you need more than 100 pins.
Maybe the next larger size is 121 BGA.


>
> Mark Borgerson

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Paul Marciano wrote:

> In terms of configuration, Digilent (who make development boards for
> Xilinx) sell a $12 cable:

Thanks, that's exactly the kind of tip I needed.

> Or Xilinx provide instructions and 'C' code to enable devices to be
> programmed directly from a microprocessor (i.e. you could wire the ARM
> to the CPLD's JTAG pins and program the CPLD from the ARM... if you can
> fit the bitfile in the ARM flash).

I have plenty of room at the moment - but I'm not sure I want to waste
all that space since I might want to add more functionality to the main
uP.

> FPGAs and CPLDs are a lot of fun.  I find verilog incredibly easy and
> interesting (coming from a 'C' and assembly background with a

I started experimenting with VHDL a while ago - I have about eight
inches of books on the topic <g> - but haven't progressed very far.

larwe wrote:
> Hi Peter,
>
> > I did this with an LPC2106 originally but without DMA and under
> > interrupts. Believe me there is still a lot of processing time left for
> > other things.
>
> That's a very impressive little board! I believe my application can
> probably _just_ run in the blanking intervals - but it leaves me no
> margin at all. I'd rather be able to run with a closer to 100% duty
> cycle.
>
> If I can't find a micro with DMA, I'm going to build some external
> hardware - I haven't yet decided if it needs to be a "full" CRTC
> implementation or whether I will just have an external scanline buffer
> to take the DMA load off the CPU.

Hey Lewin,

Will an external scanline buffer leave you much time to do anything?

I seem to remember a thread in this group a while ago saying you'd be
hard pressed to do much more than a 5 Mhz write speed with an lpc2xxx
arm. Let's see a video scan line is about 87 uSec long and if you're
writing 256 bytes per scan line ... If you're writing a 16 bit word at
a time, it might take you 30 uSec to write out the scanline.

Well that doesn't seem too bad. You'll spend around 35% of your cpu
bandwidth writing out the video doing it a word at a time and around
70% doing things a byte at a time (simpler scanline buffer hardware).
Actually your overhead will be a bit less since there are vertical
blank regions during which the cpu doesn't really have to do anything.

Now the trick will be to find an FPGA to do the scanline buffer that
doesn't cost more than just doing a CRTC with a RAM and a handful of
counters.

Maybe you could do a hybrid system using a large external ram to do the
scanline buffer and use a cheap cpld to do the scanline counter. You
could reload the address in the counters every scanline during the
horizontal blank period. This would let you use the whole RAM as a
screen buffer. You can probably buy a 128K byte SRAM chip and a cheap
cpld for about what you'd spend for a fpga.

Mark

mhahn@hvc.rr.com wrote:

> Now the trick will be to find an FPGA to do the scanline buffer that
> doesn't cost more than just doing a CRTC with a RAM and a handful of
> counters.

The RAM-and-counters method is easier for me to wrap my head around, to
be honest.

There's kind of a long grayscale that stretches from:

* 100% CPU-driven output
* Single-scanline buffer, CPU generates sync timing and reloads line
buffer every scanline
* Entirely external video RAM, CPU generates sync timing and resets the
RAM counter only. CPU is allowed to update video RAM during blanking
intervals.
* Full CRTC doing everything

I could do (up to) 512 x 256 video very easily with a 128K SRAM and two
counters, if I just use the CPU to generate the sync.

larwe wrote:
> mhahn@hvc.rr.com wrote:
>
> > Now the trick will be to find an FPGA to do the scanline buffer that
> > doesn't cost more than just doing a CRTC with a RAM and a handful of
> > counters.
>
> The RAM-and-counters method is easier for me to wrap my head around, to
> be honest.
>
> There's kind of a long grayscale that stretches from:
>
> * 100% CPU-driven output
> * Single-scanline buffer, CPU generates sync timing and reloads line
> buffer every scanline
> * Entirely external video RAM, CPU generates sync timing and resets the
> RAM counter only. CPU is allowed to update video RAM during blanking
> intervals.
> * Full CRTC doing everything
>
> I could do (up to) 512 x 256 video very easily with a 128K SRAM and two
> counters, if I just use the CPU to generate the sync.

Actually I'd be sure there was some sort of blanking when you are
updating the video RAM. It's nice to do it during vblank, but if the
screen goes black for an instant when you do a major screen update it's
not that noticeable. Do they make DACs that have an output enable?

Hmmm ... you could use 8 bits of micro IO to do the row addressing, and
do the lower 9 bits of collumn addressing just using a simple counter.
You'd have to provide a clock for the counter. You could probably use
the hsync the micro generates to clear the counter. This would probably
require you to waste a few bits on either side of hsync to provide a
proper front and back porch.

Too bad they don't make the 74hc590 in a 9 bit counter (only 8 bits, so
you'll need 2). It has tri-state outputs. You could have the counter
and the micro share the 9 lines of collumn addresses. The micro would
set the counter into Hi-Z state when it needed to write to RAM. When
the counter was running, the micro would set its lines Hi-Z.

There's probably more to it than that. I'm having a hard time believing
you could do a video interface with a micro, clock source, 1 RAM chip,
2 counter chips and some sort of dac. But it'd be cool if you could.

I've had this weird notion for some time to try to do a video display
with a PIC, this might be a cheap way to do it.

Mark

larwe wrote:
> Paul Marciano wrote:
>
> > In terms of configuration, Digilent (who make development boards for
> > Xilinx) sell a $12 cable:

I would go directly with the Xilinx  HW-SPAR3-CPLD-DK.  They have
FPGA+CPLD together for $99, including a XC3S200 FPGA,
XC9500 CPLD, jtag downloader and CDs.  The 200K FPGA alone
cost over $20 retail.  The package is cheaper than all the components.

By the way, the FPGA kit has a hardware VGA port for three basic
colors (RGB).  I am sure you can modified it for additional colors.
If you need and want an micro within the FPGA, PPC cores are available
for the Virtex-4 series.