Searching \ for '[EE:] Zilog Circuit Cellar Kit' 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=zilog+circuit+cellar
Search entire site for: 'Zilog Circuit Cellar Kit'.

Exact match. Not showing close matches.
PICList Thread
'[EE:] Zilog Circuit Cellar Kit'
2004\08\19@202725 by Herbert Graf

flavicon
face
On Thu, 2004-08-19 at 19:48, Robert Monsen wrote:

> IIRC, the instruction clock is the same as the crystal input on the Z8
> Encore. There isn't a 'divider' like on the PIC. However, instructions
> generally take more than one instruction cycle.
>
> I didn't realize they were up to 50MHz. Last time I looked, they maxed at a
> 20MHz clock.

Hmm, thanks, well, that then REALLY makes me wonder.

For example, I have this:

       PC_DR &= 0x7f;
       PC_DR &= 0x7f;
       PC_DR &= 0x7f;
       PC_DR &= 0x7f;
       PC_DR &= 0x7f;

       PC_DR |= 0x80;
       PC_DR |= 0x80;
       PC_DR |= 0x80;
       PC_DR |= 0x80;
       PC_DR |= 0x80;

in a loop, and the pin toggles at about 30kHz, so somehow, that code,
along with a for loop, results in: 1666 clock cycles?? Ouch...

I can't find any assembly listing, anyone have any idea how to get ZDS
II to spit out an assembly listing of the code is compiles? Thanks, TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\19@224659 by Robert Monsen

picon face
----- Original Message -----
From: "Herbert Graf" <spam_OUTmailinglist2TakeThisOuTspamFARCITE.NET>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Thursday, August 19, 2004 5:27 PM
Subject: Re: [EE:] Zilog Circuit Cellar Kit


> On Thu, 2004-08-19 at 19:48, Robert Monsen wrote:
>
> > IIRC, the instruction clock is the same as the crystal input on the Z8
> > Encore. There isn't a 'divider' like on the PIC. However, instructions
> > generally take more than one instruction cycle.
> >
> > I didn't realize they were up to 50MHz. Last time I looked, they maxed
at a
{Quote hidden}

You have a read, followed by an and (or or), followed by a write for each of
these. Each statement will probably require 2 or 3 clock cycles to execute,
although, IIRC, some instructions take up to 5. I'm also not sure of the
quality of the optimization.

> in a loop, and the pin toggles at about 30kHz, so somehow, that code,
> along with a for loop, results in: 1666 clock cycles?? Ouch...
>
> I can't find any assembly listing, anyone have any idea how to get ZDS
> II to spit out an assembly listing of the code is compiles? Thanks, TTYL
>

If you are debugging, you can show the assembly under the debug menus. Its
been a while since I looked at this stuff, though. I got an Encore kit some
time last year.

I think the Z8 Encore kit I got had a derated crystal; it was 18MHz rather
than 20MHz for some reason, which threw off timing calcuations.

However, on the whole, I was quite happy with the system; its got a c
compiler, a debug pin you can use to view and set memory (and set
breakpoints) a symbolic debugger, etc. Very nice to use. No simulator (and
none needed!). Unfortunately, its 3.3V, so its somewhat challenging to
interface to other 5V logic. When I tried it out, it was prone to crashes
due to (I believe) noise on the debug pin. I hope they've fixed this.

--
Regards,
Bob Monsen

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\20@001459 by Herbert Graf

flavicon
face
On Thu, 2004-08-19 at 22:46, Robert Monsen wrote:
> You have a read, followed by an and (or or), followed by a write for each of
> these. Each statement will probably require 2 or 3 clock cycles to execute,
> although, IIRC, some instructions take up to 5. I'm also not sure of the
> quality of the optimization.

Hmm, well there is definitely something odd going on, this is the code
it generates:

                               PC_DR |= 0x80;
00020F ED389E              A   318      IN0     A,(158)
000212 B7ED62              A   319      UEXT    HL
000215 6F                  A   320      LD      L,A
000216 01800000            A   321      LD      BC,128
00021A CD 00 00 00         A   322      CALL    __ior
00021E 7D                  A   323      LD      A,L
00021F ED399E              A   324      OUT0    (158),A

Quite involved, but not 1600 cycles worth... I'll have to look deeper
into it.

Thanks anyways for your help. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@033056 by William Chops Westfield

face picon face
On Aug 19, 2004, at 9:07 PM, Herbert Graf wrote:

> Quite involved, but not 1600 cycles worth... I'll have to look deeper
> into it.

Hmm.  How invasive is the debugger mode on those chips?  Last time code
was running hundreds of times slower than I thought it should, it was
because I had left a debug mode on, and it was doing hundreds of times
more stuff than I thought it was (to a port I wasn't paying attention
to.)   The Z80 has a "trace" or "single step" mode where an interrupt
occurs after every instruction.  Very handy for debugging, but you DO
want to make sure that it's turned off before you run benchmarks.
that'd probably cause just about the amount of slowdown you're seeing,
I think.

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@050308 by Alan B. Pearce

face picon face
>Quite involved, but not 1600 cycles worth...

Are you sure? I remember doing some 8085 code many years ago, and being
amazed at how many cycles some of the instructions took. Looking at the
number of bytes some of these instructions are generating ....

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@052345 by Russell McMahon

face
flavicon
face
> >Quite involved, but not 1600 cycles worth...
>
> Are you sure? I remember doing some 8085 code many years ago, and being
> amazed at how many cycles some of the instructions took. Looking at the
> number of bytes some of these instructions are generating ....

Z80 turning in its grave!
Maybe not the very very snappiest processor on earth, but nowhere near that
slow for an assembly language program to toggle a pin.
Us an HLL and who knows what may happen :-)


       RM

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@125527 by Herbert Graf

flavicon
face
On Fri, 2004-08-20 at 03:32, William Chops Westfield wrote:
> On Aug 19, 2004, at 9:07 PM, Herbert Graf wrote:
>
> > Quite involved, but not 1600 cycles worth... I'll have to look deeper
> > into it.
>
> Hmm.  How invasive is the debugger mode on those chips?  Last time code
> was running hundreds of times slower than I thought it should, it was
> because I had left a debug mode on, and it was doing hundreds of times
> more stuff than I thought it was (to a port I wasn't paying attention
> to.)   The Z80 has a "trace" or "single step" mode where an interrupt
> occurs after every instruction.  Very handy for debugging, but you DO
> want to make sure that it's turned off before you run benchmarks.
> that'd probably cause just about the amount of slowdown you're seeing,
> I think.

Hmm, that's a very interesting point, how do you turn on/off debug mode?
I've selected "release" in the GUI but I have no idea whether that
actually turns off debug mode?

Is it a register you set, or is a pin you pull or something like that?
Thanks, TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@141625 by Robert Monsen

picon face
----- Original Message -----
From: "Herbert Graf" <mailinglist2spamKILLspamFARCITE.NET>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Friday, August 20, 2004 9:56 AM
Subject: Re: [EE:] Zilog Circuit Cellar Kit


{Quote hidden}

I believe that debug mode on the Z8 isn't like that; it puts in break
statements by modifying memory using the one-wire debug pin. I don't recall
large slowdowns using the debug port when I was working with it.

I actually think he is in the ballpark for this chip. He says 50kHz, at
50Mhz, so he has 1000 instructions per loop. Knock off 50 cycles for loop
management, and thats 950 cycles. Divide by 10 for his 10 instructions, and
you have 95 cycles per statement. The compiler is obviously not doing an
optimal job speed-wise, since its using function calls to do OR statements
(maybe space wise, which makes some sense). The OR function is a multi-byte
function (oddly, since the port is a single byte.) Also, IO instructions are
quite slow IIRC.

If he declares the constant as an unsigned char, maybe it'll be faster. Its
probably promoting everything to 16 bits due to the constant.

Regards,
Bob Monsen

> -----------------------------
> Herbert's PIC Stuff:
> http://repatch.dyndns.org:8383/pic_stuff/
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@153937 by Herbert Graf

flavicon
face
On Fri, 2004-08-20 at 14:16, Robert Monsen wrote:

> I believe that debug mode on the Z8 isn't like that; it puts in break
> statements by modifying memory using the one-wire debug pin. I don't recall
> large slowdowns using the debug port when I was working with it.
>
> I actually think he is in the ballpark for this chip. He says 50kHz, at
> 50Mhz, so he has 1000 instructions per loop. Knock off 50 cycles for loop
> management, and thats 950 cycles. Divide by 10 for his 10 instructions, and
> you have 95 cycles per statement. The compiler is obviously not doing an
> optimal job speed-wise, since its using function calls to do OR statements
> (maybe space wise, which makes some sense). The OR function is a multi-byte
> function (oddly, since the port is a single byte.) Also, IO instructions are
> quite slow IIRC.
>
> If he declares the constant as an unsigned char, maybe it'll be faster. Its
> probably promoting everything to 16 bits due to the constant.

Wow, well, I must say, coming from PICs, this chip is REALLY beginning
to dissapoint me. If it takes this much more (and instructions) to get a
bloody IO pin to toggle, doing anything else useful REALLY is beggining
to scare me. 1000 instructions to toggle an IO pin? Holy crap. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@154805 by Bob Blick

face picon face
> Wow, well, I must say, coming from PICs, this chip is REALLY beginning
> to dissapoint me. If it takes this much more (and instructions) to get a
> bloody IO pin to toggle, doing anything else useful REALLY is beggining
> to scare me. 1000 instructions to toggle an IO pin? Holy crap. TTYL

Hi Herbert,

Back when I was using the Z8 (1990 or thereabouts) I found it to be a
pretty nice architecture and performance was medium. 12 clocks for most
instructions, or 16 for some external operations with slow memory or I/O.
I was using assembler. The newer chips should have only gotten faster. So
I would make the assumption the development tools are the problem here.

Cheerful regards,

Bob

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@191421 by William Chops Westfield

face picon face
On Aug 20, 2004, at 12:47 PM, Bob Blick wrote:

> Back when I was using the Z8

This *is* one of the ez80 chips (z80), not a z8.

I don't know how to check debug mode/etc; I only have one of the ez8
kits...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@203838 by Bob Barr

flavicon
face
On Fri, 20 Aug 2004 15:38:47 -0400, Herbert Graf wrote:

>
>Wow, well, I must say, coming from PICs, this chip is REALLY beginning
>to dissapoint me. If it takes this much more (and instructions) to get a
>bloody IO pin to toggle, doing anything else useful REALLY is beggining
>to scare me. 1000 instructions to toggle an IO pin? Holy crap. TTYL
>

It's not the chip slowing things down; it's the compiler. This code
could be far, far faster if it were written in assembler rather than
in C or if the compiler can optimize the code it generates.

Take a look at the code that's generated here.

The "__ior" subroutine call operates on 16-bit values.

Promotion of the port value to 16 bits adds cycles.

Loading the constant as a 16-bit value when only a byte is required
adds cycles.

The "call __ior" and the return from it add even more.

All of those extra cycles add up.

                               PC_DR |= 0x80;
     IN0     A,(158)        ; read the port into A
     UEXT    HL            ; sign extend into H
     LD      L,A               ; copy port value into L
     LD      BC,128       ; load byte 80h into BC
     CALL    __ior         ; or the BC and HL register pairs into HL
     LD      A,L               ; copy value to A
     OUT0    (158),A     ; write it back to the port

<speculation
In the __ior subroutine execution, I'd expect that each byte in the BC
register would be copied into A, then "or'd" with the corresponding
byte of the HL register.
/speculation>


In assembly, this could be done as simply as:

   in0  a,(158)
   ior   128
   out0 (158),a

I have no idea how (or IF) you could get the compiler to optimize it
that far.



Regards, Bob

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\20@215840 by William Chops Westfield

face picon face
On Aug 20, 2004, at 5:36 PM, Bob Barr wrote:

>
> The "call __ior" and the return from it add even more.
>
> All of those extra cycles add up.
>
It still shouldn't take 1000 cycles...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\08\21@025640 by Bob Barr

flavicon
face
On Fri, 20 Aug 2004 18:58:54 -0700, William Chops Westfield wrote:

>On Aug 20, 2004, at 5:36 PM, Bob Barr wrote:
>
>>
>> The "call __ior" and the return from it add even more.
>>
>> All of those extra cycles add up.
>>
>It still shouldn't take 1000 cycles...
>

In the original C code, each "and" operation and each "or" operation
is being repeated 5 times so I'd expect each repetition is taking 200
cycles.

All Z80 instructions take multiple cycles to execute. On the original
Z80, the minimum number of cycles is 4 and the maximum can go as high
as 16 or more cycles. (Several of the instructions generated in this
case are 'prefixed' instructions which take a few cycles more than
most. There may be more of them in the subroutine code.) The
subroutine call and return instructions alone would take 26 cycles to
execute. Some additional unknown number of cycles will be spent
excuting the subroutine code.

You don't need to execute very many multi-cycle instructions to burn
200 clock cycles.

Figuring timing budgets on a Z80 can be a real eye-opener.


Regards, Bob

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\08\22@165813 by Herbert Graf

flavicon
face
part 1 2332 bytes content-type:text/plain (decoded 7bit)

On Sat, 2004-08-21 at 02:54, Bob Barr wrote:
> You don't need to execute very many multi-cycle instructions to burn
> 200 clock cycles.
>
> Figuring timing budgets on a Z80 can be a real eye-opener.

It would appear so. Thanks to all for the help. I have condensed my
results so perhaps somebody here will be able to tell me with certainty
if this is the best I can expect.

I have the following code:

while (1)
{
       PC_DR |= (char)0x80;    // MCLK high

       PC_DR &= (char)0x7f;    // MCLK low
}

Which compiles to this:

53                              while (1)
0000A9                     A   134    L_12:
                          A   135    ;   54                            {
                          A   136    ;   55                            PC_DR |= (char)0x80;    //
MCLK high
0000A9 ED389E              A   137      IN0     A,(158)
0000AC CBFF                A   138      SET     7,A
0000AE ED399E              A   139      OUT0    (158),A

61                              PC_DR &= (char)0x7f;    // MCLK low
0000B1 ED389E              A   146      IN0     A,(158)
0000B4 CBBF                A   147      RES     7,A
0000B6 ED399E              A   148      OUT0    (158),A

0000B9 C3 A9 00 00         A   154      JMP     L_12

Which looks reasonable to me, yet when I put a scope on the pin I get a
50kHz signal (please see attached image).

Does this seem at all reasonable to anyone?

I see nothing in the assembly that would take ANYWHERE near as long as
that, could the IO accesses REALLY be burning that many clock cycles? I
don't know how many cycles the JMP L_12 takes, but I can't imagine it's
in the hundreds.

FWIW the dev kit is SUPPOSED to run at 50MHz, so I'm seeing 1000 clock
cycles needed to execute the above code.

I REALLY hope I'm doing something wrong, otherwise this contest entry
will be academic at best, I'll probably enter with a piss poor slow
thing, and then rewrite everything for a PIC or AVR with a support CPLD
to make things easier on me...

Thanks again to all for your help. TTYL




-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body




part 2 9607 bytes content-type:image/jpeg (decode)

2004\08\22@172112 by Robert Monsen

picon face
Is it just me, or does that waveform look odd? The high time is 10x the low
time... To me, it seems like the low time should be slightly longer than the
high time.

Are you sure you are executing the statements below, or that your pins are
configured like you think they are?

Another possibility is that the OUT0 followed immediately by the IN0 is
causing problems, perhaps some wierd hazard in the chip.

Did you try this just writing the values, as opposed to doing the and/or
thing? ie,

while(1) {
 PC_DR = (char) 0x80;
 PC_DR = (char) 0;
}

Another thing to try would be to unroll about 20 of these and see what it
looks like:

while(1) {
PC_DR |= (char) 0x80;
PC_DR &= (char) ~0x80;
PC_DR |= (char) 0x80;
PC_DR &= (char) ~0x80;
PC_DR |= (char) 0x80;
PC_DR &= (char) ~0x80;
PC_DR |= (char) 0x80;
PC_DR &= (char) ~0x80;
...
}

You could set another pin the first time to trigger on if you have a two
channel scope.

Regards,
Bob Monsen

{Original Message removed}

2004\08\22@172113 by Herbert Graf

flavicon
face
part 1 3063 bytes content-type:text/plain (decoded 7bit)

On Sun, 2004-08-22 at 16:59, Herbert Graf wrote:
{Quote hidden}

Woops, small mistake on my part, was referencing the wrong image, I'm
actually seeing 500kHz coming out, NOT 50kHz, please see the image
attached to THIS message an ignore the earlier one...

> Does this seem at all reasonable to anyone?
>
> I see nothing in the assembly that would take ANYWHERE near as long as
> that, could the IO accesses REALLY be burning that many clock cycles? I
> don't know how many cycles the JMP L_12 takes, but I can't imagine it's
> in the hundreds.
>
> FWIW the dev kit is SUPPOSED to run at 50MHz, so I'm seeing 1000 clock
> cycles needed to execute the above code.

This should read:

FWIW the dev kit is SUPPOSED to run at 50MHz, so I'm seeing 100 clocks
cycles needed to execute the above code.

> I REALLY hope I'm doing something wrong, otherwise this contest entry
> will be academic at best, I'll probably enter with a piss poor slow
> thing, and then rewrite everything for a PIC or AVR with a support CPLD
> to make things easier on me...
>
> Thanks again to all for your help. TTYL

Sorry about my previous post. Still, 100 clock cycles to toggle a pin??

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body




part 2 9537 bytes content-type:image/jpeg; name=aclaim.jpg (decode)

2004\08\22@172318 by William Chops Westfield

face picon face
On Aug 22, 2004, at 1:59 PM, Herbert Graf wrote:

>
> Which looks reasonable to me, yet when I put a scope on the pin I get a
> 50kHz signal (please see attached image).
>
The IDE includes a simulator as well as connection to the live board,
doesn't it?  Does that simulator have timing capabilities?

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@173815 by William Chops Westfield

face picon face
On Aug 22, 2004, at 2:19 PM, Herbert Graf wrote:
>
> Sorry about my previous post. Still, 100 clock cycles to toggle a pin??
>
>
Well, I count 20 bytes worth of program, so 100 clock cycles is not
totally out of the question if each byte takes at least one cycle to
fetch (should be true), and a couple of cycles to execute (shouldn't be
true - instruction timings are supposed to be for the whole
instruction, I think)   It's about what i'd expect from an old z80 with
4-cycle fetches; your chip doesn't have an "old z80 compatible slow
mode" that you got into somehow, does it?

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@184108 by steve

flavicon
face
> Woops, small mistake on my part, was referencing the wrong image, I'm
> actually seeing 500kHz coming out, NOT 50kHz, please see the image
> attached to THIS message an ignore the earlier one...

That looks like you are bandwidth limited somewhere in the chain. How
close is 2us/div to the maximum setting of your scope ?
If you are close to the bandwidth limit of the scope, it is likely that you
may also near the sampling limit and you may be seeing an alias of the
higher frequency.


Steve.

==========================================
Steve Baldwin                          Electronic Product Design
TLA Microsystems Ltd             Microcontroller Specialists
PO Box 15-680, New Lynn                http://www.tla.co.nz
Auckland, New Zealand                     ph  +64 9 820-2221
email: RemoveMEsteveTakeThisOuTspamtla.co.nz                      fax +64 9 820-1929
=========================================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@190111 by Herbert Graf

flavicon
face
On Sun, 2004-08-22 at 18:40, TakeThisOuTsteveEraseMEspamspam_OUTTLA.CO.NZ wrote:
> > Woops, small mistake on my part, was referencing the wrong image, I'm
> > actually seeing 500kHz coming out, NOT 50kHz, please see the image
> > attached to THIS message an ignore the earlier one...
>
> That looks like you are bandwidth limited somewhere in the chain. How
> close is 2us/div to the maximum setting of your scope ?
> If you are close to the bandwidth limit of the scope, it is likely that you
> may also near the sampling limit and you may be seeing an alias of the
> higher frequency.

The scope is a 10MHz one, the speed is correct as confirmed by a
frequency counter.

The "odd" shape of the waveform is I believe due to the limits of the
output drivers of the Aclaim, a PIC outputting a similar frequency looks
"perfect" on my scope. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@192318 by Herbert Graf

flavicon
face
On Sun, 2004-08-22 at 17:38, William Chops Westfield wrote:
> On Aug 22, 2004, at 2:19 PM, Herbert Graf wrote:
> >
> > Sorry about my previous post. Still, 100 clock cycles to toggle a pin??
> >
> >
> Well, I count 20 bytes worth of program, so 100 clock cycles is not
> totally out of the question if each byte takes at least one cycle to
> fetch (should be true), and a couple of cycles to execute (shouldn't be
> true - instruction timings are supposed to be for the whole
> instruction, I think)   It's about what i'd expect from an old z80 with
> 4-cycle fetches; your chip doesn't have an "old z80 compatible slow
> mode" that you got into somehow, does it?

Hmm, no clue, anybody know how to enable/disable that? I've searched
through the spec sheet but there is no mention on that. Thanks, TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@193609 by Herbert Graf

flavicon
face
On Sun, 2004-08-22 at 17:22, William Chops Westfield wrote:
> On Aug 22, 2004, at 1:59 PM, Herbert Graf wrote:
>
> >
> > Which looks reasonable to me, yet when I put a scope on the pin I get a
> > 50kHz signal (please see attached image).
> >
> The IDE includes a simulator as well as connection to the live board,
> doesn't it?  Does that simulator have timing capabilities?
>
> BillW

Hmm, I did try the simulator, it shows:

start time:     clocks=422              seconds=8.44E-6
stop time:      clocks=443              seconds=8.86E-6

That equates to: 2.38MHz

That would seem to match with what the assembly shows, so I definately
have SOMETHING wrong with the dev kit, grr...

Thanks for the suggestion. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@200117 by Matt Pobursky

flavicon
face
On Sun, 22 Aug 2004 19:36:53 -0400, Herbert Graf wrote:
> Hmm, I did try the simulator, it shows:
>
> start time:     clocks=422              seconds=8.44E-6 stop time:
> clocks=443              seconds=8.86E-6
>
> That equates to: 2.38MHz
>
> That would seem to match with what the assembly shows, so I
> definately have SOMETHING wrong with the dev kit, grr...
>
> Thanks for the suggestion. TTYL

Herbert,

Check the eZ80 datasheet -- I seem to recall that the internal flash
has is quite slow and uses a bunch of wait states. Also make sure they
are not using RAM with wait states. The external bus cycles at 50 MHz
are pretty short and take some darn fast (and expensive) memories to
run with few or no wait states.

I ran into this same kind of problem with the Rabbit CPUs when they
came out with their 44MHz R3000 chip. It only ran marginally faster
than a 22MHz R2000 CPU. The cause was adding wait states because they
used Flash that couldn't run with 0 wait states.

Matt Pobursky
Maximum Performance Systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\22@210608 by Herbert Graf

flavicon
face
On Sun, 2004-08-22 at 20:00, Matt Pobursky wrote:
> Herbert,
>
> Check the eZ80 datasheet -- I seem to recall that the internal flash
> has is quite slow and uses a bunch of wait states. Also make sure they
> are not using RAM with wait states. The external bus cycles at 50 MHz
> are pretty short and take some darn fast (and expensive) memories to
> run with few or no wait states.
>
> I ran into this same kind of problem with the Rabbit CPUs when they
> came out with their 44MHz R3000 chip. It only ran marginally faster
> than a 22MHz R2000 CPU. The cause was adding wait states because they
> used Flash that couldn't run with 0 wait states.
>
> Matt Pobursky
> Maximum Performance Systems

BINGO!!! Thank you so much Matt, I think you nailed it on the head!

I changed the config from "run from ROM" to "run from RAM" and BOOM,
twice the speed! My little ping toggles at 2-3 times the speed. Well, at
least now I know. Thank you all again for your help.

That said, I guess it really shows how much more efficient a PIC can be
(even with a /4 of the main clock) for simple IO stuff.

This thing is still gonna run slower then I was expecting, so I guess
I'll go ahead with what I was thinking, and then move it to a
PIC/AVR+CPLD when I'm done. Thanks again, TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\24@145819 by James Newton

face picon face
source= http://www.piclist.com/piclist/2004/08/22/145607a.txt?

Robert Monsen  says:
> Typical C. Everything in an expression is promoted to the
> largest type in the expression before the operation.
>
You might be interested in http://www.sxlist.com/techref/expeval2.asp which is a minimal expression evaluator which tracks the actual width of each part to ensure an exact answer.

---
James Newton: PICList.com webmaster, former Admin #3
RemoveMEjamesnewtonTakeThisOuTspamspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


'[EE:] Zilog Circuit Cellar Kit'
2004\09\09@115820 by Bob Ammerman
picon face

----- Original Message -----
From: "Jean-Michel Howland" <EraseMEjmhspamspamspamBeGoneinnaloo.net>
To: "Microcontroller discussion list - Public." <RemoveMEpiclistKILLspamspammit.edu>
Sent: Thursday, September 09, 2004 4:31 AM
Subject: Re: [EE:] Zilog Circuit Cellar Kit


> Herbert,
>
> I finally hooked up the BitScope to the ZiLOG dev board and with this
small
{Quote hidden}

This should be a bit faster:

                 ld      a,00h
                 out0    (PC_ALT2),a
                 out0    (PC_ALT1),a
                 out0    (PC_DDR),a
                 inc     a
loop:
                 dec     a
                 out0    (PC_DR),a
                 inc      a
                 out0    (PC_DR),a
                 jr      loop


If the timing is the same as the original Z80, then "ld a,nn"
takes 7 cycles, but "inc a" only takes 4. This would save
6 cycles per loop iteration.

Bob Ammerman
RAm Systems

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\09@134550 by Herbert Graf

flavicon
face
On Thu, 2004-09-09 at 04:31, Jean-Michel Howland wrote:
{Quote hidden}

Yes, that would pretty much match my results. Very disappointing. Coming
from the PIC world I was expecting to do a little more on the I/O side
then hundreds of kHz with a 50MHz part. Oh well.

FWIW I've pretty much given up on the kit, it just isn't as capable as I
thought it would be, shame really. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\09@143512 by Mark Jordan

flavicon
face

       Pin toggle at 1.2MHz can be done with an AVR running at 2.4MHz.

       The loop would be something like:

loop:
               cbi        PORTx, bit0
               sbi        PORTx, bit0
               rjmp        loop

       Mark Jordan


On 9 Sep 2004 at 13:45, Herbert Graf wrote:

{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\09@145307 by Dave VanHorn

flavicon
face
At 01:16 PM 9/9/2004, Mark Jordan wrote:


>        Pin toggle at 1.2MHz can be done with an AVR running at 2.4MHz.
>
>        The loop would be something like:
>
>loop:
>                cbi     PORTx, bit0
>                sbi     PORTx, bit0
>                rjmp    loop

I simmed it at 1.5uS/loop at 4 MHz.
The jump back takes two cycles, as does the bit set and clear in I/O
It's 1uS even for toggling a bit in a register.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\09@230805 by Jean-Michel Howland

flavicon
face

>Yes, that would pretty much match my results. Very disappointing. Coming
>from the PIC world I was expecting to do a little more on the I/O side
>then hundreds of kHz with a 50MHz part. Oh well.
>
>FWIW I've pretty much given up on the kit, it just isn't as capable as I
>thought it would be, shame really. TTYL

If you want to part with the F91 module, I'd be willing to buy it from you
for a reasonable price.

Regards
Jean-Michel.


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\09@234137 by Herbert Graf

flavicon
face
On Thu, 2004-09-09 at 23:08, Jean-Michel Howland wrote:
> >Yes, that would pretty much match my results. Very disappointing. Coming
> >from the PIC world I was expecting to do a little more on the I/O side
> >then hundreds of kHz with a 50MHz part. Oh well.
> >
> >FWIW I've pretty much given up on the kit, it just isn't as capable as I
> >thought it would be, shame really. TTYL
>
> If you want to part with the F91 module, I'd be willing to buy it from you
> for a reasonable price.

Since I got it for free I wouldn't feel right doing something like that.

I do have a plan to use it for something completely different,
unfortunately that project is far down the pipe so it wouldn't be
completed in time for the contest. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

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