Searching \ for '[EE] FPGAs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=fpgas
Search entire site for: 'FPGAs'.

Exact match. Not showing close matches.
PICList Thread
'[EE] FPGAs'
2008\10\20@184501 by Listas de Correo

flavicon
face
Hi, I need to make a device that will have to capture one frame of a
non standar video signal and store it in RAM, then pass that info to a
PC trough USB.
The signal should be sampled at 150MHz maximum.

We are considering using an FPGA, but since we never used one, we dont
know were to begin. I think the Cyclone III would be a good choice,
but any information that someone experienced can provide would be
really appreciated.

Regards,
Mauricio Jancic

2008\10\20@213117 by Shawn Tan

flavicon
face

1) Memory
Check to ensure that there is enough memory on the FPGA for your frame buffer
and that the memory _can_ be configured in such a way that you can use it for
your frame buffer. Sounds like you will need a two-port configuration at least
(one read port - USB out, one write port - video in).

Sometimes, although the RAM timings may be capable of handling 150MHz, but if
you need a larger block of RAM, this means combining multiple blocks of RAM
with logic and that may slow down the maximum speed.

2) Performance
150MHz is doable if your acquisition front end design is not too complex. That
being said, the C3 is a low-cost FPGA and if it does not meet your speed
criterion, you can always choose to use a higher speed part.

Best thing you can do is to design some basic blocks in HDL and then
synthesise it using the vendor tools to see if your design, can fit into your
selected part at the required speed.

3) Functions
Would you be manipulating your frame data within the FPGA itself? If you plan
to do some basic signal processing, you may need to look to see if the FPGA
supports DSP functional blocks. The C3 doesn't do much beyond multiplication.

4) Configuration
Would you need your design to be configured via internal FLASH or external
PROM or is your design going to be manually downloaded via JTAG each time it
is powered up? The C3 does not have internal configuration memory.

5) USB
You will need to incorporate a USB slave core to your design (look it up on
opencores if you don't have one). This is a rather complex design and may
affect your final speed and choice of device. You will also need to write some
drivers to support your device.

On Tuesday 21 October 2008 06:44:59 Listas de Correo wrote:
> Hi, I need to make a device that will have to capture one frame of a
> non standar video signal and store it in RAM, then pass that info to a
> PC trough USB.
> The signal should be sampled at 150MHz maximum.
> We are considering using an FPGA, but since we never used one, we dont
> know were to begin. I think the Cyclone III would be a good choice,
> but any information that someone experienced can provide would be
> really appreciated.

--
with metta,
Shawn Tan

Aeste Works (M) Sdn Bhd - Engineering Elegance
http://www.aeste.net

2008\10\20@214841 by Xiaofan Chen

face picon face
On Tue, Oct 21, 2008 at 9:31 AM, Shawn Tan <spam_OUTshawn.tanTakeThisOuTspamaeste.net> wrote:
> 4) Configuration
> Would you need your design to be configured via internal FLASH or external
> PROM or is your design going to be manually downloaded via JTAG each time it
> is powered up? The C3 does not have internal configuration memory.

Alternative: use a MCU (higher end) with enough Flash to interface with
the FPGA. the MCU can configure the FPGA. But I think a config PROM
or Flash will be easier.

> 5) USB
> You will need to incorporate a USB slave core to your design (look it up on
> opencores if you don't have one). This is a rather complex design and may
> affect your final speed and choice of device. You will also need to write some
> drivers to support your device.

Alternative: use a USB MCU for this task: eg: Cypress EZ-USB FX2LP
High Speed USB MCU or similar (NXP LPC-2888 family). I believe this
is more typically used.


Xiaofan

2008\10\20@215455 by Xiaofan Chen

face picon face
On Tue, Oct 21, 2008 at 6:44 AM, Listas de Correo <.....listasKILLspamspam@spam@janso.com.ar> wrote:
> Hi, I need to make a device that will have to capture one frame of a
> non standar video signal and store it in RAM, then pass that info to a
> PC trough USB.
> The signal should be sampled at 150MHz maximum.
>
> We are considering using an FPGA, but since we never used one, we dont
> know were to begin. I think the Cyclone III would be a good choice,
> but any information that someone experienced can provide would be
> really appreciated.

I do not know too much about FPGA (other than knowing that it is
getting more and more important). But last year I attended the
Xilinx/Avnet X-Fest seminar and it seems that typically this is
done with higher-end FPGA like Virtex 4/5.
Reference for the X-Fest:
http://www.fpgajournal.com/news_2007/08/20070815_01.htm

Xiaofan

2008\10\20@221648 by Sean Breheny

face picon face
I just want to warn you based on some recent experience that making an
FPGA design work reliably is not easy. Using one is not like
programming a microcontroller, it is more like designing a circuit. I
don't know your experience level, but you did say that you've never
used an FPGA before. This might not be the best project to use for
learning as it is fairly challenging. I'd recommend that you get a
demo board and play around with some easier stuff first.

As one example of a gotcha, I wrote VHDL which implemented motor
driver logic on a Lattice Semi FPGA. Part of it included a keepalive
detector which would shut down the motor if a 50Hz signal (+/- 10%)
was not present on one pin. Everything seemed to be working great with
the first prototype. Then I made several test units and ran them for a
while. Once in a blue moon, one or two of the units would decide
momentarily that the 50Hz signal was absent when it wasn't. The
problem was also temperature dependent.

In the design, my main clock was 1MHz. To make the numbers smaller in
the 50Hz decoder, I ran the 1MHz clock through a divide by 100 unit
(in the FPGA) to produce a 10kHz clock for the 50Hz decoder module.
Because the 1MHz clock was routed through primary clock routing
resources and the 10kHz clock passed through a functional block first,
their edges could drift apart by a few nanoseconds. This was enough to
cause some logic pathology by circuits which were synchronous to the
1MHz clock and which checked the output of the 50Hz module, or perhaps
problems with 1MHz-clock-sync'd signals entering the 50Hz module. It
was something like metastability. I had to fix it by running
everything directly from the 1MHz clock.

There are tools to check timing inside the FPGA and the FPGA's
internals are well spec'd, so it isn't as hard as, say, designing most
analog circuits, but it isn't as easy as micro programming, either.

It also takes a while to get your head around VHDL or Verilog. They
work like programming languages but they aren't really. They are a
means for describing what you want the FPGA to do, but the way you
structure your logic will alter how it gets implemented in important
ways.

Sean


On Mon, Oct 20, 2008 at 9:54 PM, Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:
{Quote hidden}

> -

2008\10\20@225340 by John Day

flavicon
face
At 06:44 PM 10/20/2008, you wrote:
>Hi, I need to make a device that will have to capture one frame of a
>non standar video signal and store it in RAM, then pass that info to a
>PC trough USB.
>The signal should be sampled at 150MHz maximum.
>
>We are considering using an FPGA, but since we never used one, we dont
>know were to begin. I think the Cyclone III would be a good choice,
>but any information that someone experienced can provide would be
>really appreciated.

Cyclopne-III is probably a reasonable choice. The Altera tools are
comparatively easy to use if any FPGA toolchain can be said to be
easy to use. We use Lattice Semi, Xilinx and Altera and those of us
who have to do the VHDL far and away prefer to use Altera.

Apart from that, try and find a good VHDL course somewhere, or get a
dev kit and sit down and work through all the examples and find a
good book. To be honest I cant recommend a book but a number can be
found online.

John



>Regards,
>Mauricio Jancic
>

2008\10\20@225515 by John Day

flavicon
face
At 10:16 PM 10/20/2008, you wrote:
>I just want to warn you based on some recent experience that making an
>FPGA design work reliably is not easy. Using one is not like
>programming a microcontroller, it is more like designing a circuit. I
>don't know your experience level, but you did say that you've never
>used an FPGA before. This might not be the best project to use for
>learning as it is fairly challenging. I'd recommend that you get a
>demo board and play around with some easier stuff first.

Making an FPGA design work reliably is no harder than making code
work reliably. But you need to know something about hardware and you
need to understand your FPGA. Gee, not much different to using a
micro! Synchronous design and a knowledge of clock domains would have
helped up front on your problem.

Jhn



{Quote hidden}

2008\10\20@230852 by Listas de Correo

flavicon
face
actually, what I want to implement is a frame grabber, I think that is
the name for it.

Once a user or a sub-system requires the capture, the whole system
will wait for a pulse synchronized with the frames.

When I have this pulse, I start sampling for a given time at a given
frequency (up to 150MHz) The idea is to use the FPGA or whatever as a
simple bridge between the ADC and the RAM, then, when the one frame
sample is finish, use a FT245 (parallel USB transceiver) to txmit the
data over the USB port to the PC application...

would that be as easy as it sounds?

Regards

On Mon, Oct 20, 2008 at 11:16 PM, Sean Breheny <@spam@shb7KILLspamspamcornell.edu> wrote:
{Quote hidden}

>> --

2008\10\20@231025 by Harold Hallikainen

face
flavicon
face

> On Tue, Oct 21, 2008 at 6:44 AM, Listas de Correo <spamBeGonelistasspamBeGonespamjanso.com.ar>
> wrote:
>> Hi, I need to make a device that will have to capture one frame of a
>> non standar video signal and store it in RAM, then pass that info to a
>> PC trough USB.
>> The signal should be sampled at 150MHz maximum.
>>
>> We are considering using an FPGA, but since we never used one, we dont
>> know were to begin. I think the Cyclone III would be a good choice,
>> but any information that someone experienced can provide would be
>> really appreciated.


I did a small Cyclone2 project. You can use the free version of Quartus2
for the Cyclone2. I don't know about the 3, though. You can run
simulations and tell how the timing will be before building any hardware.
Is the incoming video analog or digital? If analog, you'll need a pretty
quick ADC. And, some fast external RAM.

The project I did was pretty small, but a good first project. A consultant
showed me a "hardware designer's approach" to doing the design in Verilog.
It was MUCH easier for me than my previous struggles with VHDL. The design
comes down to defining a bunch of D latches and having D transfer to Q on
each clock edge. I then used combinatorial logic to define the D inputs to
the latches, doing state machines, counters, or whatever.

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\10\20@231850 by Shawn Tan

flavicon
face
On Tuesday 21 October 2008 11:08:07 Listas de Correo wrote:
> actually, what I want to implement is a frame grabber, I think that is
> the name for it.
>
> Once a user or a sub-system requires the capture, the whole system
> will wait for a pulse synchronized with the frames.
>
> When I have this pulse, I start sampling for a given time at a given
> frequency (up to 150MHz) The idea is to use the FPGA or whatever as a
> simple bridge between the ADC and the RAM, then, when the one frame
> sample is finish, use a FT245 (parallel USB transceiver) to txmit the
> data over the USB port to the PC application...
>
> would that be as easy as it sounds?

An FPGA would probably be overkill for this. You may be able to get away with
using a suitable micro or some other cheap programmable device. Your
bottleneck is going to be the USB connection anyway.

--
with metta,
Shawn Tan

Aeste Works (M) Sdn Bhd - Engineering Elegance
http://www.aeste.net

2008\10\20@232539 by Shawn Tan

flavicon
face
On Tuesday 21 October 2008 10:29:36 Harold Hallikainen wrote:
> The project I did was pretty small, but a good first project. A consultant
> showed me a "hardware designer's approach" to doing the design in Verilog.
> It was MUCH easier for me than my previous struggles with VHDL. The design
> comes down to defining a bunch of D latches and having D transfer to Q on
> each clock edge. I then used combinatorial logic to define the D inputs to
> the latches, doing state machines, counters, or whatever.

Yep, it is called HDL for a reason. Although it looks and feels like
programming, it is quite different and requires a different approach. I can
always tell the people who think 'hardware' or 'software' from the way they
code their HDL. I think that for most people coming from the software domain,
it takes a while before we can start to think hardware while coding software.

--
with metta,
Shawn Tan

Aeste Works (M) Sdn Bhd - Engineering Elegance
http://www.aeste.net

2008\10\21@081813 by Martin

face
flavicon
face
Sean Breheny wrote:

{Quote hidden}

You gated a clock. You should have got several errors from the
synthesizer. But I agree, FPGAs are easy to start with but learning how
to do things correctly is very difficult.
-
Martin

2008\10\21@100712 by Sean Breheny

face picon face
Hi John,

I do think there is a fundamental difference. In a microcontroller, it
is difficult to create a bug where the internal workings of the micro
give different results depending on slight temperature differences.
Unless you are dealing with an erratum, pretty much code which doesn't
interact with the outside world either works or it doesn't (given the
same inputs). This isn't true of an FPGA.

Sean


On Mon, Oct 20, 2008 at 10:57 PM, John Day <TakeThisOuTjohn.dayEraseMEspamspam_OUTsiliconrailway.com> wrote:
{Quote hidden}

2008\10\21@102959 by Shawn Tan

flavicon
face
On Tuesday 21 October 2008 22:07:08 Sean Breheny wrote:
> Hi John,
>
> I do think there is a fundamental difference. In a microcontroller, it
> is difficult to create a bug where the internal workings of the micro
> give different results depending on slight temperature differences.
> Unless you are dealing with an erratum, pretty much code which doesn't
> interact with the outside world either works or it doesn't (given the
> same inputs). This isn't true of an FPGA.

Using an FPGA merely transfers the problems to a different layer. Allowing a
person to work at the hardware layer is both a blessing and a curse. It gives
you flexibility at the cost of vigilance! d:

It certainly is possible to make reliable designs using an FPGA. The key, as
mentioned earlier, is to ensure that you: (1) understand the FPGA chosen (2)
understand your HDL code (3) understand how your code is translated into
hardware (4) understand how the said hardware really works.

The problem you had was probably because you misunderstood clocking issues in
an FPGA, that's all. It is not a good idea to do a divide-by-n clock divider.
The performance of the resultant clock is dependent on too many unpredictable
hardware variables.

--
with metta,
Shawn Tan

Aeste Works (M) Sdn Bhd - Engineering Elegance
http://www.aeste.net

2008\10\21@103711 by Herbert Graf

flavicon
face
On Tue, 2008-10-21 at 10:07 -0400, Sean Breheny wrote:
> Hi John,
>
> I do think there is a fundamental difference. In a microcontroller, it
> is difficult to create a bug where the internal workings of the micro
> give different results depending on slight temperature differences.
> Unless you are dealing with an erratum, pretty much code which doesn't
> interact with the outside world either works or it doesn't (given the
> same inputs). This isn't true of an FPGA.

Would you ignore warnings output by your C compiler?

Fact is the problem you describe was a result of not properly
constraining the design and checking the warnings. Granted, coming from
an MCU world I can understand not knowing that this could be a problem.

Personally, using FPGAs, once you KNOW them, isn't that much more
difficult then MCU stuff. The knowledge set is vastly different yes, but
fundamentally it's the same sort of deal: know your tools, read the
datasheet, pay attention to tool warnings.

TTYL

2008\10\21@104549 by alan smith

picon face
Off subject slightly...

Analog Devices has a Blackfin demo board thats does video capture.  I believe that WiLife based one of thier designs on this (now logitech).

If you can't find the reference just let me know and I can dig it up


--- On Tue, 10/21/08, Sean Breheny <EraseMEshb7spamcornell.edu> wrote:

{Quote hidden}

>

2008\10\21@105738 by Herbert Graf

flavicon
face
On Mon, 2008-10-20 at 19:44 -0300, Listas de Correo wrote:
> Hi, I need to make a device that will have to capture one frame of a
> non standar video signal and store it in RAM, then pass that info to a
> PC trough USB.
> The signal should be sampled at 150MHz maximum.
>
> We are considering using an FPGA, but since we never used one, we dont
> know were to begin. I think the Cyclone III would be a good choice,
> but any information that someone experienced can provide would be
> really appreciated.

I basically did that exact project (a little more involved then what you
describe, but fundamentally a very similar idea). Unfortunately since it
was for work I can't share any of it.

That said, what you describe is not too difficult for someone
experienced with FPGAs.

Rather then trying to choose a part, I'd suggest you research dev boards
and choose one that fits the bill.

For the design, first off you'll need to store the frame. You don't
mention how big a frame you want to capture, but based on the frequency
I'll surmise you are targeting something like 1080p (1920x1080x24bits).
For that you'll need a MINIMUM of >6MB for your frame buffer (more if
you need to support 10bits/colour). While the absolute largest FPGAs
might have that much SRAM in them, at that size they are very expensive
(>$3000). So, off hand I'd recommend getting a board with external SRAM
on it.

Another option, potentially cheaper if you are making your own board is
to use DRAM. The caveat here is you'll have to integrate a DRAM
controller, not too big a deal, most vendors offer cores for free,
otherwise http://www.opencores.org is your friend.

As for the FPGA itself, what you describe is pretty small in gate count.

Considering you want to run at 150MHz it's best to keep the design as
pipe-lined as possible, that'll make timing easier to achieve. 150MHz is
getting up there on speed for most FPGAs, you'll have to be very careful
ensuring you keep clocks on the clock tree, and that any memories are
properly inferred as block rams (instead of seas of flops).

Whatever part you choose, pay particular attention to clocking
resources. At 150MHz on the IO you'll likely have to at a minimum deskew
the clock.

As for USB there are lots of options there. The easiest would be to use
the FTDI245 chip, it's from a software side identical to the USB-RS232
FTDI chips. The only difference is on the hardware interface side, it
has a parallel interface, allowing it to operate faster. You can get
almost 1MB/s out of that chip, so if ~6sec/frame is fast enough for you
it is by far the most hassle free way of connecting your FPGA to a PC
through USB (hassle free both from the hardware and software side of
things).

If you want to download the frame faster you'll need to either use a
USB2 external chip like the Cypress parts (not too difficult), or
integrate a USB2 core in the FPGA (more difficult).

That's about all I can think of off hand. If you have any more specific
questions let me know.

TTYL







2008\10\21@113751 by Herbert Graf

flavicon
face
On Tue, 2008-10-21 at 22:29 +0800, Shawn Tan wrote:
> The problem you had was probably because you misunderstood clocking issues in
> an FPGA, that's all. It is not a good idea to do a divide-by-n clock divider.
> The performance of the resultant clock is dependent on too many unpredictable
> hardware variables.

Agreed, for those interested, there are a few ways to deal with this
sort of need, off hand:

1) use a clock resource to divide down your clock. Most FPGAs have
things like the PMCDs found in Xilinx FPGAs. They are divide-by-n clock
dividers on the clock trees, so using them doesn't muck timing up.
Unfortunately usually they have a lower frequency limit, so they aren't
always an option.

2) gate the high speed clock: instead of dividing down the high speed
clock, gate it, removing as many clock pulses as needed to get the clock
speed you want. You can only do this if your device has clock gate logic
on the clock trees (most parts do). Also note the resultant "clock" will
not be 50% duty cycle, so if you need to use the negative edge this
solution might not be for you. Finally, all the logic using the clock
will be constrained by the tool at the fast clock frequency. This
shouldn't be a problem since you'd only use this technique if the clock
you needed was too slow to begin with.

3) us an external clock divider: sometimes this is the only option if
you need a ton of really slow clocks

TTYL

2008\10\21@141052 by Sean Breheny

face picon face
I think this is a classic case of saying almost the same thing :)

I'm not saying one cannot make reliable FPGA designs. Yes, I
misunderstood how to handle clocks. I think, though, that in general,
implementing something with a micro is easier (i.e. less prone to
obscure timing problems) than in an FPGA. FPGA's are great for their
flexibility, but using one is somewhat like designing an asic rather
than just programming someone else's micro which already has most of
its hardware bugs worked out. Another analogy might be the difference
between driving a Honda Accord versus a Ferrari. In both cases,
failure to heed warnings can get you killed quite easily. However, the
set of things you need to be skilled at in order to prevent said
death, and the variety of possible relevant warnings, is much greater
with the Ferrari. Part of the difference is that the Ferrari is less
constrained and assumes that the user will make up for the lack of
constraints with his skill (or, in analogy to the toolset warnings, a
skilled instructor). A similarly-sized FPGA can do at least everything
which a micro can do, but it can do much more as well due to the fact
that the logic structure is a blank slate.

I don't think that the toolset I used (Lattice ispLever) warned me
about the clock problem. It realized that I wanted the output of the
divider to be a clock and it devoted secondary clock resources to it.
I don't think it could really know that what I was doing was bad
because it was only bad that I crossed clock domains without
synchronization. If I had not done that, I think it would have worked
even with the clock divider.

Sean

On Tue, Oct 21, 2008 at 10:37 AM, Herbert Graf <mailinglist4STOPspamspamspam_OUTfarcite.net> wrote:
{Quote hidden}

> -

2008\10\21@142040 by Richard Benfield

flavicon
face
have a look at this site, its a good place to get ideas when starting,
http://www.fpga4fun.com/digitalscope.
html the development boards are very cheap and the example code is very
well explained. the scope front
end is quite close to what you need you probably just need an external
frame buffer, how large is your frame?
and what is the required frame rate?


Richard

Listas de Correo wrote:
{Quote hidden}

2008\10\21@151449 by alan smith

picon face

Frame grabbing isn't that hard, but you need to determine your resolution first..ie..how many pixels do you want to sample. The higher the sample rate, the faster the clocks, the more memory you need to have.

Essentially you need to understand the video coming in.  For analog video, you have a number of vertical sync pulses that indicate the start of frame, and some blank lines that allows for vertical retrace settle. Bear in mind that this all refers to SVGA analog, digital video is something else.  You can see on a scope how many lines you have from VSYNC to your first line of video.  If your source is non-interlaced, makes it easier so you dont have to deal with half lines.  But you simply count the number of horizontal syncs to where the actual video starts, and then another timer to know where it starts relative to the HSYNC because you have blanking time after the HSYNC for retrace settle as well.  So now you know where the first actual video sits...start up your ADC and begin sampling..as the data comes out of course, you need to decide how your storing it and what resolution. Most consumer grade video is stored as 8 bits, but you have RGB so for each
digital pixel sample you have 24 bits (RGB) and you can store in a single frame buffer or three seperate memories.  Higher end video uses 10 or 12 bit video but you have to carve your mememory up a bit differerent but its just data, as long as you know how it goes in, you can read it out the same. So line by line you digitize the sammples and store keeping track where your writing it.  Might look at using SyncDRAM for storage or way back in the days of yore...there was actual VRAM or video RAM made specifically for video cards.  Using SRAM is more expensive but the advantage is you dont have to worry about refresh sequences.  So you also need to count the active lines and so when your done with the last line...you end up with the data in memory.  To get it back out, you just read it out in a specific format..what format is up to you because you can always reformat when you get it in the PC (so that goes with storing it in a specific format as well)

So back when I did the last video system, I used some FPGA for the memory controller and the video timing. Mine was a double buffered system.  Its all in the timing, doing the state machine in the FPGA isnt that hard, just need to know where to trigger and keep track of the syncs and lines.

If you pipeline the data, and the control sequences, then FPGAs are quite fine to use.  Its when you try to run asyncronous and rely on flight time you end up in trouble.  its not much different than any other state machine or micro.  As far as temperature variations, as long as your running in spec of the device, and you pipeline the data, everything is relative to the edge of the clocks.  

You just need a master state machine to give control to the frame grabber, or give control (or be in control) to stream it out serially thru the USB interface.  I assume that being a frame grabber, latency isnt really an issue so you dont have to run standard data packets.

--- On Tue, 10/21/08, Richard Benfield <@spam@piclist@spam@spamspam_OUT450se.co.uk> wrote:

{Quote hidden}

>

2008\10\28@051619 by Alan B. Pearce

face picon face
>I think, though, that in general, implementing
>something with a micro is easier (i.e. less
>prone to obscure timing problems)

(tongue in cheek)
I guess RMW issues on PIC port I/O don't count as obscure timing problems
...
(/tongue in cheek)


2008\10\28@053046 by David Meiklejohn

face
flavicon
face
Alan B. Pearce wrote:
>
> >I think, though, that in general, implementing
> >something with a micro is easier (i.e. less
> >prone to obscure timing problems)
>
> (tongue in cheek)
> I guess RMW issues on PIC port I/O don't count as obscure timing
> problems
> ...
> (/tongue in cheek)

(pedantic)

RMW issues are sometimes due to pin loading - it is not always a timing
issue

(/pedantic)


David Meiklejohn
http://www.gooligum.com.au


2008\10\28@090906 by Harold Hallikainen

face
flavicon
face

> Alan B. Pearce wrote:
>>
>> >I think, though, that in general, implementing
>> >something with a micro is easier (i.e. less
>> >prone to obscure timing problems)
>>
>> (tongue in cheek)
>> I guess RMW issues on PIC port I/O don't count as obscure timing
>> problems
>> ...
>> (/tongue in cheek)
>
> (pedantic)
>
> RMW issues are sometimes due to pin loading - it is not always a timing
> issue
>
> (/pedantic)
>

And you can avoid the read-modify-write issue by using the LATCH register
instead of the PORT register on 18 and higher PICs. The toggle register on
PIC32s is also pretty interesting.

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...