Searching \ for '2000 instructions a sec??' 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=2000+instructions
Search entire site for: '2000 instructions a sec??'.

Truncated match.
PICList Thread
'2000 instructions a sec??'
2000\03\14@055235 by Rob R

flavicon
face
Has anyone ever timed instructoin execution on a basic stamp 1 module?  I dont see how they can get 2000 instructions per second when it takes at least 500us to reliably get one byte of data from a serial eeprom.  And another thing is that like an average number? because there has to be a huge difference between time it takes to execue a HI command compared to executing a SEROUT command wich has much more data to be read from eeprom.

Anyone know anything about this??

rob

Send someone a cool Dynamitemail flashcard greeting!! And get rewarded.
GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41

2000\03\14@061402 by Michael Rigby-Jones

flavicon
face
part 0 2689 bytes
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I suspect 2000 instructions a second was based on a well chosen selection of instructions....i.e. very short ones.&nbsp; The stamp uses variable size instructions so it won't always need to grab a whole 8 bits from the eeprom.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Mike</FONT>
</P>
<UL>
<P><FONT SIZE=1 FACE="Arial">{Original Message removed}

2000\03\15@040149 by William Chops Westfield

face picon face
   Has anyone ever timed instructoin execution on a basic stamp 1 module?  I
   dont see how they can get 2000 instructions per second when it takes at
   least 500us to reliably get one byte of data from a serial eeprom.

Why do you think it takes 500us to get one byte of data from the eeprom?
The way I read the 93c46 datasheet, you ought to be able to get an arbitrary
byte of data from the eeprom in about 20 clocks worth, at up to 2MHz - which
would be about 10 us.  I don't think firmware on a PIC can run the clock at
2MHz, but I'd be surprised if it took more than 200us...

Note that some EEPROMs have a more complex communications scheme that would
cause the reads to take more clock cycles (typically, they require extra
bits to address the chip as well as the data address within the chip.)

BillW

2000\03\15@045458 by Rob R

flavicon
face
>>
>Why do you think it takes 500us to get one byte of data >from the eeprom?  The way I read the 93c46 datasheet, >you ought to be able to get an arbitrary byte of data >from the eeprom in about 20 clocks worth, at up to 2MHz -> which
>>

Maybe its just the way I wrote my code, however I dont see any other way to do it.  I suppose I could take out my delay's ( which i put in to make sure the data is read and written too with enough time to setup before giving more data), but still it would take me around 500us to read + - 100us but not 20us.  Im using a 24LS32 serial eeprom from Microchip.

Rob Rivera.



On Wed, 15 Mar 2000 01:00:40 PST William Chops Westfield <spam_OUTbillwTakeThisOuTspamCISCO.COM> wrote:
{Quote hidden}

Send someone a cool Dynamitemail flashcard greeting!! And get rewarded.
GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41

2000\03\15@071758 by Michael Rigby-Jones

flavicon
face
part 0 1478 bytes
<P><FONT SIZE=2 FACE="Arial">&gt;&gt;</FONT>
<BR><FONT SIZE=2 FACE="Arial">&gt;Why do you think it takes 500us to get one byte of data &gt;from the eeprom?&nbsp; The way I read the 93c46 datasheet, &gt;you ought to be able to get an arbitrary byte of data &gt;from the eeprom in about 20 clocks worth, at up to 2MHz -&gt; which</FONT></P>

<P><FONT SIZE=2 FACE="Arial">&gt;&gt;</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Maybe its just the way I wrote my code, however I dont see any other way to do it.&nbsp; I suppose I could take out my delay's ( which i put in to make sure the data is read and written too with enough time to setup before giving more data), but still it would take me around 500us to read + - 100us but not 20us.&nbsp; Im using a 24LS32 serial eeprom from Microchip.</FONT></P>

<P><FONT SIZE=2 FACE="Arial">Rob Rivera.</FONT>
</P>
<BR>
</UL>
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">The 24XXX series uses I2C, whereas the 93XX is SPI, which is generaly faster.&nbsp; No need to worry about stop and start states etc.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Mike</FONT>
</P>

</BODY>
</HTML>
</x-html>

2000\03\15@154509 by Marc

flavicon
face
> Maybe its just the way I wrote my code, however I dont see any other way to do it.  I suppose I could take out my delay's ( which i put in to make sure the data is read and written too with enough time to setup before giving more data), but still it would take me around 500us to read + - 100us but not 20us.  Im using a 24LS32 serial eeprom from Microchip.

A 24x32 is an I2C device, and I2C can always be run at 100khz (90us per byte) and newer
devices usually at 400khz (22.5us per byte).

Using two (or more) such devices in parallel not only doubles the memory size, but can
also speed up the data throughput.

Other (faster) interface technologies exist as well.  An SPI equivalent to your 24x32
is for example the M95640 with 4kbyte and 2MHz clockrate.  It can deliver a byte in 4us.

2000\03\15@182744 by William Chops Westfield

face picon face
   Maybe its just the way I wrote my code, however I dont see any other
   way to do it.  I suppose I could take out my delay's, but still it
   would take me around 500us to read + - 100us but not 20us.  Im using a
   24LS32 serial eeprom from Microchip.

Hmm.  I should preface this by saying that I haven't actually DONE
this, but...

The way I read the 93c46 datasheet, reading a byte of data consists of
clocking in a 9bit read command (which includes the address), and then
clocking out 9 bits of the data (start bit plus 8 data bits, essentially.)
The clock can be up to 2MHz, so in theory you could do the byte read in 18
* 1/(2e6) or about 9 microseconds.  Now a 4MHz PIC certainly can't generate
a 2MHz clock signal in software - I'd guess that it takes about 4 to 5
instructions to do each shift & clock, perhaps more.  Call it 8
instructions per bit to come up with an even number (2us), and your random
read should take about 36 us.

Now, on the 24c32 parts, it looks like a "random read" is about the slowest
possible operation you can do, (write device address, "write" comand, word
address, device address again (aborts the "write"), clock out data...)  On
top of that, the clock spec if 5x slower than the 93c46 (400kHz vs 2MHz),
so it doesn't sound to me like your code is badly written, it just sounds
like you picked the wrong eeprom...  (OTOH, the 24c32 part has a trivial
"read the next sequential byte" that could be utilized.)

I had noticed that there were different varieties of EEPROMs of varying
complexity, but this is the first time I've noticed the substantial speed
differences!  I think I'll have to pay more attention.  The 93C familly is
fairly low density, but the SPI EEPROM chips (AT25* for atmel) have
densities in the same range as the 24C parts, and behave similarly to the
93C parts... (don't seem to be as available, though.)

BillW

2000\03\15@193027 by Jim Robertson

flavicon
face
At 03:25 PM 3/15/00 PST, you wrote:

>
>I had noticed that there were different varieties of EEPROMs of varying
>complexity, but this is the first time I've noticed the substantial speed
>differences!  I think I'll have to pay more attention.  The 93C familly is
>fairly low density, but the SPI EEPROM chips (AT25* for atmel) have
>densities in the same range as the 24C parts, and behave similarly to the
>93C parts... (don't seem to be as available, though.)
>
>BillW

There are some high density 25C parts available from other supliers already.
(Microchip and xcel)
Regards,

Jim Robertson
NEWFOUND ELECTRONICS
________________________________________
Email: .....newfoundKILLspamspam@spam@pipeline.com.au
http://www.new-elect.com
MPLAB compatible PIC programmers.
________________________________________

2000\03\16@111756 by Rob R

flavicon
face
I still cant see it reading a byte that fast.  With having to output a read/write command unless i dont have to do this.  I use both sequential and random reads, but during sequential reads i still output the device/r/w byte already thats more then 10us.  To read sequentially my code is like 30 lines with a bunch of CALL routines and thats where most of the time is comming from.  Has anyone actually done a BYTE read less then 100us on a 4mhz clock that can show me their code?

Rob R.

On Thu, 16 Mar 2000 11:14:47 +1100 Jim Robertson <newfoundspamKILLspamPIPELINE.COM.AU> wrote:
{Quote hidden}

Send someone a cool Dynamitemail flashcard greeting!! And get rewarded.
GO AHEAD! http://cards.dynamitemail.com/index.php3?rid=fc-41

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