Maker Pro
Maker Pro

My hat is off to Microchip and their CEO!

B

Bob Larter

Jan 1, 1970
0
David said:
They have even posted this hillarious video response in record time:

I am absolutely blown away by their honesty and responsiveness, and it
starts from their CEO down.
Two thumbs up to Steve Sanghi and the guys and gals at Microchip!

Very cool, Dave.
BTW, I loved your #40 blog[0], but I'm worried that it could get you in
trouble. Have your bosses discovered your blog yet?

[0] I've worked on several Doomed Projects myself.
 
D

David L. Jones

Jan 1, 1970
0
Bob said:
David said:
They have even posted this hillarious video response in record time:

I am absolutely blown away by their honesty and responsiveness, and
it starts from their CEO down.
Two thumbs up to Steve Sanghi and the guys and gals at Microchip!

Very cool, Dave.
BTW, I loved your #40 blog[0], but I'm worried that it could get you
in trouble. Have your bosses discovered your blog yet?

Yes, my company is fully aware I do it, and I work within their blogging
guidelines (yes, they actually encourage us to do this sort of thing).
But all of those projects are from previous companies (now mostly folded),
so no problem!

Dave.
 
J

Jon Kirwan

Jan 1, 1970
0
Just one? One of my designs is about to go into production with two
F120s clocked at nearly 90MHz. One of them is just about fully busy. The
other has many microseconds to spare.

I'm clocked at 24MHz. Which is fine enough. I think it's about 422
SYSCLKs. At 90MHz, that would be more like 4.5 microseconds. But I'm
not there.
Do you really need true floating point? do you really need ln() or
would log2() do? 18 microseconds seems a little slow.

It's running on 24MHz, not 90MHz, for one thing. And it needs 20
precision bits in the result with an input value possessing a good 30
bits (the compiled result of thousands of other measurements.)
Doing log2() of a 32 bit floater can be fairly quick if you don't
care much about how much code space you use.

Well, I'm good already. Plus, it is custom-tailored to the job.
Real men code in assembly anyway.

I think better programmers are well experienced in using assembly and
will use it as appropriate, taking into account the tasks and clients.
Lacking such experience is the loss of a significant mental and
practical toolset that could otherwise be brought to bear on problems.
That doesn't mean every application gets coded entirely in assembly.

Jon

 
D

Don McKenzie

Jan 1, 1970
0
David said:
You aren't going to believe this...

I recently reviewed the new Microchip PICkit3 compared to the old PICkit2
and pretty much hammered the people responsible on behalf of those who have
found the PICkit3 upgrade rather lacking:

Dave, compliments of Spehro Pefhany, the MC PICkit3 story made it to the
Piclist also:

http://old.nabble.com/Microchip's-customer-relations..-excellent-response-td26128622.html
Hope you can read it there without going through the login hoops

Cheers Don...



--
Don McKenzie

Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
Web Camera Page: http://www.dontronics.com/webcam
No More Damn Spam: http://www.dontronics.com/spam

Breakout, Prototype, Development, & Robotics Boards:
http://www.dontronics-shop.com/sparkfun-electronics.html
 
J

Jon Kirwan

Jan 1, 1970
0
By the way, since you use SiLabs regularly and I've only been using
their IDE for a month... How do you get it to display some 'cycle
count' figure? I'd like to see an absolute figure, best of all, and
take a snapshot of it from the debugger at the start of a routine then
take a snapshot at the end of its execution and simply subtract.
Rather than sitting there staring at the code and manually counting.
Many other IDEs support this. I can display SFRs and set up a timer,
but for one it may be too coarse (if I have the usual /12 going on)
and requires that extra effort in software. I was hoping they simply
counted SYSCLKs, on the debugger device end of things. One way I do
this now is to loop a large block of code and use a timer and then
divide to get a more accurate mean value. But it's a bit of a pain.

If there's nothing, that's fine. I'm just looking for a quick answer
if you happen to have one handy.

Jon
 
N

Nico Coesel

Jan 1, 1970
0
David L. Jones said:
Also when looking for a long term investment in micros you may have to
consider the companies viability.

Not really. Most of the cost for designing a product goes into the
firmware. If you use PIC and want to switch to another platform you'll
quickly learn that porting C code from or to PIC is almost impossible
for any real piece of firmware*. If you start out with say Renesas H8,
TI's MSP430 or any ARM flavor you'll find exchanging C code between
those is very easy.

* I know the pheripherals are different. Hardware drivers are least of
the problem though.
 
J

Jon Kirwan

Jan 1, 1970
0
The JTAG section appears to not know anything about what the clock
speed is other than requiring more than 32KHz to work.

I had incorrectly imagined that maybe because the JTAG actually clocks
stuff in and out and in the process then also drives a single-step
SYSCLK equivalent to advance through an instruction that it may
provide that internal information on a display. It's very hard for me
to imagine, when stepping using F11, that the JTAG uses the external
clock. But perhaps my imagination is too limited.

Jon
 
M

M.Randelzhofer

Jan 1, 1970
0
David L. Jones said:
You aren't going to believe this...

I recently reviewed the new Microchip PICkit3 compared to the old PICkit2
and pretty much hammered the people responsible on behalf of those who
have found the PICkit3 upgrade rather lacking:
http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/

At it turns out, not surprisingly the video made it's way all around the
Microchip offices, even to the desk of their CEO.
As with any multi billion dollar corporation, I expected either deathly
silence or a nasty letter from their lawyers.

But it turns out Microchip really do care about their products and
customers, and really do listen, so they seriously took it as constructive
criticism.

So not only was my blog well received at Microchip, I got a lengthy call
from none other than the Microchip CEO Steve Sanghi, thanking me for the
blog and raising the issues. He pointed out a few factual errors which was
fair enough, but admitted they could have done the PICkit 3 better and
most importantly are working to fix the issues and give customers what
they expect.

They have even posted this hillarious video response in record time:

I am absolutely blown away by their honesty and responsiveness, and it
starts from their CEO down.
Two thumbs up to Steve Sanghi and the guys and gals at Microchip!

Dave.

Sadly also the Microchip Serial Memory Programmer now is supported by MPLAB
only, the former standalone software SEEVAL32 (on the former programmer with
a COM port) was handy and easier to use.
see:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535259
http://search.digikey.com/scripts/D...link=hp_go_button&KeyWords=DV243003&x=16&y=14

Anyhow the new product works fine and is cheap, and the Microchip response
is funny, and lets hope for an SW upgrade for the PICKIT3 and maybe also for
the serial memory programmer.

Does anybody use the pickit serial analyzer ?
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028600

By the way Dave, your video blog is excellent !

MIKE

--
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
[email protected]
Usst.ID: DE130097310
 
J

Jon Kirwan

Jan 1, 1970
0
I think that the clock is only needed to be able to stop the micro. I
doesn't seem to care that much about the clock when it is running or
already stopped. It gets very angry with me on the few cases where I
tried to stop a micro that had no clock.

My initial board was without a crystal, so just using the internal one
during initial code writing. Seems to work just fine. But I haven't
tried to disable it first, either.

In any case, thanks for the suggestion and removing my desire to keep
looking for a display on the debugger. It will save me bothering with
that silly hope anymore.

Jon
 
B

Bob Larter

Jan 1, 1970
0
David said:
Bob said:
David said:
They have even posted this hillarious video response in record time:

I am absolutely blown away by their honesty and responsiveness, and
it starts from their CEO down.
Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
Very cool, Dave.
BTW, I loved your #40 blog[0], but I'm worried that it could get you
in trouble. Have your bosses discovered your blog yet?

Yes, my company is fully aware I do it, and I work within their blogging
guidelines (yes, they actually encourage us to do this sort of thing).
But all of those projects are from previous companies (now mostly folded),
so no problem!

Ah, good.
 
J

JosephKK

Jan 1, 1970
0
I had incorrectly imagined that maybe because the JTAG actually clocks
stuff in and out and in the process then also drives a single-step
SYSCLK equivalent to advance through an instruction that it may
provide that internal information on a display. It's very hard for me
to imagine, when stepping using F11, that the JTAG uses the external
clock. But perhaps my imagination is too limited.

Jon

Jon, something to understand, standards are all about compromises. The
JTAG standards were forced to be about functional verification rather
than measuring performance because of this.
 
J

Jon Kirwan

Jan 1, 1970
0
Jon, something to understand, standards are all about compromises. The
JTAG standards were forced to be about functional verification rather
than measuring performance because of this.

As I understand JTAG, broadly speaking, its simply a very long shift
register. There is boundary checking, of course. But flashing and
debugging, too. In fact, many internal registers and various flip
flops are available that aren't all visible to the casual programmer,
as well. It's not rocket science or even vaguely difficult to count
cycles, as I gather it.

Jon
 
N

Nico Coesel

Jan 1, 1970
0
Jon Kirwan said:
As I understand JTAG, broadly speaking, its simply a very long shift
register. There is boundary checking, of course. But flashing and

It most certainly is not. JTAG is a way to access internal registers
addressed by commands. On top of JTAG there usually is a complicated,
buggy protocol to access CPU registers (and memory if you are lucky).
 
J

Jon Kirwan

Jan 1, 1970
0
It most certainly is not.

Must be some other interface I remember, then. I was able to shift
out and examine almost every internal flip-flop state, for example.
Thousands of bits worth. Gave me access to pretty much everything, if
the designers included the bits into the serial chain. I'd use test
vectors which allowed me to set register values, both hidden and
observable to a programmer, etc., before taking an instruction step.
JTAG is a way to access internal registers
addressed by commands. On top of JTAG there usually is a complicated,
buggy protocol to access CPU registers (and memory if you are lucky).

I'll try and remember what exactly it was I'd used before, then. I'll
take your point, for now. It's quite possible I've conflated JTAG
with something else.

Jon
 
K

krw

Jan 1, 1970
0
Must be some other interface I remember, then. I was able to shift
out and examine almost every internal flip-flop state, for example.
Thousands of bits worth. Gave me access to pretty much everything, if
the designers included the bits into the serial chain. I'd use test
vectors which allowed me to set register values, both hidden and
observable to a programmer, etc., before taking an instruction step.

The designers don't want you to have that information. It's the
family jewels. Emulation types get it only after signing a pile of
contracts and giving up their first offspring.
I'll try and remember what exactly it was I'd used before, then. I'll
take your point, for now. It's quite possible I've conflated JTAG
with something else.

No, these things are often accessible via JTAG. The interface could
be "buggy" I suppose, though would highly doubt. It may not be well
documented since it's not generally accessible by anyone outside the
chip manufacturer.
 
J

Jon Kirwan

Jan 1, 1970
0
The designers don't want you to have that information. It's the
family jewels. Emulation types get it only after signing a pile of
contracts and giving up their first offspring.

Normally, I suppose. I think the ARM7 documentation discloses much,
if not all. Or perhaps I'm wrong about that, as well. However, my
case was for a different processor.
No, these things are often accessible via JTAG. The interface could
be "buggy" I suppose, though would highly doubt. It may not be well
documented since it's not generally accessible by anyone outside the
chip manufacturer.

So are you saying that my original post is essentially correct, then?
That JTAG is at its fundamental level a shift register chaining
together state bits of possible interest? (It's how I'd imagined it
up to now, until Nico wrote to tell me I was wrong, but I admit not
being an expert in this area.)

Jon
 
K

krw

Jan 1, 1970
0
Normally, I suppose. I think the ARM7 documentation discloses much,
if not all. Or perhaps I'm wrong about that, as well. However, my
case was for a different processor.

Could be they've laid the whole design out hoping someone would copy
it? Dunno, but this is usually *highly* sensitive information. We
had a lot of hidden performance and feature switches in there that we
certainly didn't want the user diddling with (or so much as knowing
they were even there).
So are you saying that my original post is essentially correct, then?

Essentially, though different manufacturers may use it differently.
That JTAG is at its fundamental level a shift register chaining
together state bits of possible interest? (It's how I'd imagined it
up to now, until Nico wrote to tell me I was wrong, but I admit not
being an expert in this area.)

That's pretty much it. "Of interest" may be the sticking point. Of
interest to whom? The manufacturer has different uses than the user.
Both may be accommodated in JTAG but the manufacturer my not disclose
the information needed to get at the guts of the chip. For example,
they may only disclose the boundary scan stuff for ICT and keep
everything else a trade secret. The manufacturer may be able to get
at every latch in the chip (as we did, though this was "free" because
of the design rules) but I'd be very surprised to see one publish this
information. ...if for no other reason than it changes from rev to
rev.

JTAG is a requirement so why not use it for the kitchen sink too.
 
J

Jon Kirwan

Jan 1, 1970
0
Could be they've laid the whole design out hoping someone would copy
it? Dunno, but this is usually *highly* sensitive information. We
had a lot of hidden performance and feature switches in there that we
certainly didn't want the user diddling with (or so much as knowing
they were even there).


Essentially, though different manufacturers may use it differently.

Thanks. I'm glad to keep my prior mental model and discard Nico's
distraction from it.
That's pretty much it. "Of interest" may be the sticking point. Of
interest to whom?

Yes. That is implied. This is the internals we are talking about and
that can get into nitty-gritty implementation details if the
manufacturer decides to expose any of that. They could just chain
together obvious things only. But then it wouldn't be nearly as
useful.


The manufacturer has different uses than the user.
Both may be accommodated in JTAG but the manufacturer my not disclose
the information needed to get at the guts of the chip. For example,
they may only disclose the boundary scan stuff for ICT and keep
everything else a trade secret. The manufacturer may be able to get
at every latch in the chip (as we did, though this was "free" because
of the design rules) but I'd be very surprised to see one publish this
information. ...if for no other reason than it changes from rev to
rev.

Personally, I would like _everything_ out on the table and in plain
view. Intel would provide regular specification updates on their
chips, including changes in package designators, bugs that apply to
one and not another, and so on. It should be no real issue to include
the complete JTAG chain disclosed for each stepping and change, as
well. And let users beware.

If someone doesn't want to worry their pretty little head over these
things, they can leave it to some commercial vendor to do. If they
want to, then they can. Simple.

But disclose.
JTAG is a requirement so why not use it for the kitchen sink too.

Hehe. I sure would. Expose every single state bit to the chain.
Combinatorials don't have state, so no worry. If it holds a state,
chain it.

Jon
 
N

Nico Coesel

Jan 1, 1970
0
Jon Kirwan said:
Normally, I suppose. I think the ARM7 documentation discloses much,
if not all. Or perhaps I'm wrong about that, as well. However, my
case was for a different processor.

The ARM documentation specifies most internals behind the JTAG
interface. The documentation on how to access the registers through
JTAG is usually a few pages. The 100+ pages describe the rest.
So are you saying that my original post is essentially correct, then?
That JTAG is at its fundamental level a shift register chaining
together state bits of possible interest? (It's how I'd imagined it

No, like I typed before: JTAG offers a bunch of registers addressed by
a command register. Generally speaking: If you want to read pins,
you'll need to send a command 'read pins' followed by several reads of
the data register.
 
K

krw

Jan 1, 1970
0
Thanks. I'm glad to keep my prior mental model and discard Nico's
distraction from it.


Yes. That is implied. This is the internals we are talking about and
that can get into nitty-gritty implementation details if the
manufacturer decides to expose any of that. They could just chain
together obvious things only. But then it wouldn't be nearly as
useful.

The minimum, of course, is the boundary scan. That's a customer
requirement for ICT. From there, it's a convenient port for the
manufacturer.
The manufacturer has different uses than the user.

Personally, I would like _everything_ out on the table and in plain
view. Intel would provide regular specification updates on their
chips, including changes in package designators, bugs that apply to
one and not another, and so on. It should be no real issue to include
the complete JTAG chain disclosed for each stepping and change, as
well. And let users beware.

You might like a vacation on the International Space Station too. It's
not in the manufacturer's interest to tell you all his secrets.
....particularly ones that are trade secrets or you have no need to
know.
If someone doesn't want to worry their pretty little head over these
things, they can leave it to some commercial vendor to do. If they
want to, then they can. Simple.

It's not that simple. Documenting this stuff for others to use is
difficult and it does change.
But disclose.

What's in it for the manufacturer, other than losing control of their
trade secrets and increased costs? What would you do with a listing
of 10M latches?
Hehe. I sure would. Expose every single state bit to the chain.
Combinatorials don't have state, so no worry. If it holds a state,
chain it.

You forget what that costs. In the chips I worked on there was no
cost because that was already done because of the design rules and
JTAG was simply a convenient port to access these latch "chains".
Other design methodologies may not make this so easy. Would you spend
10% of a chip's logic to do this? 20%? 30%?
 
Top