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

0 Members and 2 Guests are viewing this topic.

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 210
  • Country: sk
EEVblog #240 - Power Supply Design Part 8
« on: January 29, 2012, 02:21:08 pm »
Interesting episode, two things:

The DAC datasheet says it has resolution of 12bits, with max/min error of +-12bits. So that basically means it can output whatever value it wants, and stay in spec. What am I missing here?

Second thing - the code is probably in very early stage right now etc, but really? Copy pasting the output of data bits to the DAC instead of a for loop? :)
 

Offline ecat

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #1 on: January 29, 2012, 02:45:58 pm »
Another great episode, many thanks Dave.

It may not be important but the video shows you missing one more SPI_CLK typo, see @11:12 and later near the video end. The first line of a function is always the trickiest, and the last line, that's the trickiest too. Come to think of it... Anyway...

digitalWrite( SPI_CLK, LOW)

I guess this should be SPI_SCLK, as it is your DAC is missing 1/2 of the first clock cycle ?

 

Offline chrome

  • Regular Contributor
  • *
  • Posts: 189
  • Country: be
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #2 on: January 29, 2012, 02:46:46 pm »
I think the 12LSb means if you output "100" it can be from 88->112

Also I agree on the for loop, that's just bad practice.
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #3 on: January 29, 2012, 03:01:33 pm »
Second thing - the code is probably in very early stage right now etc, but really? Copy pasting the output of data bits to the DAC instead of a for loop? :)

for bit banging loops are timing killer, such spaghetti code is easier to debug.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 1991
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #4 on: January 29, 2012, 03:02:45 pm »
The integral non-linearity is 12 LSBs. This means not the 12 least significant bits, but a voltage equal to 12 times the least significant bit.  This is still pretty terrible compared to more intrinsically linear DAC archetectures, but the typical value is only 2 LSB, and even 12 LSBs is only +/- 0.2% of full scale.  INL would be a bigger concern for AC applications where it leads to harmonic generation and inter-modulation distortion -- for a DC application like this it is "only" a concern for the overall accuracy, and if you were really concerned you could calibrate it out.
 

Offline thilo

  • Regular Contributor
  • *
  • Posts: 51
AW: Re: EEVblog #240 - Power Supply Design Part 8
« Reply #5 on: January 29, 2012, 03:19:31 pm »
Second thing - the code is probably in very early stage right now etc, but really? Copy pasting the output of data bits to the DAC instead of a for loop? :)

for bit banging loops are timing killer, such spaghetti code is easier to debug.
That would contradict the definition of spaghetti code.
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1905
  • Country: 00
    • If you like my hacks, send me a donation
Re: AW: Re: EEVblog #240 - Power Supply Design Part 8
« Reply #6 on: January 29, 2012, 03:26:53 pm »
Second thing - the code is probably in very early stage right now etc, but really? Copy pasting the output of data bits to the DAC instead of a for loop? :)

for bit banging loops are timing killer, such spaghetti code is easier to debug.
That would contradict the definition of spaghetti code.

no, you just misunderstood me. With "such" i refer to Daves code and not to loop.
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #7 on: January 29, 2012, 04:15:04 pm »
The integral non-linearity is 12 LSBs. This means not the 12 least significant bits, but a voltage equal to 12 times the least significant bit. 
Oh, that makes much more sense. Thanks :)

for bit banging loops are timing killer, such spaghetti code is easier to debug.
I don't think so. The loop is just an increment and a simple comparison with a jump. That should be two instructions on pretty much every architecture, and that will be small compared to the contents of the loop. Also, I would say this makes debugging actively harder, because it's easy to make a change and miss some block while replicating it, or something like that.
 

Offline baljemmett

  • Supporter
  • ****
  • Posts: 666
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #8 on: January 29, 2012, 04:31:30 pm »
for bit banging loops are timing killer, such spaghetti code is easier to debug.
I don't think so. The loop is just an increment and a simple comparison with a jump. That should be two instructions on pretty much every architecture, and that will be small compared to the contents of the loop.

Any halfway-decent compiler should be thinking about unrolling that sort of loop anyway as an optimisation, if it decides it has the code space to do so and the compilation settings allow such optimisations...  (NB: I haven't yet seen the latest video but from the comments I guess this is a reasonably small loop to shift bits out on a serial bus!)
 

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #9 on: January 29, 2012, 04:44:17 pm »
Any halfway-decent compiler should be thinking about unrolling that sort of loop anyway as an optimisation, if it decides it has the code space to do so and the compilation settings allow such optimisations...  (NB: I haven't yet seen the latest video but from the comments I guess this is a reasonably small loop to shift bits out on a serial bus!)
Of course, but this depends on many many variables. But even if it doesn't unroll it shouldn't hurt.

And yes, it's 8x data shift+mask, write to output and toggle clock. Wouldn't surprise me if it unrolled.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #10 on: January 29, 2012, 04:47:36 pm »
Any halfway-decent compiler should be thinking about unrolling that sort of loop anyway as an optimisation, if it decides it has the code space to do so and the compilation settings allow such optimisations...

Typically one optimizes for space on such small micro controllers. However, since there is an AVR GCC behind it, you have more than enough flags to fiddle with to change optimization.
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 ecat

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #11 on: January 29, 2012, 05:20:05 pm »
For loops are an essential tool in a programmers kitbag but they are not a panacea. In something that could be a time critical I/O routine they should be viewed in a critical light, or at the very least understood in relation to the compiler and underlying architecture.

Simple example:

Code: [Select]
    for( i = 0; i < 8; ++i )
         output( i );

The compiler will generate something similar to the following pseudo code...

Code: [Select]
    i = 0;
for_begin:
    if( !( i < 8) )
        goto for_exit;
    output( i );
    ++i
    goto for_begin;
for_end:

Let's assume output() is defined as a macro which executes in a single instruction cycle typical of a micro controllers I/O instructions.

if( !( i < 8 ) )
a1) If i is declared as a register variable or the compiler decides to make i a register variable then this comparison will probably execute in a single instruction cycle.
a2) If i is declared as volatile or the compiler decides not to make i a register variable then this comparison will probably execute in 2 instruction cycles plus one data fetch cycle.

Our single cycle output instruction is now taking two, three or more cycles to complete. Further, if the programmer is not careful the actual time is dependent upon the whims of the compiler writer and a combination of, often obscure, optimisation settings.

output( i );
One instruction cycle.

++i
c1) If i is declared as a register variable or the compiler decides to make i a register variable then this increment will probably execute in a single instruction cycle.
c2) If i is declared as volatile or the compiler decides not to make i a register variable then this increment will probably execute in 1 instruction cycle plus one data fetch cycle plus one data write cycle.

Our single cycle output instruction is now taking another additional instruction cycle plus possibly 2 memory access delays.

goto for_begin;
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.
d2) Without hardware assist as in d1) and depending on the underlying architecture a jump may require, say, 10 instruction cycles to execute.

Our single cycle output instruction is now taking another additional two to ten instruction cycles plus possibly n memory access delays.

The important things to understand are:
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.

Changing the variable qualifier, register/volatile, or having the compiler change it for you on the fly can have a significant impact on time critical code. 

It is unwise to make a blanket call without considering the underlying cpu architecture + cache + predicters.

Compilers + optimisation can and will screw you over in some of the most inventive and unforeseen ways imaginable.

If you are at all in doubt: KISS. You can usually find at least some time to optimise and beautify code once it's working, bosses love working code.
« Last Edit: January 29, 2012, 05:23:43 pm by ecat »
 

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #12 on: January 29, 2012, 06:28:08 pm »
The important things to understand are:
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 case the inner code is just a single cycle. Which it often is not. The loop support code is basically constant in size and execution time. So with any non-trivial loop contents it becomes irrelevant. In case of a single instruction loop I would expect the compiler to unroll it anyway, and I probably wouldn't care. Because...

If you are at all in doubt: KISS. You can usually find at least some time to optimise and beautify code once it's working, bosses love working code.
That's exactly right. I would write the loop. It's simple, readable and maintainable. In case it is too slow and doesn't work, then I would unroll it by hand. "Premature optimization is the root of all evil", as the mantra goes.

Also, if you really want to have it unrolled... at least define a macro/inline function for it, more readable and can be easily changed around.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #13 on: January 29, 2012, 06:32:28 pm »
The compiler will generate something similar to the following pseudo code...

No, it might or might not. Modern compilers are rather unpredictable in what they produce when they are really pushing optimization hard, and the good ones do push optimization hard.

Decades ago it was different. Back then C compilers promised much but couldn't deliver much optimization. These days however, I often shit my pants when studying optimized C compiler output. On a good day a good C compiler approaches hand written assembler quality in some parts. On a bad day they still mess things up.

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.

BTW, One error you have in your analysis is thinking output() is a single instruction cycle. In the current case (Arduino code) it is a call to a rather messed up function in the Arduino library. That alone can lead a compiler's optimizer to completely different conclusions.

BTW2: If you want to really unroll something, tell the compiler to do it. Usually the compiler makes less errors than the user, e.g. not missing two loop cycles :-)
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 baljemmett

  • Supporter
  • ****
  • Posts: 666
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #14 on: January 29, 2012, 06:51:13 pm »
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.

Yes indeed; describe what you're trying to do in your code, and let the compiler worry about the best way to turn it into an instruction stream.  It'll usually get it right, and when you can prove it doesn't there'll be a way to give it a prod in the right direction.  See also Knuth's famed line, "premature optimisation is the root of all evil".

(Which reminds me, I have a section of code that I thought was quite straightforward but the Hi-Tech compiler suggests might make a nice addition to their validation suite.  That was quite a surprise; must send it off and see what they make of it.)
 

alm

  • Guest
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #15 on: January 29, 2012, 07:18:24 pm »
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: 21
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #16 on: January 29, 2012, 07:35:48 pm »
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 29, 2012, 07:43:56 pm by desowin »
 

Offline remoteledger

  • Newbie
  • Posts: 2
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #17 on: January 29, 2012, 07:56:25 pm »
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: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #18 on: January 29, 2012, 08:30:53 pm »
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: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #19 on: January 29, 2012, 08:42:16 pm »
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

  • Super Contributor
  • ***
  • Posts: 1205
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #20 on: January 29, 2012, 08:59:47 pm »
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: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #21 on: January 29, 2012, 10:00:16 pm »
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: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #22 on: January 29, 2012, 10:18:41 pm »
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: 2330
  • Country: gr
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #23 on: January 29, 2012, 10:31:13 pm »
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: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #24 on: January 29, 2012, 10:33:54 pm »
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

  • Super Contributor
  • ***
  • Posts: 1013
  • Country: gb
    • Digital Wizardry, Analogue Alchemy, Software Sorcery
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #25 on: January 29, 2012, 10:36:03 pm »
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: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #26 on: January 29, 2012, 10:37:25 pm »
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: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #27 on: January 29, 2012, 10:45:16 pm »
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: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #28 on: January 29, 2012, 11:14:12 pm »
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: 41
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #29 on: January 29, 2012, 11:38:19 pm »
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  ::)
 

alm

  • Guest
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #30 on: January 30, 2012, 12:06:44 am »
Yup, order of magnitude worse than hardware...
I wonder if anyone if foolish enough to do a software coding video blog?
Probably, though I haven't bothered to look. Screencasts about software development seemed fairly popular a few years ago. Software doesn't lend itself as much to the video blog format, though. Seeing someone typing gets boring really fast, and the added value of seeing someone type it compared to just the code plus a description is quite limited. There are plenty of regular blogs though.

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.
I'd have to agree with BaW and wonder whether you've actually read this thread.

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.
Yes, lets get back to the regular scheduled arguments about which micro is the best, which one Dave should use for his own projects and which brand of test equipment is the best. Not to forget comparing DMM sizes. ;)
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #31 on: January 30, 2012, 01:05:03 am »
I'd have to agree with BaW and wonder whether you've actually read this thread.

What else is the, "Ooh, you did it wrong, you should have used a loop!" argument all about?  ::)

Dave's a big boy now, he's been around the block a few times, it's not like he's never heard of for loops. If he wants to do it that way it's his business.

One reason software blogs in the net are so unproductive is because people perpetually get bogged down over the same questions that have been done to death a thousand times before. Such pointless time wasting is a sign of bad engineering. If it is readable, easy to edit, does the right thing in all cases, runs fast enough and fits in the available memory then it's good code. Look how easy it was for Dave to shift the two null bits from the end to the beginning. In hardware, shaving the component count might save you some costs in production; removing a couple of lines in software, not so much.
I'm not an EE--what am I doing here?
 

alm

  • Guest
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #32 on: January 30, 2012, 01:30:00 am »
What else is the, "Ooh, you did it wrong, you should have used a loop!" argument all about?  ::)
You consider this a religious war?

One reason software blogs in the net are so unproductive is because people perpetually get bogged down over the same questions that have been done to death a thousand times before.
Citation needed. I come across plenty of software blogs when searching for stuff, and they rarely seem unproductive to me. Joel Spolsky's blog is the most recent one that comes to mind. Sure, there's plenty of repetition, but it's not like there aren't a thousand blogs discussing how to connect a LED to an Arduino.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #33 on: January 30, 2012, 02:01:29 am »
Citation needed.

I really meant the comments/discussion part. There are certainly people out there with interesting things to blog about on software development (even if Joel Spolsky ran out of fresh material a long time ago).
I'm not an EE--what am I doing here?
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #34 on: January 30, 2012, 02:23:15 am »
Look how easy it was for Dave to shift the two null bits from the end to the beginning.

Bingo.
When writing something like this bit-bang routine, the last thing I give a damn about is wanting to optimise things for code space in a for loop.
With in-line rolled-out code like I did, when it doesn't work, I can simply hack individual bits very easily for troubleshooting purposes without dicking around with stupid loops.
There is method to my madness.

Dave.
 

Offline PeteInTexas

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #35 on: January 30, 2012, 04:04:17 am »
How did I know the SMOP monster was going to rear its ugly head when those chips starting populating the board   ::)
 

Offline PeteInTexas

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #36 on: January 30, 2012, 04:08:57 am »
Citation needed.

I really meant the comments/discussion part. There are certainly people out there with interesting things to blog about on software development (even if Joel Spolsky ran out of fresh material a long time ago).

Except for the straight forward "how-tos" and tutorial, software blogs tend to be a rant of one level or another.  It gets old fast.
 

Offline Lightages

  • Supporter
  • ****
  • Posts: 4295
  • Country: ca
  • Canadian po
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #37 on: January 30, 2012, 06:57:59 am »
Dave:

In the last coupe of videos, not only did the brightness change, but so did the colour balance. To my eye it is very jolting but you already know I am a video producer and camera man. Perhaps you might want to set the colour balance to a fixed value instead of auto, if you haven't already.

Secondly, the power supply looks to be a nice small package with many benefits. I just might buy one!
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #38 on: January 30, 2012, 07:23:14 am »
to try and break away from the software discussion,

i assume you havent had time to start with the adc yet, as you said it was the companion one, i now fear that even 10 bit accuracy may have been thrown out of the window :/

also, is there any tricks to trimming in a voltage reference?

and to finish on a good note, good video as always dave, shows the use of a DSO with a one shot trigger
 

Offline darrenb

  • Contributor
  • Posts: 34
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #39 on: January 30, 2012, 10:33:32 am »
I can't understand why Dave moved the zero bits from the end of the bit banging sequence to the front?

From the look of the data sheet it appeared the bits at the end (least significant bits, the right hand end) were the ones that didn't matter?  So they appeared to be correctly being sent at the end initially.

 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1042
  • Country: nl
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #40 on: January 30, 2012, 11:06:32 am »
Let's talk over more pressing matters, software is like.. it works as is, and quick enough? Good, moving on.

I wonder if the analog parts of MicroChip aren't inherently 'bad'.  As you mentoined, ADC's and DAC's in micro's are not as good as an external one. I don't know on what design they are making the external converters, but if it's the same as the micro's, you're still back to where we were.

They also make like 22-bit ADC's with a claim of 18+ ENOB. I have no idea whether they will meet this specification. I have some of these lying around (MCP3551), but I really wonder whether these are spot on as well. Maybe they have a terrible offset of +100 counts if both inputs tied to GND hard.. not sure.

I'd resort to another manufacturer, probably, for analog parts from seeing this. Well, they meet their specifications, but +/- 12 LSB is quite horrible (0.3% right there). Am I right in saying that the worst case situation, the output voltages could be off by 2-3% (voltage reference +/- 0.25%, FSR output +/-1%, linearity +/-0.3%, unwanted offsets)? Kinda a pity of all the precision resistors and current sense amplifiers, etc. I would probably pick a more precise DAC from AD or TI.

Ah well, the given resolution was way better than required anyway :) Furthermore, if you really want a 'DC accurate' measurement, I think calibration is inevitable. A better resolution is ofcourse nicer because you can more precisely vary steps (only for that reason I'd smack in a overkill ADC or DAC for my hobby power supply which is probably a one or twice off).
« Last Edit: January 30, 2012, 11:25:07 am by hans »
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #41 on: January 30, 2012, 11:21:41 am »
I can't understand why Dave moved the zero bits from the end of the bit banging sequence to the front?

From the formula in the datasheet, the output voltage would have been too high. I wanted 1mV/mA output.

Dave.
 

Offline darrenb

  • Contributor
  • Posts: 34
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #42 on: January 30, 2012, 11:49:15 am »
I can't understand why Dave moved the zero bits from the end of the bit banging sequence to the front?

From the formula in the datasheet, the output voltage would have been too high. I wanted 1mV/mA output.

Dave.

Hi Dave,

But you're throwing away bits aren't you.  Lets say for 10 bits of data being sent to the ADC the data sheet says to send it 16 bits, the first four bits being the configuration bits, the next 10 being the data bits and the last two being thrown away.

Using 'C' for config bits, 'D' for data you want to send and 'X' for stuff it will throw away I think it said to send as;
CCCCDDDD DDDDDDXX.

But after the programming change it's now being sent as;
CCCCXXDD DDDDDDXX where you're throwing away the two bits at the front and the ADC is throwing away the two bits at the end.

I haven't done the math to figure out what the consequences of this would be but it doesn't seem right.  Maybe this will fix the error you were seeing?  Or maybe I'm missing something (happens all the time).

 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #43 on: January 30, 2012, 12:19:38 pm »
The error I am seeing has nothing to do with this.
I want and need 1mV/bit output, because that is what matches my current sense amp output. And to get that with the 2.048V reference and 12 bits I need to use the lower 10 bits with the x2 amp.

Dave.
 

Offline darrenb

  • Contributor
  • Posts: 34
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #44 on: January 30, 2012, 12:55:40 pm »
The error I am seeing has nothing to do with this.
I want and need 1mV/bit output, because that is what matches my current sense amp output. And to get that with the 2.048V reference and 12 bits I need to use the lower 10 bits with the x2 amp.

Dave.

Gudday again Dave,

Yes you're right - forget the error it's probably not related and it's most likely not even an error in the first place.

But..  Are you sure you're not just sending 8 bits to the ADC.  The ADC wants two bytes or 16 bits.  The first four bits are config bits so you're left with twelve.  You're sending two zeros (discard bits) at the front and then 10 bits of data but the last two are being dropped by the ADC.  12 - 2 (at the front) - 2 (at the end) = 8 bits of significant data being sent.

Based on the blog at 20:03 maybe the discard bits should be back at the end after the data bits instead of in front?

 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #45 on: January 30, 2012, 03:37:53 pm »
I think I would do the experiment implied by darrenb's question: successively increment the lsb of the data word you are sending and see what the delta of the output voltage is each time you increase it by 1. Are you getting the output precision you expect to be getting?

With a 2048 mV reference voltage and 10 bit resolution (= 1 part in 1024) I think you would expect the DAC output to increase by 2 mV with each step of the input word. If something is wrong the output would change in larger steps with every 2 or 4 increments rather than one small step per increment.
I'm not an EE--what am I doing here?
 

Offline jaapiyo

  • Newbie
  • Posts: 1
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #46 on: January 30, 2012, 03:54:15 pm »
I don't know if anyone pointed this already, but I think it would be nice if Dave made diffident kits for different mains power specifications. (Like EU, US etc.)
 

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 833
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #47 on: January 30, 2012, 04:12:44 pm »
But..  Are you sure you're not just sending 8 bits to the ADC.  The ADC wants two bytes or 16 bits.  The first four bits are config bits so you're left with twelve.  You're sending two zeros (discard bits) at the front and then 10 bits of data but the last two are being dropped by the ADC.  12 - 2 (at the front) - 2 (at the end) = 8 bits of significant data being sent.

Based on the blog at 20:03 maybe the discard bits should be back at the end after the data bits instead of in front?

Dave is using a 12-bit DAC shifted out MSB first for the test; of the 12 bits, only the lower 10 bits are used. I don't know where you're getting the "- 2 (at the end)" part from.

If you pay close attention to the bit-bang code after the corrections were made, you'll see:

SPI_DATA <= 4 config bits
SPI_DATA <= 0
SPI_DATA <= 0
SPI_DATA <= (temp >> 9) & 1
SPI_DATA <= (temp >> 8) & 1
...
SPI_DATA <= (temp >> 1) & 1
SPI_DATA <= temp & 1


If something is wrong the output would change in larger steps with every 2 or 4 increments rather than one small step per increment.

The issue is simply that the significance of datasheet specs, in particular non-linear error, was overlooked; the chip is within spec.
 

Offline baljemmett

  • Supporter
  • ****
  • Posts: 666
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #48 on: January 30, 2012, 04:13:31 pm »
I don't know if anyone pointed this already, but I think it would be nice if Dave made diffident kits for different mains power specifications. (Like EU, US etc.)
I think it's designed to run off a plugpack or similar, rather than including the mains side of things -- so there shouldn't be anything that needs to change between mains systems.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #49 on: January 30, 2012, 05:28:39 pm »
Dave is using a 12-bit DAC shifted out MSB first for the test; of the 12 bits, only the lower 10 bits are used.

That doesn't make sense from a design perspective. In an output word the least significant bits affect the resolution while the most significant bits affect the magnitude. If you masked the most significant two bits to zero in a 12 bit word you would completely change the output value, whereas if you masked the least two bits to zero you would keep the same value but lose a bit (two bits) of precision. If you wanted the different chips in the family to be plug-compatible you would want to be masking off the lower two bits of the 12 bit word to leave a lower precision 10 bit word.

Although I have not had a chance to read the datasheet, I would be surprised if the chip designers dropped such a clanger.
I'm not an EE--what am I doing here?
 

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 833
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #50 on: January 30, 2012, 06:12:33 pm »
That doesn't make sense from a design perspective. In an output word the least significant bits affect the resolution while the most significant bits affect the magnitude. If you masked the most significant two bits to zero in a 12 bit word you would completely change the output value, whereas if you masked the least two bits to zero you would keep the same value but lose a bit (two bits) of precision. If you wanted the different chips in the family to be plug-compatible you would want to be masking off the lower two bits of the 12 bit word to leave a lower precision 10 bit word.

Although I have not had a chance to read the datasheet, I would be surprised if the chip designers dropped such a clanger.

Yeah, I see my error. Corrected code for 12-bit D/A using only 10 bits should have been:

Code: [Select]
SPI_DATA <= 4 config bits
SPI_DATA <= (temp >> 9) & 1
SPI_DATA <= (temp >> 8) & 1
...
SPI_DATA <= (temp >> 1) & 1
SPI_DATA <= temp & 1
SPI_DATA <= 0
SPI_DATA <= 0

EDIT: Now that I really think about it, the previous code snippet I posted would work depending on how Dave worked out the arithmetic of value before storing into temp for the shift operation (which isn't shown). I'm confusing the crap out of myself. :-\

EDIT EDIT: Ok. Head straight. Direct-no-modification interchangeability between 12-bit and 10-bit D/A won't work without some code modification.

If 2-bit zero mask is in MSB, then interchanging from 12-bit to 10-bit requires code modification because the 2-bit don't-cares is the last two bits sent on a 10-bit. For 12-bit, there's no scaling required for value, but for 10-bit, the zero mask will cause only 8-bit ranging if the value isn't scaled by a x4 multiplier.

If 2-bit zero mask is in LSB, then interchanging also requires code modification. 12-bit D/A would have to /4 scale for the desired mapping; popping a 10-bit without getting rid of the /4 scalar would limit output to 255.

Was the D/A even supposed to be interchangeable? Why bother if it can be shown that one performs better than the other?
« Last Edit: January 30, 2012, 07:28:34 pm by slateraptor »
 

Offline IanJ

  • Supporter
  • ****
  • Posts: 1023
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #51 on: January 30, 2012, 07:26:02 pm »
I think I would do the experiment implied by darrenb's question: successively increment the lsb of the data word you are sending and see what the delta of the output voltage is each time you increase it by 1.

I'd be inclined to do this also....but not just to rule out things like further code problems, but rather to test things like noise on the board amongst other things. Sure the datasheets seem to back up what he's getting but didn't Dave get some inconsitency with the repeatability of the output on his DMM?.........I haven't re-run the video to check again.

PS. Dave, have you been told yet how many folks are jealous you get to play with this stuff all day!!!

Ian.
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2 & PDVS2mini
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #52 on: January 30, 2012, 07:34:59 pm »
jaapiyo the supply is made to run off a plug-pack, all that needs to be changed is that and it would safely meet most foreign standards, being how you would be playing with plain DC on your end,
 

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 833
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #53 on: January 30, 2012, 07:40:06 pm »
I'd be inclined to do this also....but not just to rule out things like further code problems, but rather to test things like noise on the board amongst other things. Sure the datasheets seem to back up what he's getting but didn't Dave get some inconsitency with the repeatability of the output on his DMM?.........I haven't re-run the video to check again.

PS. Dave, have you been told yet how many folks are jealous you get to play with this stuff all day!!!

Ian.

How would measuring and recording the delta of 1024 steps rule out further code problems or test for noise? 12-bit INL alone is specified at +/-12LSB = +/-12mV at x2 gain. Even with all that data, you'd be hard pressed to determine if the error is internal to the D/A or external noise with just a delta snapshot.
 

Offline ndictu

  • Regular Contributor
  • *
  • Posts: 210
  • Country: sk
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #54 on: January 30, 2012, 08:14:29 pm »
Well what do you know, today one webcomic I'm subscribed to posted this, kind of relevant:


Source: Abstruse Goose 432 - O.P.C. - visit the authors website to support him and see the alt-text.
 

Offline nixxon

  • Frequent Contributor
  • **
  • Posts: 314
  • Country: no
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #55 on: January 30, 2012, 11:09:41 pm »
Another great episode, many thanks Dave.

It may not be important but the video shows you missing one more SPI_CLK typo, see @11:12 and later near the video end. The first line of a function is always the trickiest, and the last line, that's the trickiest too. Come to think of it... Anyway...

digitalWrite( SPI_CLK, LOW)

I guess this should be SPI_SCLK, as it is your DAC is missing 1/2 of the first clock cycle ?

I noticed that as well. It must be completely insignificant, because I can see no comment to your post regarding the uncorrected SPI_CLK string in the code:

I.e. at 13 minutes into the video there is a code line (3 lines below the code line that is altered) that is not changed:

digitalWrite(SPI_CLK, LOW);

It would have been nice with line numers in the code editor window, by the way

nixxon
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #56 on: January 30, 2012, 11:28:42 pm »
Another great episode, many thanks Dave.

It may not be important but the video shows you missing one more SPI_CLK typo, see @11:12 and later near the video end. The first line of a function is always the trickiest, and the last line, that's the trickiest too. Come to think of it... Anyway...

digitalWrite( SPI_CLK, LOW)

I guess this should be SPI_SCLK, as it is your DAC is missing 1/2 of the first clock cycle ?

I noticed that as well. It must be completely insignificant, because I can see no comment to your post regarding the uncorrected SPI_CLK string in the code:

I.e. at 13 minutes into the video there is a code line (3 lines below the code line that is altered) that is not changed:

digitalWrite(SPI_CLK, LOW);

It would have been nice with line numers in the code editor window, by the way

nixxon

I'm well aware of thanks, thanks.
It doesn't matter because it's only a first time initialise thing, the line is already low when it comes into the subroutine on the second pass.

Dave.
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #57 on: January 31, 2012, 03:31:33 am »
I can't understand why Dave moved the zero bits from the end of the bit banging sequence to the front?

From the formula in the datasheet, the output voltage would have been too high. I wanted 1mV/mA output.

Dave.

I agree that the zero bits need to be at the end as per the datasheet. This why when Dave start of at the low end of the mA range nothing seems to be happening, this is not noise but is cause by the truncation of the those low bit.  Put the zero bit at the end and give it a try. This is also why the DAC seems to produce an output that is to low.

Rutger
« Last Edit: January 31, 2012, 03:43:34 am by Rutger »
 

Offline slateraptor

  • Frequent Contributor
  • **
  • Posts: 833
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #58 on: January 31, 2012, 03:55:31 am »
I agree that the zero bits need to be at the end as per the datasheet. This why when Dave start of at the low end of the mA range nothing seems to be happening, this is not noise but is cause by the truncation of the those low bit.  Put the zero bit at the end and give it a try. This is also why the DAC seems to produce an output that is to low.

Rutger

That was the first thing that came to my mind earlier today. I eventually dropped the idea after a bit of thought and convinced myself that the error is internal to the D/A.
 

Offline Zad

  • Super Contributor
  • ***
  • Posts: 1013
  • Country: gb
    • Digital Wizardry, Analogue Alchemy, Software Sorcery
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #59 on: January 31, 2012, 05:57:52 am »
Something that has occurred to me, and I need to follow up later with a good look at the schematic. Could it be that the offset is being partially imposed with the following op-amp's input offset bias?

Don't jump down my throat if this is clearly a load of crap, I have only just woken up and it is 5 to 6 in the morning here :D


Offline IanJ

  • Supporter
  • ****
  • Posts: 1023
  • Country: scotland
  • Pro EE guy many years ago, now a hobby/home biz.
    • IanJohnston.com
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #60 on: January 31, 2012, 07:44:54 am »
It would have been nice with line numers in the code editor window, by the way

Yep, the IDE sucks........so I use UltraEdit (IDE in external editor mode).
In UE you can configure custom buttons on the toolbar (with a bitmap of your own choice). The button simply runs a wee bit of VBS code which sends keystrokes to the IDE to perform the compile/upload (next best thing to command line arguments which the IDE doesn't support).

Net result, once you've opened your sketch in the IDE you just leave it there and never touch it again....everything is done from within UE.

Code: [Select]
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.AppActivate "Arduino 1.0"
objShell.SendKeys "^u"

Ian.
Ian Johnston
www.ianjohnston.com
Manufacturer of the PDVS2 & PDVS2mini
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #61 on: January 31, 2012, 08:51:58 am »
Something that has occurred to me, and I need to follow up later with a good look at the schematic. Could it be that the offset is being partially imposed with the following op-amp's input offset bias?

Not when it's less than expected result.

Dave.
 

Offline shebu18

  • Frequent Contributor
  • **
  • Posts: 307
  • Country: ro
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #62 on: January 31, 2012, 10:16:39 am »
Dave, what IDE are you using? i recommend 0022 or 0020. They seem more stable and work better.
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2330
  • Country: gr
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #63 on: January 31, 2012, 11:27:27 am »
0022, 0020 is not just a different IDE. The API has changed.

Alexander.
Become a realist, stay a dreamer.

 

Offline Shale

  • Contributor
  • Posts: 43
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #64 on: January 31, 2012, 07:09:15 pm »
Dave. Can you explain to me why you went through the trouble of laying out the design and having a board made etc, and then trying to program the board? I am very new to electronics, and I would have put it all on bread board and the cranked out the code to make sure I had everything right while still on the bread board. Is one way preferred over the other?
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #65 on: January 31, 2012, 07:14:04 pm »
I guess Dave felt he could separate the hardware aspects from the firmware/software aspects in the design by keeping things modular. Once you are confident about the hardware part you can fix that into a board layout since the conceptual functions of the micro are already accounted for in the big picture. Developing the program on the micro won't change the overall system configuration.
I'm not an EE--what am I doing here?
 

Offline PeteInTexas

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #66 on: January 31, 2012, 07:42:43 pm »
I guess Dave felt he could separate the hardware aspects from the firmware/software aspects in the design by keeping things modular. Once you are confident about the hardware part you can fix that into a board layout since the conceptual functions of the micro are already accounted for in the big picture. Developing the program on the micro won't change the overall system configuration.

Yeah, but these pins with "alternative functions" is a " real trap for young players".  Your reading the pin out diagram and thinking that is enough but once you start writing the software it turns out you can't use them that way (or simply not recommended to use them that way) in conjunction with some other choice you made for some other pins; eg that reset pin.  Personally, I would have started with the software since that is the hardest part.  I know, everyone seems to think its the other way around dismissing it as just a "small matter of programming".
 

Offline Shale

  • Contributor
  • Posts: 43
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #67 on: January 31, 2012, 07:43:09 pm »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #68 on: January 31, 2012, 08:00:46 pm »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?

That's probably just a matter of being confident in how things will work out, and finding a circuit board more convenient to work with than a tangle on a breadboard...

(There can always be another board revision to iron out wrinkles.)
I'm not an EE--what am I doing here?
 

Offline Shale

  • Contributor
  • Posts: 43
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #69 on: January 31, 2012, 08:09:55 pm »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?

That's probably just a matter of being confident in how things will work out, and finding a circuit board more convenient to work with than a tangle on a breadboard...

(There can always be another board revision to iron out wrinkles.)

I guess I am from a  way of thinking that once you pay to get a board, or whatever, then you should already  have the wrinkles ironed out. I may be looking at it in the whole wrong way since I am new though. and of course I thinking that from video 241 that the board cost $90. Maybe I am cheep, but seems like a lot of money to me to not be 100% sure. Is this normal in the industry?
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #70 on: January 31, 2012, 09:07:44 pm »
It's called "professional confidence". Once people reach a certain level of experience they can take steps like that and have sufficient confidence the design is going to work. Every now and then there will be a stumble, but on balance overall progress is faster when taking big steps than when taking smaller steps. Experienced practitioners tend to do the same in other fields too. You might also call it "impatience", but "professional confidence" sounds better  ;)

Also remember that in industry $90 is small change, whereas for the hobbyist it is much more significant. I guess Dave is somewhere in between right now...
I'm not an EE--what am I doing here?
 

Offline Short Circuit

  • Frequent Contributor
  • **
  • Posts: 439
  • Country: nl
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #71 on: January 31, 2012, 09:28:31 pm »
I guess what I was trying to say is that, How does he know all the hardware is right? the issue he is having with the DAC as an example?
He doesn't... EEVblog #17 – I hope your next project DOESN’T work!   8)

Quote
I guess I am from a  way of thinking that once you pay to get a board, or whatever, then you should already  have the wrinkles ironed out. I may be looking at it in the whole wrong way since I am new though. and of course I thinking that from video 241 that the board cost $90. Maybe I am cheep, but seems like a lot of money to me to not be 100% sure. Is this normal in the industry?
Of course this is normal practice in industry; $90 is less than an hour worth of work.
Also prototyping and breadboarding does not eliminate errors. Build 2 or 3 real prototypes, and you can easily seperate stupid accidental mistakes from the real design errors.
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 1991
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #72 on: January 31, 2012, 09:28:58 pm »
Another thing to consider is that breadboards suck :)  They are hard to use, harder to debug, and unreliable (wires that look like they are in sometimes don't make good contact.  They are hard to use for SMD, and get ugly quickly for a moderately complicated design.  The worst part is that once you get your circuit working, it is very hard to see what you have, and very easy to make mistakes when converting it to a PCB.

If you can afford it, it is much nicer to make a PCB that you know is 95% correct, make some layout choices to facilitate debugging and repair, and then fix it up with bodge wires until it works.  Once you get all the bugs worked out, it is much easier to make the handful of changes to your PCB and send it out for a second spin.  Considering there is a good chance you will make errors in your first PCB even if it is based on a working breadboard, it isn't necessarily much more expensive on average.

In the professional world, if it saves an engineer a couple of hours of swearing at a breadboard, $90 is cheap.  For a hobbyist that may or may not be the case. You can also etch your own boards to save money.  This also takes some time, but has the advantage over a professional PCB of instant gratification.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #73 on: January 31, 2012, 09:42:09 pm »
Dave. Can you explain to me why you went through the trouble of laying out the design and having a board made etc, and then trying to program the board? I am very new to electronics, and I would have put it all on bread board and the cranked out the code to make sure I had everything right while still on the bread board. Is one way preferred over the other?

Because to me it's important to have something real in my hands to play with, I prefer that to mucking around with a breadboard, as other have explained.
A real board let's you play with the case and physical aspects early in the design process, and gives you a better sense of project being on track and keeps your enthusiasm up for the project.
Most of my designs are SMD, so going to a PCB early is practically essential. That thinking just naturally follows over to through-hole projects.

Dave.
 

Offline asgard

  • Regular Contributor
  • *
  • Posts: 119
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #74 on: January 31, 2012, 09:47:29 pm »
Well, this is where I get to put my two cents worth (Yup, that's U.S. money, so that, and a banana will get you lunch for a monkey  :)

On the matter of the rolling/unrolling of loops:  After more than a decade in the RTOS business (MIPS/68xxx/PPC) it always amazes me that in a memory-constrained architecture it is the time component that is consumed first.  On the x86 and 68K the branch predictors are total shite.  No matter that the pipeline "knows" in advance where the branch is going to be, and the prefetcher knows to start working even before the branch is taken, the lookaside cache gets flushed for _any_ passage through a conditional branch instruction, even if the branch is not taken.  Believe me when I tell you that re-filling a flushed cache just sucks micro-ops, especially when the compiler optimizes nicely and ensures reference locality.  You might also note which real-estate on the CPU die represents the cache manager, as you can put an LC film over the die and see which parts are heating up the most.  Sometimes I have found out the bottlenecks in the application code that way.  It also might reduce the design-life of the part. :)

On the matter of the MCP DAC.  I had a good and hard look through the datasheet and really don't have any idea of the internal architecture of the DAC.  Is it successive approximation?  Is it some kind of screwy Sigma-Delta method?  How about double-buffered?  If the output is going to a R-2R resistive ladder just how good is the trimming process?  Hellifino.  I too can remember the day when _really_ accurate 8-bit DACS (Burr-Brown comes to mind) required great chunky bricks of epoxy with hand-trimmed resistors with an actual eyeball making laser decisions for every single part.  My brain curdles at the though of that job.
Klaatu Barada Nikto!

J.R. Stoner Bifrost Development Group asgard@jeffnet.org
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 1991
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #75 on: January 31, 2012, 11:22:49 pm »
On the matter of the MCP DAC.  I had a good and hard look through the datasheet and really don't have any idea of the internal architecture of the DAC.  Is it successive approximation?  Is it some kind of screwy Sigma-Delta method?  How about double-buffered?  If the output is going to a R-2R resistive ladder just how good is the trimming process? 

The data sheet says it is a 'resistive string architecture'  -- to me that means a chain of 4096 resistors in a voltage divider, mosfet switches for each tap, and a buffer amplifier.  It seems a bit surprising to have that long of a string, but it would explain the large INL, and they do claim that it provides low DNL, which makes sense.
 

Offline benemorius

  • Regular Contributor
  • *
  • Posts: 173
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #76 on: February 01, 2012, 12:56:51 am »
@Dave

Can't you keep the 1mV/step you're after while disabling the x2 gain and the error associated with it by multiplying your value by 2 before sending it to the DAC? You don't actually need the DAC to scale all the way to 4.096V right? In the video, it looked like your error was at least somewhat smaller before you switched on the x2 gain. (closer to 2.5mV rather than 5mV)

Also, by forcing the 2 MSBs to zero it seems to me that you're clipping your max DAC output to 1024mV (or 512mV with x1 gain). Obviously you'll catch that sooner or later, but it may as well be sooner. ;)

 

Offline janekm

  • Supporter
  • ****
  • Posts: 516
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #77 on: February 01, 2012, 01:23:59 am »
I believe the formula referencing D/4096 in page 23 is a bit of a datasheet bug... It contradicts Table 4-1 on page 19 which states clearly that 1LSB = Vref /256 * G in the case of the 8-bit part (so for Dave's design that would be 16mV). 
So clearly the INL is still tightest for the 12-bit part as one would expect. 

Also, agree with @benemorius... The error will be less if only using the gain when it is needed for the full 4.096V range, as with the gain turned off 1LSB on the 12-bit part is .5mV so only +-6mV INL ( or even better by reducing the gain error, which is max 1% of FSR, or 40mV!).
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #78 on: February 01, 2012, 10:07:36 am »
from the size of the heatsink it looks like the case could potentally host an entire second layer of pcb and possibly even a third, if one wanted to mod that far, possible?
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #79 on: February 01, 2012, 10:27:08 am »
from the size of the heatsink it looks like the case could potentally host an entire second layer of pcb and possibly even a third, if one wanted to mod that far, possible?

Indeed. There is a second board to come...

Dave.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #80 on: February 01, 2012, 10:47:32 am »
and the case :), you have been dragging us along on that
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #81 on: February 01, 2012, 11:38:24 am »
and the case :), you have been dragging us along on that

Should we start a betting pool?

My money is on a stackable instrument enclosure from polycase http://www.polycase.com/zn2
http://www.polycase.com/uploads/135971291909912.flv
« Last Edit: February 01, 2012, 11:41:24 am by BoredAtWork »
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 slateraptor

  • Frequent Contributor
  • **
  • Posts: 833
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #82 on: February 01, 2012, 11:48:59 am »
My money is on a stackable instrument enclosure from polycase http://www.polycase.com/zn2

They're not made Down Under...you sure you want to make that bet? ;)

BTW, thanks for the link. Never heard of these guys before.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #83 on: February 01, 2012, 11:53:56 am »
They're not made Down Under...you sure you want to make that bet? ;)

Unfortunately the only cases that are made in Australia are the Jiffy Boxes, as used in the uCurrent.

The case is nothing special, nor secret, but now that everyone is keen to know, I'll tease a bit longer...  :P

Dave.
 

Offline baljemmett

  • Supporter
  • ****
  • Posts: 666
  • Country: gb
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #84 on: February 01, 2012, 12:13:15 pm »
The case is nothing special, nor secret, but now that everyone is keen to know, I'll tease a bit longer...  :P

You're a big meanie, Dave ;)  It's the secret 'higher purpose' you've mentioned that intrigues me; I have my suspicions, but better to remain silent and be thought a fool and all that!
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #85 on: February 01, 2012, 12:24:58 pm »
You're a big meanie, Dave ;)  It's the secret 'higher purpose' you've mentioned that intrigues me; I have my suspicions, but better to remain silent and be thought a fool and all that!

It's not really a "higher purpose" as such, like an application use like a battery charger some people have suggested. Its just more of a feature that I envisioned from the start that drove many of the decisions.

Dave.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #86 on: February 01, 2012, 12:46:41 pm »
They're not made Down Under...you sure you want to make that bet? ;)
What else should he use, carved wood?  ;)

Quote
BTW, thanks for the link. Never heard of these guys before.

They have some nice stuff. Unfortunately they have horrible shipping costs to Europe, so I tend to avoid them, unless my employer pays. I can think of better deals than $3 for an enclosure plus $50 to $80 for shipping.
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 markus_b

  • Regular Contributor
  • *
  • Posts: 115
  • Country: ch
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #87 on: February 01, 2012, 02:02:40 pm »
They have some nice stuff. Unfortunately they have horrible shipping costs to Europe, so I tend to avoid them, unless my employer pays. I can think of better deals than $3 for an enclosure plus $50 to $80 for shipping.
I have the same problem (Switzerland). In addition you start to pay taxes and custom fees when the price, including shipping exceeds $75 or so. A small $35 order then costs $120 because of $50 shipping and $35 tax+custom. The Chinese have learnt to deal with this as you can get cheap shipping to the world. This allows Dealextreme et al to thrive.
Markus

A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.
 

Offline markus_b

  • Regular Contributor
  • *
  • Posts: 115
  • Country: ch
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #88 on: February 01, 2012, 02:09:25 pm »
One idea for the link to a PC, maybe on a daughter-board: Just use a low cost Bluetooth adapter. This provides a serial link with galvanic separation (no cable). On the PC it looks like a serial port, much the same as a USB/serial converter.

With most PCs these days having Bluetooth built-in and such modules available for under $10 this looks very attractive. Example: Bluetooth module at Dealextreme, $6.60
Markus

A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.
 

Offline FreeThinker

  • Frequent Contributor
  • **
  • Posts: 791
  • Country: england
  • Truth through Thought
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #89 on: February 01, 2012, 03:13:44 pm »
Just a quick question from a noob to avr's is the sda line pulled high internally as I can't see one on the board?
Machines were mice and Men were lions once upon a time, but now that it's the opposite it's twice upon a time.
MOONDOG
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #90 on: February 01, 2012, 04:27:53 pm »
Just a quick question from a noob to avr's is the sda line pulled high internally as I can't see one on the board?

The external pullups are in section C4 on the rev B schematics. AVRs do have internal, switchable pull-up's, however these are too weak for I2C.
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 FreeThinker

  • Frequent Contributor
  • **
  • Posts: 791
  • Country: england
  • Truth through Thought
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #91 on: February 01, 2012, 04:49:24 pm »
Thanks for that B@W. Missed that section entirely...one of the problems with 'modular' schematics is traceing signals that go to umpteen places with no indication on the drawing (especially if you are not familiar with the system/operation) but I should have spotted that one. Getting old I guess :(
Machines were mice and Men were lions once upon a time, but now that it's the opposite it's twice upon a time.
MOONDOG
 

Offline benemorius

  • Regular Contributor
  • *
  • Posts: 173
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #92 on: February 01, 2012, 05:08:02 pm »
Thanks for that B@W. Missed that section entirely...one of the problems with 'modular' schematics is traceing signals that go to umpteen places with no indication on the drawing (especially if you are not familiar with the system/operation) but I should have spotted that one. Getting old I guess :(

But one of the huge advantages of pdf schematics is that you can use the search feature to follow net names around. ;)
 

Offline FreeThinker

  • Frequent Contributor
  • **
  • Posts: 791
  • Country: england
  • Truth through Thought
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #93 on: February 01, 2012, 07:23:33 pm »
Thanks for that B@W. Missed that section entirely...one of the problems with 'modular' schematics is traceing signals that go to umpteen places with no indication on the drawing (especially if you are not familiar with the system/operation) but I should have spotted that one. Getting old I guess :(

But one of the huge advantages of pdf schematics is that you can use the search feature to follow net names around. ;)
Never thought of that  ;D. Tend to print things out (old school).....I really am showing my age :'(
Machines were mice and Men were lions once upon a time, but now that it's the opposite it's twice upon a time.
MOONDOG
 

Offline asgard

  • Regular Contributor
  • *
  • Posts: 119
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #94 on: February 01, 2012, 08:35:48 pm »
They're not made Down Under...you sure you want to make that bet? ;)
What else should he use, carved wood?  ;)


Why not?  It was good enough for Lee Felsenstein.  Loved those beefy wood end-pieces on the SOL-20's.

BTW about that heatsink.  It appears to be a single-source item common to Australia and New Zealand.
Just how much dissipation is being contemplated here?  Ohmite has a number of chunky single TO-220 heatsinks, but no duals of the same mounting character as yours.  Any particular recommendation on a Mouser/Digikey/Allied substitution?

J.R.
Klaatu Barada Nikto!

J.R. Stoner Bifrost Development Group asgard@jeffnet.org
 

Offline Blue

  • Regular Contributor
  • *
  • Posts: 55
  • Country: nl
  • Fighting for peace is like fucking for virginity
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #95 on: February 01, 2012, 08:57:20 pm »
Dave's teaser: Use two boards and you've got a +- powersupply....
Nice for opamps etc...  ;)
« Last Edit: February 01, 2012, 08:59:47 pm by Blue »
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #96 on: February 01, 2012, 09:56:24 pm »
BTW about that heatsink.  It appears to be a single-source item common to Australia and New Zealand.
Just how much dissipation is being contemplated here?  Ohmite has a number of chunky single TO-220 heatsinks, but no duals of the same mounting character as yours.  Any particular recommendation on a Mouser/Digikey/Allied substitution?

Sorry, no idea.
Yes, the heatsink is custom made for Altronics apparently.
It was just the right size for my box.
The holes are not the right height for a TO-220 package though which is annoying.

Dave.
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #97 on: February 01, 2012, 10:22:16 pm »
Just a quick question from a noob to avr's is the sda line pulled high internally as I can't see one on the board?

The external pullups are in section C4 on the rev B schematics. AVRs do have internal, switchable pull-up's, however these are too weak for I2C.

Hmm? You can definitely use the internal ones for I2C. The Arduino Wire library enables them (20k??), which has been used numerous times without external pullups. There are situations where external ones are better though.
 

alm

  • Guest
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #98 on: February 01, 2012, 10:45:27 pm »
Maximum value for pull up resistors is determined by the capacitance of the track/cable and connected devices. I believe the max rise time for standard mode is 1 us. From the ATmega328p datasheet, the value of the internal pull-ups would be about 33 kohm for Vcc=2.7V, this would limit the capacitance to about 30 pF. The ATmega328p alone contributes about 10pF, this would leave another 10 pF for one slave and about 10 cm of PCB trace. It's probably not enough for multiple slaves or if connectors are involved.
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #99 on: February 01, 2012, 10:49:10 pm »
Hmm? You can definitely use the internal ones for I2C. The Arduino Wire library enables them (20k??), which has been used numerous times without external pullups. There are situations where external ones are better though.

The Arduino people do a lot of rubbish things. And just because it sometimes works for them, it isn't a good idea. The build-in pull-ups are rather imprecise, varying up to 50k or maybe higher in older AVRs. Depending on the capacitive load and clock frequency you have on the I2C bus this becomes a gamble. The greater the capacitive load, the higher the clock frequency, the smaller the pull-up resistors should be. Therefore engineers put real pull-up resistors on the bus, while Arduino gamblers just throw the dice.
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 electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #100 on: February 01, 2012, 10:58:15 pm »
Fair enough. Just saying it can be done, and it usually successful. Other than quick and dirty tests on breadboards, I usually stick a couple of 4k7 or 6k8s, as my time in potential troubleshooting is worth more than 2 cents.
 

Offline ModernRonin

  • Contributor
  • Posts: 44
Closed loop voltage control for the DAC?
« Reply #101 on: February 02, 2012, 09:47:29 pm »
Since the DAC seems to be inaccurate, I wanted to ask what everyone thought about using some kind of closed loop control scheme for it. I realize this is probably the wrong answer; the right way to do things is to get a DAC that doesn't suck.

But if there are no DACs that don't suck, or the non-sucky ones are so expensive as to be prohibitive and/or not available in through-hole... what needs to be done to close the control loop on the DAC?

I mean sure, you can feed the DAC voltage back to the ADC and measure it. Now you're depending on the accuracy of the ADC. My guess is that high precision ADCs are a lot more expensive than high precision DACs.

So, is there any way to do some kind of analog wizardry with the voltage reference we already have? Off the top of my head, my idea goes something like this... we already have a uCurrent on the board, so let's use it. Take the voltage reference and the output voltage of the DAC and connect them with a 1k resistor. Then use the uC to measure the amount of current flowing through the resistor. Said current being proportional to the voltage differential between the two sources. Then feed that number back into the AVR and do some math, and adjust the data being written to the DAC accordingly.

Am I being completely insane here?
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 1991
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #102 on: February 02, 2012, 10:00:11 pm »
Any way you slice it, you have to trust your DAC or your ADC.  How are you going to read the ucurrent?  With an ADC.

The best thing to do is to use an intrinsically linear DAC architecture.  For instance, compared to a string DAC, an R2R DAC has much better INL although the DNL may be worse.  PWM and sigma-delta DACs are nearly perfectly linear by nature, so they are a good choice when that is important.  They work on the principle that a 1-bit DAC can't be non-linear as there are only two states.  Two points define a line.  Thus the techniques use interpolation in time to make intermediate values.  This works because we can generate very stable clocks.
 

Offline Rufus

  • Super Contributor
  • ***
  • Posts: 2094
Re: Closed loop voltage control for the DAC?
« Reply #103 on: February 02, 2012, 11:52:05 pm »
Am I being completely insane here?

Not completely :)

The way to improve performance of DACs and ADCs with loose specification it so calibrate them (which would also calibrate out other error sources like the reference voltage and resistor matching).

It is only software and an bit of NV memory and requires 5 minutes and a decent multimeter to perform. I think I remember Dave saying or writing he couldn't be bothered with scaling and calibration. If the PSU ends up being popular someone will write the software to do it properly.
 

alm

  • Guest
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #104 on: February 03, 2012, 01:57:40 am »
Doing that 5 minute calibration for a production run could be a pain, however, although it wouldn't be such an issue with a kit. For a batch of 50, like with the uCurrents, it would require about four hours. I guess Dave could think of a more enjoyable way to spend those four hours, for example by ranting about Microchip DACs ;). It also requires the error to be stable.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #105 on: February 03, 2012, 11:09:28 am »
software calibration procedure wouldn't be that bad if the user had to do it, turn on kit, hold in 2 buttons as it starts up,

then measure and trim in with the rotary encoder, and have it update on each time you fill in the value to narrow the error, until each value matched up exactly?

then one could probably get away with a correction formula, maybe a bit complex to make something to accurately calculate over the whole range, (please shoot me down if i am wrong, just thinking) or are math functions really that performance prohibitive, as i can neither see any way to calibrate the reference, DAC or ADC short of software,
 

Offline dcel

  • Regular Contributor
  • *
  • Posts: 179
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #106 on: February 03, 2012, 02:07:20 pm »
Hi all...

I believe I found a possible answer to the last addendum of the video regarding the I2C bus problem with the LCD. I think it is the -ACK from the LCD trying to pull that line low. I found this info in my datasheet for the MCP23016 that I have.  Apperantly, there are a few protocols for I2C and some slaves -ACK and some dont, esp., if being read from exclusively. If someone more knowledgeable than I about I2C would chime in that would be great.

Chris

 

Offline FreeThinker

  • Frequent Contributor
  • **
  • Posts: 791
  • Country: england
  • Truth through Thought
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #107 on: February 03, 2012, 05:16:20 pm »
Hi all...

I believe I found a possible answer to the last addendum of the video regarding the I2C bus problem with the LCD. I think it is the -ACK from the LCD trying to pull that line low. I found this info in my datasheet for the MCP23016 that I have.  Apperantly, there are a few protocols for I2C and some slaves -ACK and some dont, esp., if being read from exclusively. If someone more knowledgeable than I about I2C would chime in that would be great.

Chris
Yes This has been pointed out by a couple of people. Seems logcal to me that the device SHOULD ack data sent but not all devices do (apparently) not very helpfull in a fault situation. Don't think it is a big deal but easily fixed (I think) :P
Machines were mice and Men were lions once upon a time, but now that it's the opposite it's twice upon a time.
MOONDOG
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #108 on: February 05, 2012, 01:25:45 am »
Dave, I was looking at the different options for the DAC, because I was looking at the dual version of your power supply (eg with a negative output as well) and came across the following 4 channel 12 bit DAC:
   
MCP4728-E/UN  at $ 1.44 / 100 with build in voltage reference (optional).

I know you didn't want surface mount parts but with the Maxim 4080 and the voltage ref chip you have chosen that option is already gone.

The advantage of having the extra 2 channels is that you can add/drive another power supply from the same DAC. And you can save on the cost of the parts, maybe you eliminate the external voltage ref chip.

Rutger
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #109 on: February 05, 2012, 01:40:22 am »
the thing is, until dave reveals the second board, it seems pretty clear his design had in mind only a single supply, and until he reveals his secret purpose, a dual dac is all thats needed, albeit a better quality one at a similar price is something he is likely looking out for, (about $6 for a dual dac without such an insane offset)
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2330
  • Country: gr
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #110 on: February 05, 2012, 02:28:07 pm »
Are you sure there will be second board (did Dave mentioned something?)? Maybe the space is needed for a flat lead acid battery.

Alexander.
Become a realist, stay a dreamer.

 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #111 on: February 05, 2012, 10:49:36 pm »
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

Forgive me if this has been covered elsewhere, but why are you bit-banging SPI in the first place? The Atmega328 has hardware SPI, and hardware I2C. Sending data to the device should be as simple as:

Code: [Select]
digitalWrite (SS, LOW);  // or high, whatever is required
y = SPI.transfer (x);  // send a byte, get one back
digitalWrite (SS, HIGH); // finished with slave
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #112 on: February 05, 2012, 10:54:11 pm »
From Dave at the video comments on the main page:
Quote from: Dave
I’ve been asked this countless times now. I am leaving the hardware SPI free for the external serial interface, for Ethernet, or other serial device that needs it.

(Would this have been a problem if all on the hardware bus anyway?)
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #113 on: February 06, 2012, 12:02:04 am »
Er, but ...

SPI is designed to be paralleled up. Not using it in the core device, but leaving it free for something people might or might not add, seems to me to be doing it backwards.

You already have the separate chip selects, which you need to activate each chip. Now all you have to do is share the SPI pins (MOSI, MISO, SCK). The only (device) output line (MISO) goes high-impedance whenever the target device is not selected. It's designed like that.

That is not at all taking away the ability to use other chips like Ethernet, SD cards or whatever. They would each just need their own chip select, and I see you have four free on the MCP23008 chip anyway.

The hardware SPI has buffers, interrupt capability etc.

In fact, freeing up your SPI-DIN, SPI-CLK etc. pins would mean you can probably bypass having to use the port-expander just to toggle the chip select lines. So, the whole thing becomes much simpler.

(Would this have been a problem if all on the hardware bus anyway?)

No, that's my point.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #114 on: February 06, 2012, 12:21:29 am »
Nick, you've missed the whole point.
The point is that keeping the bus entirely free allows people to do anything they want with it, not just SPI.
Beginners can play with the pins and port, or the SPI or whatever and not have to worry about screwing up the existing ADC/DAC interface.
And it allows the separate DAC/ADC interface to operate on it's own timer interrupt or something similar as well without having to worry about conflicts.

Dave.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #115 on: February 06, 2012, 12:42:16 am »
OK, Dave. :)

Adding an Ethernet interface to a sophisticated power supply doesn't sound to me like a beginner project, but you're the boss!

I look forwards to seeing it.
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #116 on: February 06, 2012, 12:45:09 am »
Speaking of looking forward, is there an ETA on part 9?
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #117 on: February 06, 2012, 01:07:45 am »
Adding an Ethernet interface to a sophisticated power supply doesn't sound to me like a beginner project, but you're the boss!

The whole point of going the Arduino route is that it does become trivial for anyone to add such a feature.
I'm not that fussed myself, but people may very well want to add such a thing.
Or experiment with the ports in unknown ways for their own purposes etc.
The more you decouple the core function like ADC/DAC from the expandability ports, the easier it all is.
Why do you think many modern micros have more than one SPI and I2C port?
If this AVR had two hardware SPI ports I still would have used two separate hardware SPI ports for this very reason.

Dave.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #118 on: February 06, 2012, 01:09:40 am »
Speaking of looking forward, is there an ETA on part 9?

I don't have ETA's.
I don't even know what Part 9 will be until I decide to do it.
I have the PCB layout time lapse to do, maybe something on the 10bit DAC and ADC parts if there is something worth sharing there, maybe the 2nd board or system engineering part, I don't know....

Dave.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #119 on: February 06, 2012, 01:29:22 am »
If this AVR had two hardware SPI ports I still would have used two separate hardware SPI ports for this very reason.

It doesn't need two hardware SPI ports because you can share them between multiple devices. Ditto for the I2C port.

Having said that, though, the hardware does support "USART in SPI Mode" (page 204 of the datasheet). So you effectively have two SPI ports (although the USART one is master only, not that this would matter in your case).

I'm not sure what multiple SPI ports really gives you. Already SPI is pretty fast (eg. about 3 uS per byte, which is around 48 clock cycles). Pretty much as fast as an interrupt can be serviced. So realistically you could only use one SPI port at high speed anyway (by the time you store the data, loop, test if it's time to get another byte and so on).

Quote
And it allows the separate DAC/ADC interface to operate on it's own timer interrupt or something similar as well without having to worry about conflicts.

Once you bit-bang, interrupts become more of an issue because you are handling the timing, not the hardware.

Anyway, thanks for sharing all your design ideas, it's interesting to see how it all comes together.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #120 on: February 06, 2012, 01:33:54 am »
There's an interesting design conundrum here. One tries to separate the core functions from the bits people might want to hack, so that misguided hacks don't break the core functions. However, the whole thing inside the MCU is operating on software, and if someone hacks the software badly they could break everything. The ultimate solution here would be two MCUs--one dedicated to the core device function running a fixed program, and one for user programming separated from the core functions with protected interfaces...  ;D
I'm not an EE--what am I doing here?
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #121 on: February 06, 2012, 01:39:50 am »
I'm not sure what multiple SPI ports really gives you. Already SPI is pretty fast (eg. about 3 uS per byte, which is around 48 clock cycles). Pretty much as fast as an interrupt can be serviced. So realistically you could only use one SPI port at high speed anyway (by the time you store the data, loop, test if it's time to get another byte and so on).

In this case I've made it very clear what advantage it gives you and anyone playing around with it.
A beginner can now screw around with the SPI/serial I/O interface all they want without worrying about screwing up any of the core functionality of the project.
IMO that is a big advantage and is a main reason why I did it that way.
When designing stuff like this you have to think about those sorts of little things that might make someones life easier down the track, or give them the flexibility to do something you as the designer haven't thought of.

Dave.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #122 on: February 06, 2012, 01:44:15 am »
There's an interesting design conundrum here. One tries to separate the core functions from the bits people might want to hack, so that misguided hacks don't break the core functions. However, the whole thing inside the MCU is operating on software, and if someone hacks the software badly they could break everything. The ultimate solution here would be two MCUs--one dedicated to the core device function running a fixed program, and one for user programming separated from the core functions with protected interfaces...  ;D

And that's the trick.
Nick is saying don't bother, forget it, just use the most elegant technical solution because you can  ;D
My approach is to do some small things in this regard that may possibly help some people people down the track (maybe even myself).
And you propose designing the Space Shuttle by committee :P

Dave.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #123 on: February 06, 2012, 02:21:30 am »
Nick is saying don't bother, forget it, just use the most elegant technical solution because you can  ;D
My approach is to do some small things in this regard that may possibly help some people people down the track (maybe even myself).

You've certainly helped me, Dave. :)

Heck, I even made up your dummy load a couple of days ago. Picture here:

http://gammon.com.au/forum/?id=11525

What I like about your approach is that you often describe the elegant technical solutions. For example, in the first video for the power supply you showed how you could have used two voltage regulators (one for current and one for voltage) but with careful, elegant, design, you cut it down to one. I like that.

You research stuff, and you choose the right part for the job. :)
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #124 on: February 06, 2012, 03:30:54 am »
You research stuff, and you choose the right part for the job. :)

Not always.
Sometimes I just do things because I want to  :P

Dave.
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #125 on: February 06, 2012, 06:38:30 am »
Dave, on the video you told us that putting the rotary encoders on the I2C I/O would not be a good idea.  But speed isn't really an issue with encoders is it? Could you explain?

Rutger
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #126 on: February 06, 2012, 06:43:38 am »
One reason (and I think this is what Dave said in the video), is that you want to read a rotary encoder from pin change interrupts, which is most easily done using the appropriate pins directly on the uC.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #127 on: February 06, 2012, 07:05:36 am »
Dave, on the video you told us that putting the rotary encoders on the I2C I/O would not be a good idea.  But speed isn't really an issue with encoders is it? Could you explain?

Yes, the reason was primarily easy and fast interrupt capability.
I'm not using interrupts at the moment BTW, and update rate does in fact matter, a lot as it turns out. My first attempt at main loop code had me doing everything once per loop (update LCD, read I2C switches, read rotary encoders etc), but I was easily missing rotary encoder steps when turning the knob very fast. I had to increase the rotary encoder checking 1000:1 to the other code to get a sufficient encoded update rate.

Dave.
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #128 on: February 06, 2012, 07:26:46 am »
Running out of processing speed?  You might want to consider putting a faster chip in the board, like the ATMEGA328 that can run easily 2 times faster at 16MHz.
And you can even clock it at 20Mhz! ;)

Another thing I noticed looking at the DAC specs is that the internal error is less if you use the higher supply voltage. Have you tried feeding it 5V instead of 3.3V?

I might bread board the Rotary encoders using the I2C chip with the interrupt and see if I can get it to work that way.   I hate to waste 4 ports on 2 encoders.

Rutger
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #129 on: February 06, 2012, 08:17:51 am »
I did a post about rotary encoders and interrupts:

http://www.gammon.com.au/forum/?id=11130

You can make one rotary encoder use a single "external" interrupt, and since you have two encoders, that takes care of the two external interrupt pins (ie. D2 and D3). (A bit of circuit rejigging might be required).

If that isn't feasible or desirable, pin-change interrupts, although more fiddly to work with, might do the trick.

I found when I was playing with rotary encoders that, whilst they can be made to work reliably, swapping two lines of code can impact reliability significantly.  It's all about race conditions.

Quote
You might want to consider putting a faster chip in the board, like the ATMEGA328

The chip he is using will run at 16 MHz (at 3.78V). I don't think that is the problem. Although to save a dollar, I'm not sure why I wouldn't just go with the chip with more RAM and program memory. At 3.3V he can run at 12 MHz if speed is an issue, but really with interrupts that shouldn't be a problem.
 

Offline nessatse

  • Regular Contributor
  • *
  • Posts: 98
  • Country: za
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #130 on: February 06, 2012, 08:26:59 am »
Running out of processing speed?  You might want to consider putting a faster chip in the board, like the ATMEGA328 that can run easily 2 times faster at 16MHz.
And you can even clock it at 20Mhz! ;)

I don't think that is quite necessary.  The main rason for any slowness are the bloated Arduino libraries.  Just replacing crap Arduino calls like digitalWrite and digitalRead with direct port reads and writes will make a huge difference already.  Just look at the Arduino library source code if you need convincing.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #131 on: February 06, 2012, 08:31:34 am »
nickgammon, personnaly i do not understand how your rotary encoder method would work, would it not involve atleast 2 pulses to tell direction, in place of 1 for daves method,
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #132 on: February 06, 2012, 08:39:18 am »
I don't think that is quite necessary.  The main rason for any slowness are the bloated Arduino libraries.  Just replacing crap Arduino calls like digitalWrite and digitalRead with direct port reads and writes will make a huge difference already.

They are not crap, they do what they are designed to do, which is to simplify programming. Direct port reads and writes will be faster, particularly if you know in advance what port you want to access. In that case, variable reads can be replaced by constants, which of course will be faster. But if you want to set (say) 10 consecutive pins to output then it becomes trickier. Or if you you need to set some pin, which pin you don't know until runtime, then you need to do a table lookup, which then slows things down to the speed of the libraries. They didn't make them slow to amuse themselves.

In any case, reading rotary encoders is best done by an interrupt service routine, in which case the question of whether or not digitalRead is slow becomes a bit academic.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #133 on: February 06, 2012, 08:51:29 am »
nickgammon, personnaly i do not understand how your rotary encoder method would work, would it not involve atleast 2 pulses to tell direction, in place of 1 for daves method,

These are the conditions:

Code: [Select]
Forward direction: LH then HH, or HL then LL
Reverse direction: HL then HH, or LH then LL

Given a state change on one of them (eg. the first one) and looking at this code:

Code: [Select]
// Interrupt Service Routine for a change to encoder pin A
void isr ()
{
  if (digitalRead (PINA))
    up = digitalRead (PINB);
  else
    up = !digitalRead (PINB);
  fired = true;
}  // end of isr

If the first pin (PINA) is (now) high then we are going up if PINB is HIGH (LH -> HH).
If the first pin (PINA) is (now) low then we are going up if PINB is LOW (HL -> LL).
Otherwise we are going down.  :)

One interrupt and we know what we are doing.
 

Offline nessatse

  • Regular Contributor
  • *
  • Posts: 98
  • Country: za
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #134 on: February 06, 2012, 09:37:07 am »
They are not crap, they do what they are designed to do, which is to simplify programming. Direct port reads and writes will be faster, particularly if you know in advance what port you want to access.

I can't think of many embedded applications where you don't know in advance where your peripherals are connected.  If you compare the Arduino code:
Code: [Select]
void digitalWrite(uint8_t pin, uint8_t val)
{
uint8_t timer = digitalPinToTimer(pin);
uint8_t bit = digitalPinToBitMask(pin);
uint8_t port = digitalPinToPort(pin);
volatile uint8_t *out;

if (port == NOT_A_PIN) return;

// If the pin that support PWM output, we need to turn it off
// before doing a digital write.
if (timer != NOT_ON_TIMER) turnOffPWM(timer);

out = portOutputRegister(port);

uint8_t oldSREG = SREG;
cli();

if (val == LOW) {
*out &= ~bit;
} else {
*out |= bit;
}

SREG = oldSREG;
}

with the staightforward example:
Code: [Select]
  PORTB |= _BV(SOME_PIN);
(which incidentally usualy gets optimised to a single instruction)
there can be no argument as to which one has no place in production code.

Quote
But if you want to set (say) 10 consecutive pins to output then it becomes trickier.

Trickier than what??

Quote
In any case, reading rotary encoders is best done by an interrupt service routine, in which case the question of whether or not digitalRead is slow becomes a bit academic.

Not really.  Bloated and slow code is bad, whether in an ISR or not
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #135 on: February 06, 2012, 09:43:38 am »
What if I want my code to be directly portable to the Arduino Mega, the Maple (ARM), or the upcoming ARM Arduinos?

digitalRead(), et al. functions are for both readability and portability. Efficiency is always compromised as you go higher in level with programming languages. If there weren't convenient advantages, we'd all be coding in assembler instead of Java, C++, Objective C, etc.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #136 on: February 06, 2012, 09:56:44 am »
Not really.  Bloated and slow code is bad, whether in an ISR or not

That's your opinion, right?

There's a school of though that unreadable code is bad.

Compare:

Code: [Select]
PORTB |= _BV(SOME_PIN);
to:

Code: [Select]
digitalWrite (10, HIGH);
In your case you have to make sure that you have PORTB right, and SOME_PIN right. Back to the datasheet, to see if pin 10 is on PORTA, PORTB or PORTC. And work out which bit SOME_PIN is.

And if I read your code I have to check you got it right.

But if I read:

Code: [Select]
digitalWrite (10, HIGH);
... I know someone is setting pin 10 on. No argument.

And as electrode says, the higher level code is portable.

Code: [Select]
Bloated and slow code is bad ...
Does it matter if I am turning on a light in fish tank? Do the fish notice if the light comes on a few microseconds later? Come on.

The same applies to the power supply. Does it *really* matter if, when you turn the knob, the voltage goes up a microsecond later using one method then when you turned the knob with another method? No, because your ability to react to cause-and-effect at a human level isn't that fast.

And as for the bloat, I agree in principle, but this sort of code is not going to use all of the 16Kb/32Kb of the flash memory whichever way you do it.

After watching Dave spending - how long? - debugging the SPI problems ... was it really worth it to save a few bytes, when he will have 12 Kb over anyway?
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #137 on: February 06, 2012, 10:06:27 am »
the better question is how are we going to make use of those free KB, :D
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #138 on: February 06, 2012, 10:08:03 am »
Some kind of Easter Egg, I think.

When you dial up 5.55 volts, it pumps out 100 555 amps and fries your chip to a cinder!

Muahahahah!
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #139 on: February 06, 2012, 10:18:00 am »
After watching Dave spending - how long? - debugging the SPI problems ... was it really worth it to save a few bytes, when he will have 12 Kb over anyway?

But Dave did use the oh so great Arduino calls, so your argument doesn't cut it.

Frankly said, you do the typical Arduino wanking. No, portability is not relevant here, because you ain't gona need it. Dave's MCU will not magically fall of the PCB and a replacement appear via quantum tunneling. And in fact, if you need portability, then you could do it with a few defines.

In real embedded systems programming of tiny devices, as opposite to Arduino wanking, everything done dynamically at runtime, that could be done statically at compile time, is bad. Because it significantly increases the risk when something in the system runs wild.

And while we are at it, your encoder reading via interrupts is also a no-no in real embedded programming, especially if they are hand-operated. Mechanical encoders bounce. This results in additional, superfluous interrupts. For every bounce interrupt the CPU has to shitcan what it is currently doing, save registers and execute the interrupt handler. That overhead is unpredictable, especially when the mechanics in the encoder gets weak over time, while on the other hand regularly sampling the encoder is predictable. I have previously posted in some of the power supply threads how to do encoder reading the right way. I have deleted that posting because of the Arduino wankers who anyhow won't get it. For the rest who want to learn, I encourage them to go out and check how to properly sample and decode an encoder in a predictable way.
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 electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #140 on: February 06, 2012, 10:24:10 am »
I have deleted that posting because of the Arduino wankers who anyhow won't get it.

Is that necessary? Most countries have a court system, where I'm sure that if Arduino really did come to life and murder your family, it would've been locked away by now.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #141 on: February 06, 2012, 10:30:04 am »
But Dave did use the oh so great Arduino calls, so your argument doesn't cut it.

No, he didn't. He didn't use the SPI.transfer as I suggested.

As for the rest of your post: "if you can't attack the argument, attack the man".
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #142 on: February 06, 2012, 10:31:35 am »
I have previously posted in some of the power supply threads how to do encoder reading the right way. I have deleted that posting because of the Arduino wankers who anyhow won't get it.

You deleted it because it doesn't work.

My post stands.
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #143 on: February 06, 2012, 10:34:27 am »
I have deleted that posting because of the Arduino wankers who anyhow won't get it.

I'm a little surprised the moderators allow this sort of talk. Enjoy your little world.
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4395
  • Country: au
  • Question Everything... Except This Statement
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #144 on: February 06, 2012, 10:36:15 am »
Please guys can we get this back on topic, not infighting about arduino, :/

Dave, what are the dimensions of the board?
 

Offline nessatse

  • Regular Contributor
  • *
  • Posts: 98
  • Country: za
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #145 on: February 06, 2012, 10:37:05 am »
Not really.  Bloated and slow code is bad, whether in an ISR or not

That's your opinion, right?
Yes, it is my opinion, but one which is generally shared by most software developers, except perhaps Arduino fanboys.

Quote
There's a school of though that unreadable code is bad.

Compare:

Code: [Select]
PORTB |= _BV(SOME_PIN);
to:

Code: [Select]
digitalWrite (10, HIGH);
In your case you have to make sure that you have PORTB right, and SOME_PIN right. Back to the datasheet, to see if pin 10 is on PORTA, PORTB or PORTC. And work out which bit SOME_PIN is.

And if I read your code I have to check you got it right.

But if I read:

Code: [Select]
digitalWrite (10, HIGH);
... I know someone is setting pin 10 on. No argument.


And pin 10 is?? Some arbitrary numbering invented by the Arduino folks?.  If anyone considers my example 'unreadable', then one has to wonder why they are doing embedded programming.  In any case, it is easily replaced with a macro, or even an inlined function.  Very readable, but orders of magnitude more efficient.   

Quote
Does it matter if I am turning on a light in fish tank? Do the fish notice if the light comes on a few microseconds later? Come on.

Probably not, if you are only doing simple 'flashing LED' type applications.   

I am often somewhat surprised when I see a lot of effort going into hardware design, choosing the right components, optimising component cost vs performance, etc., and then to be happy finishing it off with sloppy code 'because it's good enough'. (BTW, I am making a general comment here not referring to Dave's PSU)
 

Offline Nick Gammon

  • Contributor
  • Posts: 41
  • Country: au
    • Gammon Software Solutions
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #146 on: February 06, 2012, 10:50:37 am »
... except perhaps Arduino fanboys.... and then to be happy finishing it off with sloppy code

If insulting people is how this forum works, I will happily leave it right now.

My first processor had 256 bytes of memory, so I know something about writing tight code. But you don't really care about that do you?

If you really, truly, believe that you can prove how smart you are by calling people "wankers" and "fanboys" well, welcome to a small, closed world of people who don't mind being insulted.

/unsubscribe
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 30112
  • Country: au
    • EEVblog
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #147 on: February 06, 2012, 10:52:44 am »
Dave, what are the dimensions of the board?

About 120mm x 102mm or thereabouts.

Dave.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #148 on: February 06, 2012, 04:24:46 pm »
If insulting people is how this forum works, I will happily leave it right now.

My first processor had 256 bytes of memory, so I know something about writing tight code. But you don't really care about that do you?

If you really, truly, believe that you can prove how smart you are by calling people "wankers" and "fanboys" well, welcome to a small, closed world of people who don't mind being insulted.

Please ignore the idiots. I for one like your contributions. The idiotic posters around here are the reason so many forums have an iron fist moderation policy. Dave is more liberal than that, but it does mean we have to put up with a certain background noise level.
I'm not an EE--what am I doing here?
 

Offline nessatse

  • Regular Contributor
  • *
  • Posts: 98
  • Country: za
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #149 on: February 06, 2012, 06:03:46 pm »
Please ignore the idiots. I for one like your contributions. The idiotic posters around here are the reason so many forums have an iron fist moderation policy. Dave is more liberal than that, but it does mean we have to put up with a certain background noise level.
I won't speak for BAW, he is very capable of defending himself, but I think if anybody is going to be so offended by the mere mention of the word fanboy, then he'd probably be better off not using the Internet at all :)

As for the 'idiots' reference you made, perhaps you should rather present counter arguments to the relevant points of discussion, I don't believe either BAW's or my own comments can be considered idiotic.

In my case I am really just trying to say that we should hold software design to the same standards as hardware.  We go through a lot of effort minimising component counts, getting good PCB layouts etc, it seems a shame to finish it off with software that does not hold up to the same engineering standards.

I have no problems with the Arduino per se, in fact I have one permanently on my desk that I use for quickly testing proof of concepts, etc.  But would I use the Arduino libraries in production code?  Very unlikely, for reasons I have already mentioned.
 

Offline IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #150 on: February 06, 2012, 06:14:18 pm »
As for the 'idiots' reference you made, perhaps you should rather present counter arguments to the relevant points of discussion, I don't believe either BAW's or my own comments can be considered idiotic.

There's nothing at all wrong with debate about the merits of different designs. It is to be expected that people disagree. They always will.

My 'idiots' reference is purely about the tone of comments made by various posters. The number of times I read a post and go  ::)  is enormous.

Personally I just think to myself "what an idiot" and ignore the post. Your job as a poster is to invite me to read and enjoy what you write. If you as a poster choose to fill your comments with sarcasm and snide comments and insults then you don't make the sale and you have failed. Simple as that.

And of course you do need a bit of a thick skin to survive on the net. It's no place for wimps.
I'm not an EE--what am I doing here?
 

Offline olsenn

  • Frequent Contributor
  • **
  • Posts: 993
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #151 on: February 06, 2012, 06:23:36 pm »
What's with all the power supply crap on this forum... does it really require 8+ video blogs and dozens of forum topics? If you need a high quality PSU then you're best off just buying one professionally designed/built, and if you're just trying to get a start into product design don't you think maybe something a tad simpler, smaller, and not involving mains power would be a better first project?
 

Offline Zad

  • Super Contributor
  • ***
  • Posts: 1013
  • Country: gb
    • Digital Wizardry, Analogue Alchemy, Software Sorcery
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #152 on: February 06, 2012, 06:28:53 pm »
Well done Olsen on totally missing the point of the videos.

Can you point to where you think the mains voltage is? No, thought not. It uses a generic brick mains adaptor. No mains potential is involved in he project at any point.

If you don't like it, don't watch them. You haven't paid for them, so where is the problem?

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #153 on: February 06, 2012, 06:29:43 pm »
I think you missing the point.

It isn't always about the destination, but enjoying the journey getting there.

Rutger
 

Offline olsenn

  • Frequent Contributor
  • **
  • Posts: 993
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #154 on: February 06, 2012, 06:36:53 pm »
Didn't mean to offend anyone haha, I just (as you say) am missing the point. I think "the journey getting there" is always, or always should be, the most fun part of ANY electronics project (or any project really), I just don't see why so many people seem to choose this one, while no other projects (as far as I know --correct me if I'm wrong) are mentioned to any great detail here.

Knock yourselves out with all the PSU stuff though guys; I didn't mean to step on your project
 

Offline Bored@Work

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: 00
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #155 on: February 06, 2012, 06:40:36 pm »
I have previously posted in some of the power supply threads how to do encoder reading the right way. I have deleted that posting because of the Arduino wankers who anyhow won't get it.

You deleted it because it doesn't work.

My post stands.

My stuff works in the field. Your stuff just works in your imagination.
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 IanB

  • Super Contributor
  • ***
  • Posts: 9593
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #156 on: February 06, 2012, 06:46:40 pm »
Knock yourselves out with all the PSU stuff though guys; I didn't mean to step on your project

It's really Dave's project; we are only watching it.

But in reality look at how much ground Dave has been covering in both analog and digital design. The PSU aspect is really just a vehicle to carry all sorts of other interesting things that have wider application.
I'm not an EE--what am I doing here?
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 205
  • Country: us
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #157 on: February 06, 2012, 07:18:32 pm »
I agree with Ian, I have learned a ton of stuff from the videos that can be applied to any project.

Dave has really explained the whole design/prototyping and building of a electronics project with micro controller and software from beginning to end (which is still to come).

Sure there a tons of PSUs out there, but I don't know of one with a open source Arduino compatible Mirco!  I think because of this there is a lot of interrest in this project, it is not just another PSU, but one with 'intelligence'. 8)
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #158 on: February 06, 2012, 10:21:44 pm »
I just don't see why so many people seem to choose this one, while no other projects (as far as I know --correct me if I'm wrong) are mentioned to any great detail here.

Because it's exciting to see an electrical engineering design taken from start to finish. Other than small modules and bits and pieces, this and the uCurrent are the only two projects Dave has taken us through in such detail. It's definitely interesting, even for those of us that don't need the design in its current form (eg. I'd have 2 x 0-15V @ 1A supplies for series/parallel and omit the uCurrent and a bunch of the I/O and not bit-bang anything).
 

Offline electrode

  • Regular Contributor
  • *
  • Posts: 141
  • Country: au
Re: EEVblog #240 - Power Supply Design Part 8
« Reply #159 on: March 04, 2012, 12:05:42 pm »
They're not made Down Under...you sure you want to make that bet? ;)

Unfortunately the only cases that are made in Australia are the Jiffy Boxes, as used in the uCurrent.

The case is nothing special, nor secret, but now that everyone is keen to know, I'll tease a bit longer...  :P

Dave.

Has the case been revealed yet? Or can we still place our guesses? :D

Amp Hour Episode #73 somewhere around the 20 minute mark had a reference to a Hammond case. A screenshot of Dave's PCB from YouTube gives something that is 3.3 ATmega328s wide (~112mm) and slightly less deep (~100 odd mm).

So the case is one of the ones from here:
http://www.hammondmfg.com/scpg.htm

Possibly this one (if my dodgy measurements were 10% undersized):
http://www.hammondmfg.com/pdf/1598B.pdf

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf