shiftout/shiftin on PortC

kennethm

New Member
Technical,

Would it be possible to modify the shiftout and shiftin commands to work on portc in the X1 and portA/B/C in the X2 variants in future revisions of the firmware? It is a pity that the commands are currently limited to the output/inputs pins.
 

hippy

Technical Support
Staff member
I recall the big step from X1 to X2 is planned to be that all commands will work on any pin (*) so that should be available.

(*) Unless fixed as input or output by underlying hardware, or specific pins are required for a particular command. HSERIN, HSPIOUT and HI2C's will likely need fixed pins as now but bit-banging should be possible on other pins.
 

MORA99

Senior Member
until then, cant you copy the code from the manual used on pre-x1 parts, and change it a little to work on portc?
 

kennethm

New Member
Need for speed

Its faster to use the "internal" implementation of shiftin/shiftout.

Right now my current picaxe project needs all the speed I can squeeze out of the 40X1 as I am multiplexing 25 rows of Leds with each row having 5 tri color LEDs using 2 chained 74HC595s per row.

I am currenty running at 20Mhz and I'm already pushing the PICAXE to its limits, so any additional bit banging routines written in basic in my display code will introduce even more flicker into the display. :)
 
Last edited:

inglewoodpete

Senior Member
Wow! That's quite an investment in tricolor LEDs!!

Have you considered a demultiplexor chip to drive the 25 rows of LEDs? The 74LS138 or similar comes to mind. This would reduce your dependance on the limited number of dedicated output pins.
 

kennethm

New Member
Indeed it is, but one can find very cheap Tricolour LEDS on Ebay (although of questionable quality).

I am also using 74HC595 shift registers to control the rows so I only need 3 dedicated pins ;).

However your suggestion requires some serious looking into as i am bit banging 16 bits at a time for row control, whilst a cursory glance at the spec sheet for the 74LS138 indicates 3 bits can control 8 lines rather than using 8 bits for 8 lines, which means less processing, and hence i might be able to cut down on the slight flicker that is apparent in my display.

Perhaps connecting a shift register to the demultiplexer control pins will avoid using if statments inside my drawing loop and a simple spiout will suffice, or i can use the let pins = b0 command

Thanks for the pointer.
 
Last edited:
Top