Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 45

Thread: A small twist to an old Classic ...

  1. #11
    Join Date
    Nov 2007
    Location
    Melbourne Australia
    Posts
    552
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Making stuff with what we have lying around is the essence of DIY. A lot of innovation happens that way....

    As far as I know, the first mention of microcontroller support for ledtriks was on a PIC. See here for discussions on the original 'PICtricks'. Some of holtm's code might be a good starting point?

    Tim

  2. #12
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Quote Originally Posted by TimW View Post
    Making stuff with what we have lying around is the essence of DIY. A lot of innovation happens that way....

    As far as I know, the first mention of microcontroller support for ledtriks was on a PIC. See here for discussions on the original 'PICtricks'. Some of holtm's code might be a good starting point?

    Tim
    Very cool.. thank for the link Tim.

    [Edit] Hahaha... there I was thinking I was doing something a little 'novel'. ;)
    Last edited by LabRat; 07-12-2009 at 09:16 AM. Reason: Followed the link.

  3. #13
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Quote Originally Posted by scorpia View Post
    Being someone with pic tools and not avr tool i would be interested in this.

    but yes i would look at respinning it to a bigger pic. either 16f628a or 16f722 or something in a higher range either 18f or 24f series.

    either way i would be interested in seeing the code to check to see if it works and to play.

    good to see people playing with things. thats what this site is all about.

    ps you can allways order pics from microchipdirect. if anyone os going to have stock its the maker

    Peter
    I've been thinking about this quite a bit (insomnia ya know). As it is the board with the 16F688 should be able to do everything the Tricks-C does, and have room to spare (additional wipes & transitions??). Furthermore, we should be able to flash one (or two) frames into the device (something to consider adding to the protocol).

    What are you hoping to gain by going with a larger part? Control for multiple panels from a single board? Perhaps do-able, but then we risk increasing the cost/complexity to the point of not making this a reasonable solution for the "diy@home" types (which was my goal, and may not be everyone's).

    The only thing I see this board not having compared to the TRICKS-C, is the "status LED". This is due to having the crystal oscillator added to the board. I see from HOLTM's attempts previously, he managed to get the PIC to LEDTRICKS operational. If we/I can get this talking to the PC without the need of the external OSCILLATOR, then I can buy back those pins, and add in the status LED.

    Of course.. I need to make a LEDTRICKS first.. and the panel.. and solder all those LEDs... (how many days until Xmas??)

    [Post Thought] This board has enough RAM for TWO frames - either buffer swapping for faster/cleaner transitions, or it should be possible to drive two LEDTRICKS at once. (Unless my blurry eyed Sunday morning thinking has missed something)
    Last edited by LabRat; 07-12-2009 at 09:42 AM. Reason: Thought of something else.

  4. #14
    Join Date
    Dec 2007
    Location
    Melbourne , Australia
    Posts
    896
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    yes to me the main reason was the extra i/o.

    Also being that the 16f722 can be got cheaper than the 16f688 and can be run on either its internal 16mhz osc or run from memory upto 32Mhz external crystal.

    basicly its the old addage bigger must be better :p

    Also something i know tim has been playing with that might require some more grunt is the ability to add dimming to the ledtriks. this makes the whole mcu controller board worth it to me.

    Plus i like playing with code. so why not
    ps liking playing around with the code and being good at it are 2 diff things

    the 18f and 24f range of pics would be a "cause i can" reason and nothing more. Allthough a usb controlled ledboard could be cool.

    Peter
    Last edited by scorpia; 07-12-2009 at 05:52 PM.

  5. #15
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Quote Originally Posted by scorpia View Post
    the 18f and 24f range of pics would be a "cause i can" reason and nothing more. Allthough a usb controlled ledboard could be cool.
    Oddly enough (when it comes to me.. it usually *IS* odd), I considered the 18F series for USB, but dismissed it, due to the extended range of the RS485. Hooking up to the USB stack would be fairly painless (heck, take the basic UBW board, and just re-direct all those I/O's to an RJ45 ). This even allows for a boot loader, so you can compile new code and load it over the USB. Now *that*'s an interesting twist. Software upgrades to the PIX-C. ;)

    However, that would mean new SW on the PC side as well. If I manage to adhere to the existing serial protocol, I should be able to leverage the existing PC side of things. No changes required there.

    Anyhow.. current status, I've fixed several issue with the version I had posted before (amongst other things, the pinout to the ledtricks was COMPLETELY wrong), and whipped out a version 1.4. Etched up my proto-type (I think it might actually have been faster than trying to wire up the breadboard), and dropped the 16F688 into play. The "I've got power Blue LED" is operational, and the PicKit clone recognizes the chip as being out "there". I haven't populated the serial portion of the board yet, figuring that can wait until I had the proof that the PIC was setup correctly.

    Now to see if I can compile the "Test" code from years gone by, and stuff that into the device.

    It feels good to move from "armchair observer" to "actively doing something".

  6. #16
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Just discovered that I will required an *special* adapter/dongle if I want to do in circuit debugging. (That's a bit of an eye-opener.. and here I am without even a gpio to an LED... trying to tell if this code is doing anything).

    Ok.. time to hit the sack and thing about the implications here.

    On the bright side, I built the original pictricks.asm code, and loaded it. No idea if it *DID* anything.. but I loaded it. ;)

  7. #17
    Join Date
    Dec 2007
    Location
    Melbourne , Australia
    Posts
    896
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Quote Originally Posted by LabRat View Post
    Oddly enough (when it comes to me.. it usually *IS* odd), I considered the 18F series for USB, but dismissed it, due to the extended range of the RS485. Hooking up to the USB stack would be fairly painless (heck, take the basic UBW board, and just re-direct all those I/O's to an RJ45 ). This even allows for a boot loader, so you can compile new code and load it over the USB. Now *that*'s an interesting twist. Software upgrades to the PIX-C. ;)

    However, that would mean new SW on the PC side as well. If I manage to adhere to the existing serial protocol, I should be able to leverage the existing PC side of things. No changes required there.
    i dont see why it would require new software. there is a usb boot load + software. i think the ubw uses it. and as the usb port can be made to look like a serial port the software doesnt need to change on the pc side.

  8. #18
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Had a thought that my progress may be better suited to a "blog" than a forum, so I'm moving my updates/postings to that venue.

    LabRat's Blog Attempts

  9. #19
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    Just letting all of those saying to use the "other bigger PIC" know, that it's time to say "we told you so". I discovered that my current board is flawed when I read the following snippet from manual.

    Code:
    Note: When the SPEN bit is set the TX/CK I/O
    pin is automatically configured as an
    output, regardless of the state of the
    corresponding TRIS bit and whether or not
    the EUSART transmitter is enabled. The
    PORT latch is disconnected from the
    output driver so it is not possible to use the
    TX/CK pin as a general purpose output.
    I don't have any spare pins in the current design, and I had wanted to re-task the TX/CK pin as a GPIO to the RJ45. As I can't do that, I will have to look at re spinning with a larger PIC, or dropping the external oscillator, and buying back two pins.

    Oh well.. in the worst case, I convert *this* board over to a version of the JEC PIXEL, that can drive 7 channels of downstream DC SSR's.
    Last edited by LabRat; 07-20-2009 at 11:32 AM. Reason: I can't count...

  10. #20
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: A small twist to an old Classic ...

    I was progressing very well until last night when I started on the "Roll Left" command. No matter what I tried, the data in the buffer just isn't correct, so I've been chasing it down all evening. There is definitely something *amiss* here (and I'm not 100% certain it's my code).

    So here's a call for PIC guru's for help to identify why the rrf command, is mis-behaving.

    Here's the relevant info (I hope):
    • BANK0 contains the "Top 1/2" of the frame
    • BANK1 contains the "Bottom 1/2"
    • In the 16 bytes of "common" data, exist the shared rxBuffer, which includes:bitShifter (countdown from 8 to zero), column_count (6 to 0), and row_count (8 to 0). Input1&Input2 - the new bits for the roll, and Voldemort the "BYTE that shall not be named" which simply contains a flag that indicates whether I'm processing the top or bottom portion of the frame (need to know when to exit the loop).


    As we are shifting Left, I'm processing the buffer in reverse, and "C"arrying in the new bit from the bitShift register. (lsb first)

    Code:
    cmdLeft
    	BANKISEL Fr0Row0		
    		movlw	Fr0End
    		movwf	FSR				; Point in the BANK 
    		movf	input2,W		; Get the appropriate byte from the payload
    		movwf	bitShifter		; Everything is where we want it.
    		clrf	voldemort		; Indicate 1st time throught this loop
    
    cml_forEachBank 
    		movlw 	d'8'			; 8 rows per frame
    		movwf	row_count		; 
    cml_forEachRow
    		movlw	d'6'			; 6 bytes per row
    		movwf	column_count	;
    		rrf		bitShifter,F	; Put the "next" lowest bit into 'C'
    cml_forEachColumn
    		decf	FSR,F			; Decrement to the next BYTE in the stream
    		rrf		INDF,F			; Rotate the payload NOTE: inverse rotate due to msb output ordering
    		decfsz	column_count	; Count down all 6 bytes in the ROW
    		goto 	cml_forEachColumn
    
    		decfsz	row_count
    		goto 	cml_forEachRow
    
    		btfsc	voldemort,1		; Was this the second frame?
    		goto	doneCmd			; Yes - we are done
    		
    	BANKISEL Fr1Row0
    		movlw	Fr1End
    		movwf	FSR
    		movf	input1,W
    		movwf	bitShifter
    		bsf		voldemort,1		; Flag that we are executing the SECOND 1/2 of the shiftloop
    		goto	cml_forEachBank
    Ok that's the setup.. here's the bizarre problem. The rrf INDF command, appears to be shifting 3 times, instead of 1. (Yeah.. I know it sounds unreal.. ).

    I tweaked the code to exit after processing the first memory location only.
    It contained 0x80 at the start, and after the shift... I'm left with 0x10??

    I've tried all sorts of tests, to narrow this down. I've copied the value from the INDF into W, output it into a new location (still 0x80), did an rrf of W and spat that out into yet ANOTHER location.. 0x10!!
    It gets worse... if I double up the RRF INDF, so that I perform the operation twice.. the output is... 0x10?!?

    (I'm not making this up)

    To make things even more confusing.. if I add some "wait" time at the very start of the routine.. 3+ms (of thereabouts). The output will be... 0x20 .
    If I go larger.. around 4-5 ms, then I get the expected values.

    Anyone have any ideas on where I could look next? (For now I've left the wait states in there.. but that just seems oh so wrong.)

    Thanks for any feedback.

    Oh.. the Roll Right command which uses a rlf INDF works without issue.
    Last edited by LabRat; 07-29-2009 at 08:36 AM. Reason: I kan spell rael good.

Page 2 of 5 FirstFirst 1234 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •