Libraries I'm working on: timer, shifters, etc ...

I'm working on several libraries to help my project up. I'm sure I'm doing some silly things, but still, could be useful to others. ;-)

http://arduino.wusik.com

The one I loved most is MyTimer, which helped me out a lot producing a great MIDI PPQ Clock. (960 PPQ) 8-) The MyTimer Examples folder has an example of the MIDI PPQ Clock. :D

I'm still learning, so, please, let me know how to improve those libs and also any mistakes I have done. Just be nice. :)

Best Regards, WilliamK

Libraries I added to the link so far:

Encoder Encoder2 (lite) MyTimer (8 bits timer) C165 (16 Inputs with only 3 pins) C595 (16 Outputs with only 3 pins)

Hi William,

Just looking at the C595 code, it seems a very inefficient way to shift 16 bits out, loading an array then looping through the array. Is there any particular reason for not just shifting the bits in an int?

Also I think you could drop these

      digitalWrite(latchPin, LOW);
      [glow]digitalWrite(dataPin, LOW);[/glow]
      digitalWrite(clockPin, LOW);
      for (int i=15; i>=0; i--)  
      {
        digitalWrite(clockPin, LOW);
        if (Output[i]) digitalWrite(dataPin, HIGH); else digitalWrite(dataPin, LOW);
        digitalWrite(clockPin, HIGH);
        [glow]digitalWrite(dataPin, LOW);[/glow]
      }

Rob

He also could use the shiftOut() function, which does the same thing, just better and more efficient, but that would mean reusing working code instead of reinventing it in a worse manner. Sometimes one just need to let the kids play.

Korman

Hummm, I did use the shiftOut function and hated it. You have to keep in mind that I come from Windows C++ and Assembly programming, not MC programming. So I tend to like things in a certain way.

Now, Korman, to be honest, just bear with me and drop the attitude, you may be surprised with what life brings you. ;-)

In any event, this makes the code look easier to understand, while using shiftOut gives me headaches. :-[

In any event, I'm just a "kid", a 36 year old Father with near 25 years of programming background, so heck, what do "I" know? ::) I do stupid things, but that's how my stupid mind thinks, and yet, I produce code, it may look ugly to some, but to me, they mean something.

Anyway, this set of small libs I'm doing could be gold to some people that are like me, a bit nuts, I guess...

Wk

BTW: shiftOut also loops, it just loops the binary data, and not an array, so why its so different? :wink:

wiring_shift.c

void shiftOut(uint8_t dataPin, uint8_t clockPin, uint8_t bitOrder, uint8_t val)
{
      uint8_t i;

      for (i = 0; i < 8; i++)  {
            if (bitOrder == LSBFIRST)
                  digitalWrite(dataPin, !!(val & (1 << i)));
            else      
                  digitalWrite(dataPin, !!(val & (1 << (7 - i))));
                  
            digitalWrite(clockPin, HIGH);
            digitalWrite(clockPin, LOW);            
      }
}

Wk

Graynomad, thanks, I will check if those can be removed, I'm a bit tired right now, just watched Tron Legacy today with my Son. :o

Wk

It's true that shiftOut also loops, that's the nature of the problem and can't be avoided, the difference is that it doesn't force the caller to fill an array with up to 16 function calls first.

shiftOut does however I feel have some limitations that you could address eg,

a) it doesn't toggle the latch pin b) it doesn't handle different data types.

Can I suggest the following

You're already doing a) which is good and in fact how I think it should be done (given my next suggestions), maybe an optional parm to disable this function for cases with an indeterminant amount of data to be shifted, that way someone with X number of bytes can still toggle the latch pin themselves.

Ditch the array filling, take the parameter directly and shift the same way shiftOut does.

Write functions that handle different data types such as byte, int, long, *char, *byte[] etc so calls like

C595 ("hello world") C595 (1234567) C595 (&led_on_off_array)

etc would work and require no further work from the caller.

I think this would make your library a worthy extension of the existing shiftOut.


Rob

BTW: shiftOut also loops, it just loops the binary data, and not an array, so why its so different?

Lets compare the functions: Memory usage: Shiftout: 1 byte temporary, 0 permanent C595: 2 bytes temporary, 19 permanent. That's 1% of Memory on a Uno

Flexibility: Shiftout: 1 Byte is shiftet, no latch code so the function can be reused for any number of bytes without any change C595: 16 bits are shifted. For more or less register, the library needs to be changed. Impossible to shift different data lengths on different pins.

Comfort: Shiftout: No latch pin handling, easy data handling for packed bits. Data storage needs to be external. Easy to expand to int, long or strings, just call function repeatedly. Individual bit access needs handled externally with bitset/bitclear operations. C595: Latch pin handling, internal stoarage, good access to individual pins. Handling of packed data horrible.

So one can easily see, that your library is mostly failing and the little added benefit is overshadowed by all the problems. If the good features of your class were to be implemented properly in a class, you should store your data internally as bytes, have your accessor function convert positions into bits and let internally the shiftOut function handle the shifting. That way you'd have exactly the same interface for your class with all the benefit of proven standard code and without any of the shortcomings. This would be the solution expected from an experienced software development. If you need an example how to achieve it, just let me know and I'll a sample for you.

You have to keep in mind that I come from Windows C++ and Assembly programming, not MC programming. So I tend to like things in a certain way.

My experience with developing Windows dates already back some 10 years and I haven't kept too much with it recently, I was more busy with scripting and application languages to earn my keep. But I find it sad that the Windows environment forces people these days to produce crappy code, as you imply.

Korman