Author Topic: EEVblog #240 - Power Supply Design Part 8  (Read 12187 times)

0 Members and 1 Guest are viewing this topic.

alm

  • Guest
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #15 on: January 30, 2012, 06:18:24 AM »
Code: [Select]
    i = 0;
for_begin:
    if( !( i < 8) )
        goto for_exit;
    output( i );
    ++i
    goto for_begin;
for_end:

Real assembly from avr-gcc is more something like this:
Code: [Select]
    i = 8;
for_begin:
    do_something();
    if (--i) goto for_begin;
The if and goto represent two assembly instructions; two or three cycles.

d1) If you have a working branch predictor then this may take one or two cycles. If you have a pre-fetch buffer or cache then the jump may or may not require a new set of fetch cycles.
How many 8-bit micros have a brench predictor or pre-fetch buffer? The SRAM is simply running at the same speed as the ALU, so no need for caching or complicated pipelines. This means that jumps are quite cheap. On CPU's with long pipelines and complex caching strategies, it may get even more complicated, because unrolling a loop may prevent your code from fitting in the instruction cache, which can carry a huge performance hit.

A simple for loop may be 5 or 10 times slower than the equivalent linear code. Indeed a standard compiler optimisation is to un-roll the loop to produce linear code... which in itself may make things better or worse.
In the worst case with a single cycle output instruction it would be three to four times slower in my example. In many cases (like in the Arduino library) it's likely to take longer (you may have to toggle a clock line for example), so the relative overhead is reduced even further.

It is unwise to make a blanket call without considering the underlying cpu architecture + cache + predicters.
Exactly. This is why it's usually unwise to second-guess the compiler unless you've done the research (eg. looked at the disassembly listing) or are an expert at that particular MCU architecture.

Offline desowin

  • Contributor
  • Posts: 19
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #16 on: January 30, 2012, 06:35:48 AM »
As others already mentioned using loop there could be nice, I'll throw in my two cents about the unnecessary assignment. I believe the temp = value; before sending each data bit is redundant. The value of temp is not going to change in the meantime (and even if value changes in some interrupt, it's bad idea to use part of old and part of new value).
« Last Edit: January 30, 2012, 06:43:56 AM by desowin »

Offline remoteledger

  • Newbie
  • Posts: 2
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #17 on: January 30, 2012, 06:56:25 AM »
Just sharing my experience with SPI. This is common to misconfigure data capture mode. Microcontroller allows you to set data capture on raising clock or on falling clock. So if controller thinks that receiver will accept data on falling clock and actual receiving device accept it on raising clock, then you'll get nasty data corruption it the best or no communication at worse.

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 206
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #18 on: January 30, 2012, 07:30:53 AM »
As a consequence I have long given up on trying to second-guess what a compiler does. Especially I refrain from trying to "help" the compiler when coding. Help only gets in the way of the compiler's optimizer. The only exception is when a particular piece of code turns out to be too slow or too large. When I have hard measurements showing this, not just a gut feeling. Then, and only if it matters, I try to trick the compiler into doing better. It happens fewer and fewer over the years.

Nicely said. Unless you really need the compiler to output some specific code, just do what is easiest, most readable etc. When you need some optimization, you can suggest it using compiler flags or keywords like inline (not sure about AVRs, but from I've read about modern x86/x86_64 compilers, they just ignore the inline altogether and decide themselves if it's a good optimization or not).

And of course, if you really, really need to micromanage the code, throw in a block of assembly. But that should be the last resort.

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 206
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #19 on: January 30, 2012, 07:42:16 AM »
As others already mentioned using loop there could be nice, I'll throw in my two cents about the unnecessary assignment. I believe the temp = value; before sending each data bit is redundant. The value of temp is not going to change in the meantime (and even if value changes in some interrupt, it's bad idea to use part of old and part of new value).

Except the first temp = value; line, all others are redundant. (temp>>x) will just return the value and leave temp unchanged. As for the first one, I think it wasn't visible in the video where that came from, but I suppose it's a parameter to that function. In that case the temp variable is completely redundant.

Dave: maybe you could publish the code somewhere (either just on the website; or preferably, in the long run, on some VCS hosting like github, bitbucket, google code etc). Software is something that can be easily collaborated over net, and people could start making improvements, bug fixes and adding features already.

The good thing about for example github is that you get a visible list of all forks made by participants, and they can also send you pull requests. You can review each one and decide whether to incorporate it into your "official" repository (eg. bugfix), or not (eg. some personal preference about display style, features, ...).

Of course, like everyone had their own vision of the schematic/pcb, this will probably end with a lot of people arguing over it. So maybe just put it on the site for now.

Offline TerminalJack505

  • Frequent Contributor
  • **
  • Posts: 997
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #20 on: January 30, 2012, 07:59:47 AM »
I don't think it's worth the time or trouble to get worked-up about Dave's code at this point.  If I were to guess I would say he simply hacked something together just to test the board. 

The code you saw in the video will likely change significantly by the time all is said and done.

Offline IanB

  • Super Contributor
  • ***
  • Posts: 4673
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #21 on: January 30, 2012, 09:00:16 AM »
The last thing to do is open up a discussion over code. People will get into deep discussions and nit pick over the tiniest things, as has happened in this thread. If you think that happens over hardware designs, just wait and see how much worse it is over software. Every man and his dog is a software expert...  ;D
I'm not an EE--what am I doing here?

Online EEVblog

  • Administrator
  • *****
  • Posts: 11507
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #22 on: January 30, 2012, 09:18:41 AM »
Dave: maybe you could publish the code somewhere (either just on the website; or preferably, in the long run, on some VCS hosting like github, bitbucket, google code etc). Software is something that can be easily collaborated over net, and people could start making improvements, bug fixes and adding features already.

No. This is a dictatorship, I'll code the way I like, no one else gets any say in it until it's released  :P

Dave.

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 1288
  • Country: gr
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #23 on: January 30, 2012, 09:31:13 AM »
Dave, when you started the video the light was quite bright (I like it). At some time it dimmed. Do you use a spotlight and turned it off for the laptop's screen capturing?

Alexander.
Become a realist, stay a dreamer.


Online EEVblog

  • Administrator
  • *****
  • Posts: 11507
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #24 on: January 30, 2012, 09:33:54 AM »
The last thing to do is open up a discussion over code. People will get into deep discussions and nit pick over the tiniest things, as has happened in this thread. If you think that happens over hardware designs, just wait and see how much worse it is over software. Every man and his dog is a software expert...  ;D

Yup, order of magnitude worse than hardware...
I wonder if anyone if foolish enough to do a software coding video blog?

Dave.

Offline Zad

  • Frequent Contributor
  • **
  • Posts: 872
  • Country: gb
    • Digital Wizardry, Analogue Alchemy, Software Sorcery
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #25 on: January 30, 2012, 09:36:03 AM »
I utterly HATE software religion wars. One simple SPI routine has turned into a war of optimisation, readability, what optimisation "really" means, what compiler is "best" and cock waving comparisons. This is why I prefer to stick with hardware.

Move on guys. If it works, it works. If you want to rewrite it to please your particular software God, then feel free but don't drag everyone else into it. Linux only got anywhere because one person was in charge.


Online EEVblog

  • Administrator
  • *****
  • Posts: 11507
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #26 on: January 30, 2012, 09:37:25 AM »
Dave, when you started the video the light was quite bright (I like it). At some time it dimmed. Do you use a spotlight and turned it off for the laptop's screen capturing?

The light in the new lab is crap and highly variable depending upon the angle. Usually I let the auto exposure setting on the camera pick and then change to manual mode to fix that setting, but sometime I tweak it by hand if it looks too dull on the playback screen.
An yes, I have some small spotlight on arms too that I move around.

Dave.

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3501
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #27 on: January 30, 2012, 09:45:16 AM »
I utterly HATE software religion wars. One simple SPI routine has turned into a war of optimisation, readability, what optimisation "really" means, what compiler is "best" and cock waving comparisons.

You haven't read the postings you are commenting on, have you?
I delete PMs unread. If you have something to say, say it in public.
For all else: Profile->[Modify Profile]Buddies/Ignore List->Edit Ignore List

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 206
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #28 on: January 30, 2012, 10:14:12 AM »
No. This is a dictatorship, I'll code the way I like, no one else gets any say in it until it's released  :P

Yeah as I said in the last paragraph, it'll get much worse than the HW talks. You can of course ignore the suggestions, but as TerminalJack505 said, there probably isn't much to talk about for now.

I utterly HATE software religion wars. One simple SPI routine has turned into a war of optimisation, readability, what optimisation "really" means, what compiler is "best" and cock waving comparisons.

You haven't read the postings you are commenting on, have you?
Probably not. I think we generally agreed about the best (well, at least better) way to do it. Not that it matters for a prototype, as long as it works.

Offline naimis

  • Contributor
  • Posts: 38
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #29 on: January 30, 2012, 10:38:19 AM »
I wonder if anyone if foolish enough to do a software coding video blog?

Dave.
As a "software guy", I'd have to really put some thought into finding a subject I'd consider less interesting for a video blog  ::)


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf