Go Down

Topic: Higher Performance IO (Read 8879 times) previous topic - next topic

chippey

Hey Martin,
What header file do I need to include to use turnOffPWM()?
I'm including pins_arduino.h and binary.h, and shiftOutHPPM almost compiles, but I'm still getting this set of errors:
Code: [Select]
fastSB.c: In function 'shiftOutHPPM':
fastSB.c:25: warning: cast to pointer from integer of different size
fastSB.c:26: warning: cast to pointer from integer of different size
fastSB.c:29: warning: implicit declaration of function 'turnOffPWM'
/Applications/arduino-0011/hardware/libraries/ShiftBrite/fastSB.o: In function `shiftOutHPPM':

/Applications/arduino-0011/hardware/libraries/ShiftBrite/fastSB.c:29: undefined reference to `turnOffPWM'

/Applications/arduino-0011/hardware/libraries/ShiftBrite/fastSB.c:30: undefined reference to `turnOffPWM'

Couldn't determine program size: hardware/tools/avr/bin/avr-size: '/tmp/build52562.tmp/shiftbright6.hex': No such file



MartinFick

I don't have the environment in front of me now, so I can't verify anything, but checkout post#4, I think that the bottom code section explains what you need.

chippey

Heh, I feel silly for missing that.  Now it works!  Sketch is now 3168 bytes as opposed to ~11k.

Frisken

I tried to use the 74HC595 for sending data to a GLCD but it was way to slow when using the digitalWrite command. When trying it with mems test program I got less then 1 FPS. Then I changed the library to use the macro created by MartinFick in this thread and it got up to 11 FPS right away. I also use the WriteFastLow and WriteFastHigh macros that mem created in the ks0108 library for setting the latchPin.
Nice work both of you!! It works like magic.
I thought that getting the GLCD up and running would take a long time and be quite troublesome, but with your code it was very easy.
Thank you!!

mem

Frisken, good to hear that you have the Graphics LCD going with the 74HC595

I am working on a new release of the GLCD library, why not post the changes you made for the74HC595 in the GLCD thread (or start a new one). Sounds like this would be a useful capability to include in the library if you don't mind sharing the code

Frisken

mem, I post the answer in the GLCD thred.

Frisken

MartinFick,
I am using your shiftOutByte macro and it works great. But I wonder if you have a shiftInByte macro lying around some ware??

Don Kinzer

Quote
I wonder if you have a shiftInByte macro lying around some ware?

Here is some code that I put together for a shift in macro.  Note that there is one additional parameter (compared to shiftOut) which tells the macro whether to read the data before the leading edge of the clock or after the leading edge of the clock.  Which you should use depends on the external device that you're dealing with.

Code: [Select]
#define PRECLOCK 0  // sample data before clock
#define POSTCLOCK 1  sample data after clock

#define bitRead(pin) ({ \
 uint8_t cnt = ((pin) < 8) ? (pin) : ((pin) - 8); \
 uint8_t val = ((uint16_t)(((pin) < 8) ? PIND : PINB) >> cnt) & 0x01; \
 val; \
})

#define shiftInBit(dataPin, clockPin, sampleWhen, bit) ({ \
 uint8_t val; \
 if ((sampleWhen) == PRECLOCK) \
   val = bitRead(dataPin); \
 bitWrite(clockPin, HIGH); \
 if ((sampleWhen) != PRECLOCK) \
   val = bitRead(dataPin); \
 bitWrite(clockPin, LOW); \
 val << (bit); \
})

#define shiftInByte(dataPin, clockPin, sampleWhen, bitOrder) ({ \
 uint8_t val = 0; \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?0:7)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?1:6)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?2:5)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?3:4)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?4:3)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?5:2)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?6:1)); \
 val |= shiftInBit(dataPin, clockPin, sampleWhen, ((bitOrder) == LSBFIRST ?7:0)); \
 val; \
})

One problem with this macro, and shiftOutByte for that matter, is that the clock polarity if fixed.  By this I mean that the leading edge of the clock pulse is always a low-to-high transition.  It would be better if both macros simply toggled the clock output.  That would allow you to set the polarity of the clock signal by setting the initial state of the clock line.  The shiftOut() function has the same shortcoming.

The newer AVR chips support toggling an output pin by writing a 1 to the corresponding bit of the PINx register.  (The mega8 does not have this feature but the mega168 and mega328P both do.)  A macro like the one below could be used to toggle an output pin on the AVR devices that support this feature.
Code: [Select]
#define togpin(pin) sbi((pin)<8 ? PIND:PINB, (pin) - ((pin)<8 ? 0:8))
Don

ZBasic Microcontrollers
http://www.zbasic.net

Frisken

Thankyou Don!

I will try this macro when I got the time.

paulb

Thanks to all who have worked on new shiftout function, it's great to see this happening.

I'd like to put in a request for a variable frame size, if and when the right function gets packaged up and included in core. I programmed an LED sign with the TI PWM chip TLC5940 and it had a frame size of 14 bits I believe.

There are a couple of other arcane issues such as whether the data line gets left high or low and the relationship of clock to data. I didn't really study the protocols that much, just tried the options included in SBC docs until I found ones that worked. There seemed to be three or four flavors of the protocol I recall.

What about the native SPI hardware? Isn't this the real path to speed, plus unloading the chip for other duties?

There's 6 cents worth.



Go Up