<altz...@gmail.com> wrote: >Jon Kirwan wrote: >> On Fri, 30 Oct 2009 15:43:58 +0000, Raveninghorde >> <raveninghorde@invalid> wrote:
>>> On Fri, 30 Oct 2009 06:52:49 -0700 (PDT), MooseFET >>> <kensm...@rahul.net> wrote:
>>>> On Oct 30, 4:57 am, Al Borowski <al.borow...@gmail.com> wrote: >>>>>> Briefly, the Modified-Harvard architecture used in the PIC devices >>>>>> separates the program memory from the data memory, in other words >>>>>> separates the ROM/FLASH program memory from the RAM.
>>>>> [...]
>>>>> Yes, but there's more to to a uC core then choosing between >>>>> Harvard or >>>>> Von Neumann. I think most of the PICs quirks come from the other >>>>> decisions made.
>>>>> The PIC (up to 16 bit cores anyway) is an accumulator architecture >>>>> - >>>>> you have to funnel everything through the W register.
>>>> Going with accumulator model allowed Microchip to make the processor >>>> with fewer transistors. It is a trade off that can break either way. >>>> If you have a limit on the chip size you can make a higher >>>> performance processor that is harder to program.
>>>> [....] >>>>> in the 16 bit core thankfully). Personally, I think the most >>>>> annoying >>>>> thing about programming PICs in assembly are the btfsc (test a bit >>>>> in 'file', skip the next instruction if it's clear) and btfss >>>>> (same thing >>>>> but skip if set) instructions. Why they couldn't just call these >>>>> ifbit >>>>> and ifnbit, I don't know :-)
>>>> Does ifbit mean skip if the bit is set or do the instruction if the >>>> bit is set?
>>>>> Back to the OP, great job Microchip on the video. It's a nice >>>>> contrast >>>>> to TI, who recently sent misleading DMCA notices to people who >>>>> tried >>>>> installing after-market OSs on their graphics calculators >>>>> (http://news.cnet.com/8301-30685_3-10374284-264.html)
>>>>> Cheers,
>>>>> A;
>>>> I still prefer the 8051. It is way better. >>>> [ducks]
>>> So do I. The 8051 family was/is great.
>> I'm using one from SiLabs, right now. Last 8051 project I did was >> back in the early 1980's. (Still have a box of about 100 80C32 chips >> in perfect shape.) For this app, I needed a much faster floating >> point ln(x) function (achieved under 18 microseconds) and found myself >> spending some time coding assembly on it. No question in my mind that >> this processor was designed with hand-coded assembly in mind, though. >> Very easy to use efficiently for a human coder, though I do have to >> check the book often to see if a particular instruction supports a >> particular mode of access, yet just the kind of thing to seriously >> complicate a compiler's life.
>>> But I found the varients of 8051 I used were obsolete on more than >>> one occassion causing problems. I'm still sourcing SAB80C517 at silly >>> prices for example.
>> I gather that Atmel has an AT89 line that includes an external bus and >> so does SiLabs. Not sure how either of these would score on not >> obsoleting designs, though.
>>> I first used the PIC for very low cost apps around 1990 and found >>> that there was always an upgrade path which didn't obsolete my >>> designs.
>> Yes. I've been using PICs since the late 1980's.. just around the >> very month that Parallax entered the public fray. Nobody likes the >> bare-bones ALU design for the smaller-width instruction families -- >> it's design guts lay out on the floor, plain to see. But Microchip >> has maintained a very serious commitment to upgrade pathways over the >> entire time I've been involved (just after they decided to move beyond >> the "million unit rice cooker customer" days and place them into a >> broader marketplace. I couldn't have guessed then how strong that >> commitment would be. But they seem to well know what is important and >> they have clearly (to me) worked very hard to _earn_ the respect they >> have gained. And it's been so on almost every good business front.
>> One begins to realize after experiencing such a company's commitment >> to their customers, if that realization isn't already at hand, just >> how relatively unimportant an instruction set is to all these other >> business factors.
>>> Secondly Microchip always have product available. I recall one rep >>> trying to convert me to the ST6. Then he said ST are behind on >>> production and delivery was 4-6 months.
>> Well, Microchip has had their days with delays (the wait for the >> 18F252 from using the 18C252 comes to mind) but they have tended to be >> shorter than longer delays.
>>> There are better micros than the PIC from an engineering perspective >>> but they are hard to beat from a production view point.
>> In all the time I've used them, they have consistently maintained a >> solid professional use pathway that simply doesn't break. I have old >> tools that they no longer make (ProMate II) and yet they still support >> it without question or quibble. If I have so much as a flaky power >> switch they want me to send it in and fire off a replacement with >> shipping included for the "bad" one, so that I don't even miss a >> single second of use. Same for the modules that plug into it. Their >> tools are supported, decades it seems after they don't sell them >> anymore. That takes commitment on their part.
>> I find wringing of hands over the instruction set to be relatively >> badly placed. There are a lot more important things to focus on and >> on those areas Microchip has done a yeoman's service across the board.
>> Obviously, I use other manufacturers too. It's _very_ hard to find a >> 1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for >> example. But none of have compared quite as well on the business >> issues over the years.
>> Jon
>Also when looking for a long term investment in micros you may have to >consider the companies viability.
I will turn this question around on its head in a moment. Your point is made, but there is another view, too.
>Microchip are essentially the only micro manufacturer actually making monay >and doing quite well at present.
I place this at the feet of the quality of their business managers and their clear recognition of the right priorities in forging lasting business relationships. I am sure that there are excellent technical resources developing microcontroller products at all of the other businesses. Perhaps just as good as found at Microchip -- I simply can't compare them because I'm not informed about it. But I do know how they operate their business model. And I have been little other than impressed with it. So while I'm sure that poor technical quality would kill them (so I'm sure they do have good technical resources), so also would a poorly arranged set of priorities in their business design. And their competition, from my experience, do not come very close, sad to say. Almost to a company, though they differ in the reasons why I think they hang themselves on some point or another.
>All the others are losing money >hand-over-first and some are in a very bad state.
I would tend to imagine this would give them a clue. Standing on the outside as a consumer of these kinds of products, I have no question at all why Microchip is doing well. It's actually pretty easy to see why they are successful. They are committed to a mutual relationship in business and they actually _work_ at earning their respect, day in and day out. They just don't slip up on this.
If they do fail, it will only be because the entire field is in a nose dive. Not because they didn't get the business issues right.
>All the fanboys scream >Atmel, but they haven't made a cent since they started, and are probably the >most unstable in terms of long term viability.
I don't know much about Atmel. I developed one commercial product using their AT90S2312, I think. From start to finish, it took me 4 days to write it and the experience was excellent during the process because I never needed to actually call for any support from Atmel and the part worked well. Later, when considering an AT91 from Atmel's French arm, experiences turned significantly sour because I did have to involve them. And that's the last time I considered using Atmel for professional use -- I still like them for personal projects where I know in advance I'm not depending on them for anything serious.
I tend to imagine that it is Atmel's own fault for ordering it's business priorities wrongly. At least that's a consistent theory from my short experience with them. I would have NO problem specifying an Atmel part for some hobbyist project. But that's about where I draw the line. And just perhaps, others have also learned from experiences not unlike my own. Perhaps they are paying the piper, now. But I can't say. Might be for entirely different reasons.
> 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.
-- W . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^---------------------------------------------------------------
>>On Oct 30, 4:57 am, Al Borowski <al.borow...@gmail.com> wrote: >>> > Briefly, the Modified-Harvard architecture used in the PIC devices >>> > separates the program memory from the data memory, in other words >>> > separates the ROM/FLASH program memory from the RAM.
>>> [...]
>>> Yes, but there's more to to a uC core then choosing between Harvard or >>> Von Neumann. I think most of the PICs quirks come from the other >>> decisions made.
>>> The PIC (up to 16 bit cores anyway) is an accumulator architecture - >>> you have to funnel everything through the W register.
>>Going with accumulator model allowed Microchip to make the processor >>with fewer transistors. It is a trade off that can break either way. >>If you have a limit on the chip size you can make a higher performance >>processor that is harder to program.
>>[....] >>> in the 16 bit core thankfully). Personally, I think the most annoying >>> thing about programming PICs in assembly are the btfsc (test a bit in >>> 'file', skip the next instruction if it's clear) and btfss (same thing >>> but skip if set) instructions. Why they couldn't just call these ifbit >>> and ifnbit, I don't know :-)
>>Does ifbit mean skip if the bit is set or do the instruction if the >>bit is set?
>>> Back to the OP, great job Microchip on the video. It's a nice contrast >>> to TI, who recently sent misleading DMCA notices to people who tried >>> installing after-market OSs on their graphics calculators (http://news.cnet.com/8301-30685_3-10374284-264.html)
>>> Cheers,
>>> A;
>>I still prefer the 8051. It is way better. >>[ducks]
>So do I. The 8051 family was/is great.
>But I found the varients of 8051 I used were obsolete on more than one >occassion causing problems. I'm still sourcing SAB80C517 at silly >prices for example.
8051s, in several performance varieties (parallel one-clock to the original serial 12-clock ALU), are now available as FPGA soft cores. Obsolete chip? Just synthesize. Haven't quite figured out why I want to buy FPGA fabric to do an 8051, though. ;-)
>I first used the PIC for very low cost apps around 1990 and found that >there was always an upgrade path which didn't obsolete my designs.
>Secondly Microchip always have product available. I recall one rep >trying to convert me to the ST6. Then he said ST are behind on >production and delivery was 4-6 months.
>There are better micros than the PIC from an engineering perspective >but they are hard to beat from a production view point.
I don't see much use for the larger PICs. We're using a PIC-24 but it's more than overkill and just too weird.
On Oct 30, 2:09 pm, Jon Kirwan <j...@infinitefactors.org> wrote: [.. was PIC now 8051s ..]
> I'm using one from SiLabs, right now.
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.
> in perfect shape.) For this app, I needed a much faster floating > point ln(x) function (achieved under 18 microseconds) and found myself > spending some time coding assembly on it.
Do you really need true floating point? do you really need ln() or would log2() do? 18 microseconds seems a little slow.
Doing log2() of a 32 bit floater can be fairly quick if you don't care much about how much code space you use.
> No question in my mind that > this processor was designed with hand-coded assembly in mind, though. > Very easy to use efficiently for a human coder, though I do have to > check the book often to see if a particular instruction supports a > particular mode of access, yet just the kind of thing to seriously > complicate a compiler's life.
> >But I found the varients of 8051 I used were obsolete on more than one > >occassion causing problems. I'm still sourcing SAB80C517 at silly > >prices for example.
> I gather that Atmel has an AT89 line that includes an external bus and > so does SiLabs. Not sure how either of these would score on not > obsoleting designs, though.
> >I first used the PIC for very low cost apps around 1990 and found that > >there was always an upgrade path which didn't obsolete my designs.
> Yes. I've been using PICs since the late 1980's.. just around the > very month that Parallax entered the public fray. Nobody likes the > bare-bones ALU design for the smaller-width instruction families -- > it's design guts lay out on the floor, plain to see. But Microchip > has maintained a very serious commitment to upgrade pathways over the > entire time I've been involved (just after they decided to move beyond > the "million unit rice cooker customer" days and place them into a > broader marketplace. I couldn't have guessed then how strong that > commitment would be. But they seem to well know what is important and > they have clearly (to me) worked very hard to _earn_ the respect they > have gained. And it's been so on almost every good business front.
> One begins to realize after experiencing such a company's commitment > to their customers, if that realization isn't already at hand, just > how relatively unimportant an instruction set is to all these other > business factors.
> >Secondly Microchip always have product available. I recall one rep > >trying to convert me to the ST6. Then he said ST are behind on > >production and delivery was 4-6 months.
> Well, Microchip has had their days with delays (the wait for the > 18F252 from using the 18C252 comes to mind) but they have tended to be > shorter than longer delays.
> >There are better micros than the PIC from an engineering perspective > >but they are hard to beat from a production view point.
> In all the time I've used them, they have consistently maintained a > solid professional use pathway that simply doesn't break. I have old > tools that they no longer make (ProMate II) and yet they still support > it without question or quibble. If I have so much as a flaky power > switch they want me to send it in and fire off a replacement with > shipping included for the "bad" one, so that I don't even miss a > single second of use. Same for the modules that plug into it. Their > tools are supported, decades it seems after they don't sell them > anymore. That takes commitment on their part.
> I find wringing of hands over the instruction set to be relatively > badly placed. There are a lot more important things to focus on and > on those areas Microchip has done a yeoman's service across the board.
> Obviously, I use other manufacturers too. It's _very_ hard to find a > 1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for > example. But none of have compared quite as well on the business > issues over the years.
>> 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.
-- --------------------------------------------- Check out my Electronics Engineering Video Blog & Podcast: http://www.eevblog.com
On Fri, 30 Oct 2009 19:12:17 -0700 (PDT), MooseFET
<kensm...@rahul.net> wrote: >On Oct 30, 2:09 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >[.. was PIC now 8051s ..]
>> I'm using one from SiLabs, right now.
>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.
>> in perfect shape.) For this app, I needed a much faster floating >> point ln(x) function (achieved under 18 microseconds) and found myself >> spending some time coding assembly on it.
>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.
>> No question in my mind that >> this processor was designed with hand-coded assembly in mind, though. >> Very easy to use efficiently for a human coder, though I do have to >> check the book often to see if a particular instruction supports a >> particular mode of access, yet just the kind of thing to seriously >> complicate a compiler's life.
>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.
>> >But I found the varients of 8051 I used were obsolete on more than one >> >occassion causing problems. I'm still sourcing SAB80C517 at silly >> >prices for example.
>> I gather that Atmel has an AT89 line that includes an external bus and >> so does SiLabs. Not sure how either of these would score on not >> obsoleting designs, though.
>> >I first used the PIC for very low cost apps around 1990 and found that >> >there was always an upgrade path which didn't obsolete my designs.
>> Yes. I've been using PICs since the late 1980's.. just around the >> very month that Parallax entered the public fray. Nobody likes the >> bare-bones ALU design for the smaller-width instruction families -- >> it's design guts lay out on the floor, plain to see. But Microchip >> has maintained a very serious commitment to upgrade pathways over the >> entire time I've been involved (just after they decided to move beyond >> the "million unit rice cooker customer" days and place them into a >> broader marketplace. I couldn't have guessed then how strong that >> commitment would be. But they seem to well know what is important and >> they have clearly (to me) worked very hard to _earn_ the respect they >> have gained. And it's been so on almost every good business front.
>> One begins to realize after experiencing such a company's commitment >> to their customers, if that realization isn't already at hand, just >> how relatively unimportant an instruction set is to all these other >> business factors.
>> >Secondly Microchip always have product available. I recall one rep >> >trying to convert me to the ST6. Then he said ST are behind on >> >production and delivery was 4-6 months.
>> Well, Microchip has had their days with delays (the wait for the >> 18F252 from using the 18C252 comes to mind) but they have tended to be >> shorter than longer delays.
>> >There are better micros than the PIC from an engineering perspective >> >but they are hard to beat from a production view point.
>> In all the time I've used them, they have consistently maintained a >> solid professional use pathway that simply doesn't break. I have old >> tools that they no longer make (ProMate II) and yet they still support >> it without question or quibble. If I have so much as a flaky power >> switch they want me to send it in and fire off a replacement with >> shipping included for the "bad" one, so that I don't even miss a >> single second of use. Same for the modules that plug into it. Their >> tools are supported, decades it seems after they don't sell them >> anymore. That takes commitment on their part.
>> I find wringing of hands over the instruction set to be relatively >> badly placed. There are a lot more important things to focus on and >> on those areas Microchip has done a yeoman's service across the board.
>> Obviously, I use other manufacturers too. It's _very_ hard to find a >> 1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for >> example. But none of have compared quite as well on the business >> issues over the years.
David L. Jones wrote: > 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:
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.
>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.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
> 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
Put a break point either side of the routine and look at the contents of the PCA counter in both places.
<kensm...@rahul.net> wrote: >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >> 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
>Put a break point either side of the routine and look at the contents >of the PCA counter in both places.
I see. I hadn't earlier been interested in setting up the PCA for such use and was hoping that the debug/jtag unit itself maintained a SYSCLK count I could display without involving software I write explicitly for the purpose (which, of course, I can do.) From the above response, I take it the answer is 'no.' Accepted.
> "Swanny" wrote: > > Briefly, the Modified-Harvard architecture used in the PIC devices > > separates the program memory from the data memory, in other words > > separates the ROM/FLASH program memory from the RAM. In the case of the > > PIC, the program memory bus width is larger than the data memory bus > > width, allowing transfer of the complete instruction op code in fewer > > cycles (many instructions take only 1 cycle).
> Just like with AVR, practically everything 1 cycle except branches.
> M
But don't the 10xx, 12xx, and 16xx PICs take 4 clocks per instruction cycle? AVRs only take 1 clock per instruction (with the usual exceptions).
> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
> <kensm...@rahul.net> wrote: > >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: > >> 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
> >Put a break point either side of the routine and look at the contents > >of the PCA counter in both places.
> I see. I hadn't earlier been interested in setting up the PCA for > such use and was hoping that the debug/jtag unit itself maintained a > SYSCLK count I could display without involving software I write > explicitly for the purpose (which, of course, I can do.) From the > above response, I take it the answer is 'no.' Accepted.
> Thanks for taking a moment on this for me, > Jon
The JTAG section appears to not know anything about what the clock speed is other than requiring more than 32KHz to work.
<kensm...@rahul.net> wrote: >On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>> <kensm...@rahul.net> wrote: >> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >> >> 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
>> >Put a break point either side of the routine and look at the contents >> >of the PCA counter in both places.
>> I see. I hadn't earlier been interested in setting up the PCA for >> such use and was hoping that the debug/jtag unit itself maintained a >> SYSCLK count I could display without involving software I write >> explicitly for the purpose (which, of course, I can do.) From the >> above response, I take it the answer is 'no.' Accepted.
>> Thanks for taking a moment on this for me, >> Jon
>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.
Nico Coesel wrote: > "David L. Jones" <altz...@gmail.com> wrote:
>> 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.
This is the kind of gotcha you need to know about in advance when deciding what architecture to use.
> 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.
> 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.
> -- > --------------------------------------------- > Check out my Electronics Engineering Video Blog & Podcast: > http://www.eevblog.com
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.
-- www.oho-elektronik.de OHO-Elektronik Michael Randelzhofer FPGA und CPLD Mini Module Klein aber oho ! Kontakt: Tel: 08131 339230 m...@oho-elektronik.de Usst.ID: DE130097310
> On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
> <kensm...@rahul.net> wrote: > >On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: > >> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
> >> <kensm...@rahul.net> wrote: > >> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: > >> >> 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
> >> >Put a break point either side of the routine and look at the contents > >> >of the PCA counter in both places.
> >> I see. I hadn't earlier been interested in setting up the PCA for > >> such use and was hoping that the debug/jtag unit itself maintained a > >> SYSCLK count I could display without involving software I write > >> explicitly for the purpose (which, of course, I can do.) From the > >> above response, I take it the answer is 'no.' Accepted.
> >> Thanks for taking a moment on this for me, > >> Jon
> >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.
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.
<kensm...@rahul.net> wrote: >On Oct 31, 2:41 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
>> <kensm...@rahul.net> wrote: >> >On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >> >> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>> >> <kensm...@rahul.net> wrote: >> >> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >> >> >> 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
>> >> >Put a break point either side of the routine and look at the contents >> >> >of the PCA counter in both places.
>> >> I see. I hadn't earlier been interested in setting up the PCA for >> >> such use and was hoping that the debug/jtag unit itself maintained a >> >> SYSCLK count I could display without involving software I write >> >> explicitly for the purpose (which, of course, I can do.) From the >> >> above response, I take it the answer is 'no.' Accepted.
>> >> Thanks for taking a moment on this for me, >> >> Jon
>> >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.
>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.
David L. Jones wrote: > Bob Larter wrote: >> David L. Jones wrote: >>> They have even posted this hillarious video response in record time: >>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>> 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.
-- W . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^---------------------------------------------------------------
>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>> <kensm...@rahul.net> wrote: >>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>> >> 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
>>> >Put a break point either side of the routine and look at the contents >>> >of the PCA counter in both places.
>>> I see. I hadn't earlier been interested in setting up the PCA for >>> such use and was hoping that the debug/jtag unit itself maintained a >>> SYSCLK count I could display without involving software I write >>> explicitly for the purpose (which, of course, I can do.) From the >>> above response, I take it the answer is 'no.' Accepted.
>>> Thanks for taking a moment on this for me, >>> Jon
>>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
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.
>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>> <kensm...@rahul.net> wrote: >>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>> >> 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
>>>> >Put a break point either side of the routine and look at the contents >>>> >of the PCA counter in both places.
>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>> such use and was hoping that the debug/jtag unit itself maintained a >>>> SYSCLK count I could display without involving software I write >>>> explicitly for the purpose (which, of course, I can do.) From the >>>> above response, I take it the answer is 'no.' Accepted.
>>>> Thanks for taking a moment on this for me, >>>> Jon
>>>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
>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.
>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>> <kensm...@rahul.net> wrote: >>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>> >> 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
>>>>> >Put a break point either side of the routine and look at the contents >>>>> >of the PCA counter in both places.
>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>> SYSCLK count I could display without involving software I write >>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>> above response, I take it the answer is 'no.' Accepted.
>>>>> Thanks for taking a moment on this for me, >>>>> Jon
>>>>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
>>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
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).
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>> <kensm...@rahul.net> wrote: >>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>> >> 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
>>>>>> >Put a break point either side of the routine and look at the contents >>>>>> >of the PCA counter in both places.
>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>> SYSCLK count I could display without involving software I write >>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>> Thanks for taking a moment on this for me, >>>>>> Jon
>>>>>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
>>>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
>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.
>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>> <kensm...@rahul.net> wrote: >>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>> >> 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
>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>> >of the PCA counter in both places.
>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>> SYSCLK count I could display without involving software I write >>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>> Thanks for taking a moment on this for me, >>>>>>> Jon
>>>>>>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
>>>>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
>>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.
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.
>>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.
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.
>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>> >> 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
>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>> >of the PCA counter in both places.
>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>> Jon
>>>>>>>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
>>>>>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
>>>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.
>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.
>>>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.
>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.)
|
