Searching \ for '[PIC] PIC32 USB - for logic analyzer' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC32 USB - for logic analyzer'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC32 USB - for logic analyzer'
2011\09\29@091714 by V G

picon face
I'm trying to write a simple logic analyzer to run on the PIC 32. It will
poll a pin (or pins) (either via interrupt on change, or preset sampling
rate), and send data to the PC via USB. A few questions:


1. How should I manage the USB transfers? There's not enough RAM on the PIC
to store and then transfer all at once, so I'm not even going to bother. I'm
going to transfer on the fly, as it's sampling. I don't need more than 1
MSPS anyway, so this should be fine.

Should I transfer a byte at a time? 64 bytes at a time? 30kB at a time?
How I have it set up now is the PIC32 running at maximum performance at
80MHz and Timer1 prescaled 1:8, and loaded with a period of 10. So the tick
frequency is 1MHz. Every time the a timer goes off, an interrupt occurs, and
the pin is sampled. The ISR itself handles the loading of the buffers, etc.
(Is that the right way to do it)? So should it call a USB transfer every
byte? 64 bytes? 30kB?

Note: I'm using the generic USB package from the Microchip application
libraries by the way, so simple generic USB bulk transfers.

Is there a faster way to stream data through USB while sampling?

2. I looked into DMA transfers to USB, but it was impossible to search for
any examples, and it looks pretty complicated, so I don't know.

3. The other option is to get 128MB of DRAM from somewhere and hook up to
the PIC, but DRAM interfacing will be pretty complicated, and I want to keep
it simple.

Other than that, I'm out of ideas for now.

What's the main concept for sampling fast and transferring on the fly? Or is
that not possible

2011\09\29@111923 by Harold Hallikainen

face
flavicon
face
I built a "logic analyzer" many years ago. I used the printer port on a
Cromemco CP/M computer as the logic inputs. I watched for a change in the
byte I read from the port, then saved the new value to memory and bumped a
pointer. Once I had finished a capture, I printed out all the data in
binary, one byte per line. I used this to reverse engineer the serial bus
on a Commodore 1541 floppy disk drive.

For your application, I think it'd be easier to add external RAM to use
during capture, then send the data after capture. I've got a project using
a 1MB static RAM that's easy to interface to. I used it on a PIC24 which
did not have the parallel master port, so I bit banged it. On the PIC32,
you could use the PMP for a fair amount of the work (though you'd have to
manually control higher address lines).

Here's some of my UsbTask code from a project:

   if(!USBHandleBusy(USBGenericOutHandle)){        // If it's safe to look at
the receive buffer
     if(count=USBHandleGetLength(USBGenericOutHandle)){    // if there's
something in the receive buffer
       if(count<=pUsbRxFifo->BytesFree){   // we have room in the fifo
         index=0;
         while(count--){
           PutFifo(pUsbRxFifo,OUTPacket[index++]);     // get data from
usb buffer to fifo
         }
         USBGenericOutHandle =
USBGenRead(USBGEN_EP_NUM,(BYTE*)&OUTPacket,USBGEN_EP_SIZE); //
ok to read more
       }// endif we had room
     }// endif there was something there
   }// endif not busy
   if(!USBHandleBusy(USBGenericInHandle)){ // 0 if ok to transmit
     if(count=pUsbTxFifo->BytesInBuf){  // we have something to send
       if(count>=sizeof(INPacket)){
         count=sizeof(INPacket);         // limit how many bytes we send
to size of output buffer
       }
       index=0;
       NumBytes=count;       // remember how many bytes we're sending
       while(count--){
         INPacket[index++]=GetFifo(pUsbTxFifo);  // fill the transmit
buffer from the fifo
       }
       USBGenericInHandle =
USBGenWrite(USBGEN_EP_NUM,(BYTE*)&INPacket,NumBytes); // send the
bytes
     }
   }



Harold

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

2011\09\29@113345 by V G

picon face
On Thu, Sep 29, 2011 at 11:19 AM, Harold Hallikainen <spam_OUTharoldTakeThisOuTspamhallikainen.org
{Quote hidden}

Thanks for the reply. Your code is pretty similar to my code

2011\09\29@122935 by jim

flavicon
face

I built a logic analyzer many years ago that used an oscillator that
would increment the address counter
of some dual port cache RAMS.  You could capture using one port of the
ram chip, and output the data on the
other port.  The dual port rams were from Cypress IIRC, and I believe
they were 128K x 9.  I used the 9th  bit as a trigger capture bit. After the capture, I would then send the
captured data out to the PC for
display. It worked well.   You might try looking at some of these RAM
chips.  Again, IIRC, they would work  up to about 60 Mhz or so.

Regards,

Jim

> ---{Original Message removed}

2011\09\29@124831 by Mark Rages

face picon face
On Thu, Sep 29, 2011 at 10:29 AM,  <.....jimKILLspamspam@spam@jpes.com> wrote:
>
>  I built a logic analyzer many years ago that used an oscillator that
> would increment the address counter
>  of some dual port cache RAMS.  You could capture using one port of the
> ram chip, and output the data on the
>  other port.  The dual port rams were from Cypress IIRC, and I believe
> they were 128K x 9.  I used the 9th
>  bit as a trigger capture bit. After the capture, I would then send the
> captured data out to the PC for
>  display. It worked well.   You might try looking at some of these RAM
> chips.  Again, IIRC, they would work
>  up to about 60 Mhz or so.
>

Microchip has some serial RAMs that do this.  Just keep clocking them
and they store a bit with each clock.  Design here:
http://dangerousprototypes.com/docs/Logic_Shrimp_design_overview


-- Regards,
Mark
markrages@gmail

2011\09\29@131722 by V G

picon face
On Thu, Sep 29, 2011 at 12:48 PM, Mark Rages <markragesspamKILLspamgmail.com> wrote:

> On Thu, Sep 29, 2011 at 10:29 AM,  <.....jimKILLspamspam.....jpes.com> wrote:
> >
> >  I built a logic analyzer many years ago that used an oscillator that
> > would increment the address counter
> >  of some dual port cache RAMS.  You could capture using one port of the
> > ram chip, and output the data on the
> >  other port.  The dual port rams were from Cypress IIRC, and I believe
> > they were 128K x 9.  I used the 9th
> >  bit as a trigger capture bit. After the capture, I would then send the
> > captured data out to the PC for
> >  display. It worked well.   You might try looking at some of these RAM
> > chips.  Again, IIRC, they would work
> >  up to about 60 Mhz or so.
> >
>
> Microchip has some serial RAMs that do this.  Just keep clocking them
> and they store a bit with each clock.  Design here:
> http://dangerousprototypes.com/docs/Logic_Shrimp_design_overview
>
>
The only problem I have with these is that 256K samples isn't enough. I can
store 250k samples on the PIC32 RAM itself if I wanted to. I either need to
stream it to the host on the fly, or need some cheap DRAMs

2011\09\29@134104 by Herbert Graf

picon face
On Thu, 2011-09-29 at 13:17 -0400, V G wrote:
> The only problem I have with these is that 256K samples isn't enough. I can
> store 250k samples on the PIC32 RAM itself if I wanted to. I either need to
> stream it to the host on the fly, or need some cheap DRAMs.

I'm confused, if you can store 250k samples in the PIC, why do you want
to bother with "on the fly" type stuff? When is 250k samples not enough?

Alot of the work I do requires at most a few hundred samples. Thousands
is rare. 250k? I'd say you should refine your triggering so that you
don't need such a large window. Alot of people I've worked with started
out thinking they needed millions of samples to get their work done.
They quickly learned that small sample windows triggered at the right
point are FAR more useful to quickly debugging an issue.

If 250k is REALLY not enough, you STILL don't need "on the fly". Create
a large ring buffer in the PIC to store your samples, and on an
interrupt check that buffer and if it's fills beyond a certain amount,
shoot a large chunk of it to the PC over USB. That way you don't have to
worry about traffic on the USB bus, or the PC not responding quickly
enough to you.

Another option, which is either very easy or very hard is to compress
your data. Logic analyzer waveforms are usually VERY compressible
(almost all the data is relatively static, or is a clock in which case
you just have to define the period).

TTYL

2011\09\29@140616 by V G

picon face
On Thu, Sep 29, 2011 at 1:41 PM, Herbert Graf <EraseMEhkgrafspam_OUTspamTakeThisOuTgmail.com> wrote:

> On Thu, 2011-09-29 at 13:17 -0400, V G wrote:
> > The only problem I have with these is that 256K samples isn't enough. I
> can
> > store 250k samples on the PIC32 RAM itself if I wanted to. I either need
> to
> > stream it to the host on the fly, or need some cheap DRAMs.
>
> I'm confused, if you can store 250k samples in the PIC, why do you want
> to bother with "on the fly" type stuff? When is 250k samples not enough?
>

When capturing multiple channels and data through the bus.



{Quote hidden}

Yes, that's what I thought of initially, but there are problems:

1. If I burst large chunks of data to the PC, the PIC will either miss a few
samples during the transfer process, OR

2. If the sampling is done in a high priority interrupt, then the USB
protocol will get interrupted.


> Another option, which is either very easy or very hard is to compress
> your data. Logic analyzer waveforms are usually VERY compressible
> (almost all the data is relatively static, or is a clock in which case
> you just have to define the period).
>

Yeah, that's true. But then I'd have to use CPU clock cycles to compress on
the fly. I don't know if I can still get my 10 Msps target with any of these
options give that the max speed is 80MHz

2011\09\29@141136 by jim

flavicon
face

Actually, I forgot to mention that these RAMS were cascadable.  I
actually had two in cascade to allow storing 512k samples per pin on
each of 9 pins per memory.  And I had a total of 36 channels.  Eight
Dual Port RAMS total.

Regards,

Jim

> ---{Original Message removed}

2011\09\29@141953 by V G

picon face
Thanks. SRAM is pretty cheap these days anyway. I'll probably just stick a
serial 16MB SRAM on there and I'll be good to go.

On Thu, Sep 29, 2011 at 2:11 PM, <jimspamspam_OUTjpes.com> wrote:

> Actually, I forgot to mention that these RAMS were cascadable.  I
> actually had two in cascade to allow storing 512k samples per pin on
> each of 9 pins per memory.  And I had a total of 36 channels.  Eight
> Dual Port RAMS total.

2011\09\29@142902 by V G

picon face
Wow, I can't believe I missed this -

1. Computer SDRAM, or

2. SPI SD cards, or compact flash.

Cheap, LOTS of memory, and fast enough. Assuming 10MB/s writes on the
cheapest cards, that's 80Mbit/s = 80Msps which is WAYYY more than I need.
Super easy interface, and very cheap. I think I found my answer

2011\09\29@143027 by Herbert Graf

picon face
On Thu, 2011-09-29 at 14:06 -0400, V G wrote:
> When capturing multiple channels and data through the bus.

Fine, but how many logic probes will you have? 8? 16? Even with 16
you've got 15k samples, still MORE then enough for pretty much all debug
work you'll have.

> Yes, that's what I thought of initially, but there are problems:
>
> 1. If I burst large chunks of data to the PC, the PIC will either miss a few
> samples during the transfer process, OR
>
> 2. If the sampling is done in a high priority interrupt, then the USB
> protocol will get interrupted.

Interesting, I'm not familiar with the PIC's USB peripheral, does it
require that much hand holding? You can't just set up a bunch of stuff
and tell it to "go"?
If true you're right, and I'd say a PIC isn't the correct tool to use in
this case.

Have you considered using an FPGA? I've done this sort of thing before,
if you are familiar with FPGAs this sort of project becomes rather
trivial.

> > Another option, which is either very easy or very hard is to compress
> > your data. Logic analyzer waveforms are usually VERY compressible
> > (almost all the data is relatively static, or is a clock in which case
> > you just have to define the period).
> >
>
> Yeah, that's true. But then I'd have to use CPU clock cycles to compress on
> the fly. I don't know if I can still get my 10 Msps target with any of these
> options give that the max speed is 80MHz.

Very true, again, considering your requirements, and how "messy" USB can
be (I'm worried you're "on the fly" solution will never work due to
latency on the PC side servicing the USB port), I think you should
consider a change of target.

FWIW I built a very basic serial port based logic analyzer many years
ago:

http://repatch.dyndns.org/pic_stuff/logan/index.html

(it's actually quite embarrassing looking at that project now, the code
is a such a mess, and the design is really crude).

In that I decided on a RAM chip for data storage, a CPLD to address and
clock it, and a 16F877 PIC to do all the other good stuff. It was a
really fun project and I actually used it's for real work a few times.

TTYL

2011\09\29@143041 by V G

picon face
On Thu, Sep 29, 2011 at 2:28 PM, V G <@spam@x.solarwind.xKILLspamspamgmail.com> wrote:

> Wow, I can't believe I missed this -
>
> 1. Computer SDRAM, or
>
> 2. SPI SD cards, or compact flash.
>
> Cheap, LOTS of memory, and fast enough. Assuming 10MB/s writes on the
> cheapest cards, that's 80Mbit/s = 80Msps which is WAYYY more than I need.
> Super easy interface, and very cheap. I think I found my answer.
>

Also has more than enough space for wear leveling the flash (I'm not sure if
the SD controller does that already or not). Can't get any better than this.

2011\09\29@143047 by jim

flavicon
face

One other thing.  The RAMS I am talking about are 128K 9 bit locations.
Which means there are 1179648 bits.
Not 128K bits.  In other words, I cascaded two of the 128K RAMS for a
total of 256K.  Each channel of the
analyzer is connected to a data line on the RAMS.  I had 4 of these two
RAM setups in parallel.  This gives
me 36 channels, each with 256K samples.   I used this many times before
I was able to afford a commercially
built unit.  And if I still had it (I gave it to a student friend of
mine a few years ago), I would still
use it.  In some respects, it was better than the commercial unit.

The bottom line is in the projects I worked on, 256K samples was more
than enough.  I could specify what I
wanted to trigger on by setting a pattern on any or all of the input
channels, and the unit would trigger
when that pattern would appear.  Until that pattern appeared on the
input lines, the data would come in and
the RAMS would record the level, but only after the pattern appeared
would the unit mark the beginning of
the record, and would stop when the RAMS were full.

In other words, until the trigger event happened, data would come in
and if the max address range of the  RAMS were exceeded, the counter would wraparound and over write the
existing data.  After the trigger event
appeared, the current address of the RAM was flagged, and you would
continue collecting data up to the end
of the RAM.  If you wanted to see the pre trigger data, that could be
reviewed up to a point.  But you had\
to select the pretrigger  option if you wanted to see pretrigger data. Otherwise, you would see only post
trigger data.

I built this unit based on a magazine article, but I added some
enhancements of my own.  I may still have
the article if you'd be interested.  I'd have to look for it though.


Regards,

Jim

> ---{Original Message removed}

2011\09\29@144620 by Herbert Graf

picon face
On Thu, 2011-09-29 at 14:28 -0400, V G wrote:
> Wow, I can't believe I missed this -
>
> 1. Computer SDRAM, or

VERY hard to interface to due to the speeds required. Note: most DRAM
will NOT run at slow speeds (modern DRAM is usually speced to not run at
less then hundreds of MHz).

> 2. SPI SD cards, or compact flash.

SPI mode on SD cards is likely nowhere near fast enough for your
purposes.

CF in IDE mode is, but it's doubtful you'd be able to get enough
bandwidth using a PIC and bit banging, you'd need a CPLD or FPGA (I've
done it).

Note that both methods have variable write times that you'll have to
account for. SD cards are known to write at steady rates for a good bit
and then "hiccup" for a substantial amount of time, you'll have to
account for that.

TTYL

2011\09\29@144952 by V G

picon face
On Thu, Sep 29, 2011 at 2:30 PM, Herbert Graf <KILLspamhkgrafKILLspamspamgmail.com> wrote:

> Fine, but how many logic probes will you have? 8? 16? Even with 16
> you've got 15k samples, still MORE then enough for pretty much all debug
> work you'll have.
>

I'm capturing bulk data being written to devices on various busses at the
same time to analyze the timing between them and to reverse engineer the
data. For any other purpose, I'd agree that 15k samples is usually enough,
but when the data itself is of interest, I need to be able to capture it.


> Interesting, I'm not familiar with the PIC's USB peripheral, does it
> require that much hand holding? You can't just set up a bunch of stuff
> and tell it to "go"?
>

As of now, I'm filling a buffer and calling transmit(). I'm pretty sure that
without DMA, the transmit() is blocking. Also, there's issues with polling
and interrupt modes and USB tasks that have to be serviced periodically that
take up CPU time. I measured throughput with and without USB with an
oscilloscope and it's a 10x difference. Of course, I'm using the stock
Microchip USB libraries, so I'm assuming they're not super duper optimized.


> If true you're right, and I'd say a PIC isn't the correct tool to use in
> this case.
>
> Have you considered using an FPGA? I've done this sort of thing before,
> if you are familiar with FPGAs this sort of project becomes rather
> trivial.
>

Yes, I have. I have the Nexys 2 board with USB 2.0 high speed as well as
32MB of RAM which is perfect for this application. Drawback: I'm not good
with FPGAs yet. Not enough to trust myself to do this. I still need to learn
more with them.

Very true, again, considering your requirements, and how "messy" USB can
{Quote hidden}

Looks good. I'm going to try my SPI SD card method first. I have a good
feeling about this. SD says max 50 MHz via SPI which is more than enough for
me

2011\09\29@145159 by V G

picon face
On Thu, Sep 29, 2011 at 2:46 PM, Herbert Graf <RemoveMEhkgrafTakeThisOuTspamgmail.com> wrote:

> SPI mode on SD cards is likely nowhere near fast enough for your
> purposes.
>

Wikipedia says max 50 MHz via SPI for all but the oldest cards. I'll
benchmark it and see how it goes. I can use DMA with SPI, even better.


> CF in IDE mode is, but it's doubtful you'd be able to get enough
> bandwidth using a PIC and bit banging, you'd need a CPLD or FPGA (I've
> done it).
>

Yeah, that's why I'm staying away from CF.


> Note that both methods have variable write times that you'll have to
> account for. SD cards are known to write at steady rates for a good bit
> and then "hiccup" for a substantial amount of time, you'll have to
> account for that.
>

It'll be a buffered write. The buffers clear faster than the time it takes
to write, so hiccups will be okay. The DMA controller will handle the data
transfer from RAM to SPI

2011\09\29@160610 by Herbert Graf

picon face
On Thu, 2011-09-29 at 14:49 -0400, V G wrote:
> Looks good. I'm going to try my SPI SD card method first. I have a good
> feeling about this. SD says max 50 MHz via SPI which is more than enough for
> me.

You may have to try a few cards.

While 50MHz is the physical clock rate, you won't get anywhere near that
throughput.

The reason is protocol overhead (which isn't the big) and write time
(which is HUGE). You'll have to hunt for a card with as short and as
consistent a write time as possible (IIRC SD cards have a write block of
512 bytes).

Even bit banging, I'd notice some cards would take many queries of "are
you done" before they were done writing.
For example, here is a web site where someone measured the performance
of their 2GB SD card:

http://forum.xda-developers.com/archive/index.php/t-242802.html

Details:
Card tested "Storage Card"
Min. read time: 0.25ms
Max read time: 18.00 ms
Avg. read time 1.87ms
Sector/block: variable 4-64
Min write time: 0.50ms
Max write time: 16.00 ms
Avg. write time: 4.02ms
Read/write ratio: 0.46
Sector size: 512 bytes
Start Sector: 0
End Sector: 3910656
Total Sectors read: 2504
Total data read: 1.00MB
Total read time: 4673 ms
Total sectors written: 2504
Total data written: 1.00MB
Total write time: 10057ms

Notice the HUGE variability of read and write times? That's the killer
for apps the need consistent write performance.

I'd assume newer cards are better, but I'd love to hear back what stats
you end up getting?

TTYL

2011\09\29@173916 by IVP

face picon face
> I'm confused, if you can store 250k samples in the PIC, why do
> you want to bother with "on the fly" type stuff? When is 250k
> samples not enough?
>
> Alot of the work I do requires at most a few hundred samples

Agreed. I don't think I've had an instance when the problem couldn't
be solved or identified using for example one slow overall capture at
low resolution to see a general pattern and then captures of smaller
specific regions or events at higher resolution

Note my occassional gif attachments of analyser outputs

I've built 2 analysers, both based on relatively slow micros - a 68HC
and a 16F84A-10. The micro does not do the capturing. It manages
the circuit, which is basically a variable PLL, TTL clocks/latches and
ex-mobo fast cache RAM (2 x 8k)

Jo

2011\09\29@180906 by IVP

face picon face
> Notice the HUGE variability of read and write times? That's the killer
> for apps the need consistent write performance.
>
> I'd assume newer cards are better, but I'd love to hear back what stats
> you end up getting?

Herbert,

there have been several posts lately about SDHC performance and
SPI. Basically it is very slow and not suitable for a high-end analyser.
Perhaps with RAM buffering

For one application I'm even considering two microSD in parallel if
I stick with dsPIC SPI (>10MHz)

As you say, 50MHz might be the maximum clock speed, but it certainly
isn't a reliable indicator of overall write speed

Jo

2011\09\30@022804 by Oli Glaser

flavicon
face
On 29/09/2011 19:49, V G wrote:
>> Have you considered using an FPGA? I've done this sort of thing before,
>> >  if you are familiar with FPGAs this sort of project becomes rather
>> >  trivial.
>> >
> Yes, I have. I have the Nexys 2 board with USB 2.0 high speed as well as
> 32MB of RAM which is perfect for this application. Drawback: I'm not good
> with FPGAs yet. Not enough to trust myself to do this. I still need to learn
> more with them.

I would really think about giving it a go on the FPGA. This seems like a perfect project to learn with, not too hard but enough practical challenges and the reward of a usable tool at the end of it (faster than you will ever get with the PIC32)

2011\09\30@024040 by V G

picon face
On Thu, Sep 29, 2011 at 4:06 PM, Herbert Graf <spamBeGonehkgrafspamBeGonespamgmail.com> wrote:
>
> You may have to try a few cards.
>

Yep, that's what I plan to do.


> While 50MHz is the physical clock rate, you won't get anywhere near that
> throughput.
>
> The reason is protocol overhead (which isn't the big) and write time
> (which is HUGE). You'll have to hunt for a card with as short and as
> consistent a write time as possible (IIRC SD cards have a write block of
> 512 bytes).
>

I think modern SD cards have improved quite a lot. On the computer, I get
consistent 80Mb/s+ writes.



{Quote hidden}

I'll test and let you know. On the pc, using a super cheap micro sd card and
super cheap USB card reader, I'm getting consistent 48Mbit/s writes. If I
can even score half that on my PIC32, that'll be more than enough,
especially with SPI running at close to 50MHz via DMA. Since the nature of
the application is sequential writes, SD should work perfeclty

2011\09\30@024517 by V G

picon face
On Thu, Sep 29, 2011 at 6:07 PM, IVP <TakeThisOuTjoecolquittEraseMEspamspam_OUTclear.net.nz> wrote:

> there have been several posts lately about SDHC performance and
> SPI. Basically it is very slow and not suitable for a high-end analyser.
> Perhaps with RAM buffering
>

RAM buffering indeed.


> For one application I'm even considering two microSD in parallel if
> I stick with dsPIC SPI (>10MHz)
>

Yep, that's a good option. Especially with SD cards being
$5/2GB<http://www.sdcards.com/micro-sd-cards>.
I wish I could still find smaller ones.


> As you say, 50MHz might be the maximum clock speed, but it certainly
> isn't a reliable indicator of overall write speed
>

That's true. The computer is giving me 50Mbit/s constant write on the
cheapest piece of crap micro sd card I could find. There is hope

2011\09\30@025940 by V G

picon face
On Fri, Sep 30, 2011 at 2:27 AM, Oli Glaser <RemoveMEoli.glaserspamTakeThisOuTtalktalk.net> wrote:

>  I would really think about giving it a go on the FPGA. This seems like a
> perfect project to learn with, not too hard but enough practical
> challenges and the reward of a usable tool at the end of it (faster than
> you will ever get with the PIC32)


You're right, but then I'd need to learn how to use the USB module on my
Nexys 2 board, and how to interface the RAM which takes additional time.
I'll probably do that after I get something working on the PIC32

2011\09\30@044510 by alan.b.pearce

face picon face
> I think modern SD cards have improved quite a lot. On the computer, I get
> consistent 80Mb/s+ writes.

Don't forget that will be using the 4 bit parallel interface, not the SPI interface. The SPI interface is really a legacy interface that does not seem to be well supported. Go and look at Joe's (IVP) thread over the last month or so about interfacing an SD card using SPI.

To use the parallel interface you really need to be a member of the SD group to get the required documentation, although there is some in the wind, if you can find it.

But I am confused about what sort of analyser you are attempting to build. When you first posted I got the impression that you were looking at 'self capturing' what was happening on a PIC32, but now I get the impression you are building something to capture waveforms on other equipment. Is this correct?


-- Scanned by iCritical.

2011\09\30@045039 by V G

picon face
I was going crazy trying to figure out how DangerousPrototypes got their
PIC18F24J50 running at 20MHz to capture signals at 20MHz when I couldn't
even get my PIC32 to toggle a pin faster than 10MHz (from C32). Then I
realized that they had the SRAMs to capture the data directly.

-_______________________-



Wow it really is tough to get a micro controller to capture inputs directly..
Need some other logic to do it.

Oh well - time to put my PIC stuff away and get out the old Spartan 3.

Still going to test the SPI stuff for fun though. I want to push the PIC to
its limits - even if that means writing inline assembler to do it

2011\09\30@045841 by V G

picon face
On Fri, Sep 30, 2011 at 4:45 AM, <alan.b.pearceEraseMEspam.....stfc.ac.uk> wrote:

> Don't forget that will be using the 4 bit parallel interface, not the SPI
> interface. The SPI interface is really a legacy interface that does not seem
> to be well supported. Go and look at Joe's (IVP) thread over the last month
> or so about interfacing an SD card using SPI.
>

True, there's probably information on the net for that. Also, could reverse
engnieer the signals. How much more complicated could they be over the
normal SPI commands? Address, write, address write, etc...


> To use the parallel interface you really need to be a member of the SD
> group to get the required documentation, although there is some in the wind,
> if you can find it.
>

Oh I'll be able to find it :P

(Hopefully)


> But I am confused about what sort of analyser you are attempting to build..
> When you first posted I got the impression that you were looking at 'self
> capturing' what was happening on a PIC32, but now I get the impression you
> are building something to capture waveforms on other equipment. Is this
> correct?
>

I'm sorry for any confusion. The truth is, I'm trying to capture data that
my printer sends to its various serial devices (EEPROMs/RAM) and analyze it
so I can "hack" into it. There's no way in hell I'm spending $200 to buy new
cartridges when I can refill them myself for $20. Yes, I know, there are
already solutions out there to circumvent this, such as toner chips (which
I'm currently trying to reverse engineer), reset page count on the serial
EEPROM (which is why I requested 24c64s), but doing it myself is so much
more fun, and I get to learn things I would otherwise not have.

Principles.

Just messing around, I already became more familiar with the PIC32 and how
it uses interrupts for pin change, timer interrupts, DMA, SPI and I2C
module, USB module for generic interface, CDC interface, how to push it to
its limits, etc.

Now I'm going to destroy a few SD cards, then whip out the FPGA and see what
I can do with its onboard high speed (80MHz) RAM and the ability to run it
at around 333MHz. I'll probably have to run it at 60MHz anyway, since my
oscilloscope (thanks again Sean) can't go that high

2011\09\30@064717 by Joep Suijs

picon face
2011/9/30 V G <EraseMEx.solarwind.xspamgmail.com>:
> Oh well - time to put my PIC stuff away and get out the old Spartan 3.
>

I started building sram-based micro-controlled sampling hardware, but
abandoned that at some point in favor of
http://www.sump.org/projects/analyzer/
Way better specs and works great for me. Dangerous prototypes has a
downsize version.

Joe

2011\09\30@074341 by V G

picon face
On Fri, Sep 30, 2011 at 6:47 AM, Joep Suijs <RemoveMEjsuijsEraseMEspamEraseMEgmail.com> wrote:

> I started building sram-based micro-controlled sampling hardware, but
> abandoned that at some point in favor of
> http://www.sump.org/projects/analyzer/
> Way better specs and works great for me. Dangerous prototypes has a
> downsize version.
>
>
Yep, been looking at that. It would take all of 10 mins to get it working on
the Nexys 2 board since there's already a port. But still no fun compared to
making your own

2011\09\30@075004 by M.L.

flavicon
face
On Thu, Sep 29, 2011 at 9:16 AM, V G <RemoveMEx.solarwind.xspam_OUTspamKILLspamgmail.com> wrote:
> What's the main concept for sampling fast and transferring on the fly? Or is
> that not possible?

The crux of the problem is that USB is master/slave and the PIC32 is the slave.
You should look into isochronous transfer if you need guaranteed
constant bandwidth.

-- Martin K

2011\09\30@082310 by V G

picon face
On Fri, Sep 30, 2011 at 7:49 AM, M.L. <RemoveMEmTakeThisOuTspamspamlkeng.net> wrote:

> The crux of the problem is that USB is master/slave and the PIC32 is the
> slave.
> You should look into isochronous transfer if you need guaranteed
> constant bandwidth.
>
>
I believe the problem is the fact that I was trying to get the
microcontroller to do the actual capturing. There's no way it can capture
that fast while also managing the memory, incrementing memory points for the
buffer, going through for loops, if loops. That ought to slow it down at
least 20-30 times when done in C.

An interesting and attractive product is this:
http://www.saleae.com/logic/claiming 24Msps. (Many hardware clones are
available, since it's basically a
Cypress 8052 board)

Internally, the chip is a
CY7C68013A-56PVXC<www.cypress.com/products/index.jsp?fid=14&rpn=CY7C68013A>8052
type. Looking at the datasheet, it seems that maximum clock speed is
48MHz with 4 clocks per instruction - that's 12MIPS maximum. How is it able
to sample at 24Msps? I'd love to know how this one works. Someone has
guessed 96MHz CPU clock = 24 MIPS.

Now reading this thread: http://www.eevblog.com/forum/index.php?topic=2600.0

Seems it's USB in DMA mode - that explains a lot.

Someone has stated: "The hardware just transfers bytes (8-bit = 8-channel
wide) at the specified rate to the PC. The PC does all work like triggering
and decoding."

That's still pretty impressive. But how is it able to sample at 24Msps at
only 12MIPS? I'd imagine at least 96MHz clock is needed for 24MIPS. And even
at 24 MIPS, how is it possible to sample at 24Msps? That's assuming a best
case scenario of one sample per instruction. I can't conceive of a way that
that's possible, due to instructions to increment memory pointers, etc.
UNLESS - the USB DMA is reading directly off of one byte of RAM the entire
time, so all the CPU is doing is constantly assigning the PORT values to
that single RAM byte.

That's my best guess. Any other ideas?

Ok gonna try that now with isosynchronous USB transfer with DMA. Huge pain
in the ass to get DMA USB working on the PIC. Severe lack of
documentation/examples. I can't find ANYTHING for this..

2011\09\30@082457 by V G

picon face
On Fri, Sep 30, 2011 at 8:22 AM, V G <EraseMEx.solarwind.xspamspamspamBeGonegmail.com> wrote:

{Quote hidden}

Isochronous*. I don't know why I said the other thing..

2011\09\30@083034 by V G

picon face
Another project: http://buglogic.robomotic.com/tiki-index.ph

2011\09\30@125001 by Michael Watterson

face picon face
V G wrote:
>
>
>
> I'll test and let you know. On the pc, using a super cheap micro sd card and
> super cheap USB card reader, I'm getting consistent 48Mbit/s writes. If I
> can even score half that on my PIC32, that'll be more than enough,
> especially with SPI running at close to 50MHz via DMA. Since the nature of
> the application is sequential writes, SD should work perfeclty.
>   How do you know this without the OS "lying" and giving an average including Driver cache /buffer or OS cache/buffer or spped to controller the card is in?

Anyway the PC doesn't use SPI to talk to them.

Actually shop around for Ink, or get a different printer.

I'd only ever refill cartridges on a really cheap printer or one with cheaply disposable heads. Because there are many ink formulations. Really is the Engineering effort proportional to the problem?

2011\09\30@134453 by V G

picon face
On Fri, Sep 30, 2011 at 12:49 PM, Michael Watterson <mikeSTOPspamspamspam_OUTradioway.org>wrote:

> How do you know this without the OS "lying" and giving an average
> including Driver cache /buffer or OS cache/buffer or spped to controller
> the card is in?
>
> Anyway the PC doesn't use SPI to talk to them.
>

You're right. I used benchmark software to test it. It's not lying.


> Actually shop around for Ink, or get a different printer.
>

Okay Mr. Moneybags.

This isn't for just the printer. It's a learning process.


> I'd only ever refill cartridges on a really cheap printer or one with
> cheaply disposable heads. Because there are many ink formulations.
> Really is the Engineering effort proportional to the problem?
>

It's not about the engineering effort

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