EEVblog #240 - Power Supply Design Part 8

[Rutger]

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

[electrode]

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.

[EEVblog]

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.

[Rutger]

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

[Nick Gammon]

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.

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.

[nessatse]

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.

[Rerouter]

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,

[Nick Gammon]

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.

[Nick Gammon]

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.

[nessatse]

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.

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

Trickier than what??

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

[electrode]

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.

[Nick Gammon]

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?

[Rerouter]

the better question is how are we going to make use of those free KB,

[Nick Gammon]

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!

[Bored@Work]

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.

[electrode]

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.

[Nick Gammon]

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".

[Nick Gammon]

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.

[Nick Gammon]

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.

[Rerouter]

Please guys can we get this back on topic, not infighting about arduino, :/

Dave, what are the dimensions of the board?

[nessatse]

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.

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.   

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)

[Nick Gammon]

... 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

[EEVblog]

Dave, what are the dimensions of the board?

About 120mm x 102mm or thereabouts.

Dave.

[IanB]

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.

[nessatse]

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.