
Gareeeesh
Members-
Content Count
48 -
Joined
-
Last visited
About Gareeeesh
-
Rank
Advanced Member
Profile Information
-
Gender
Not Telling
-
I had to switch to the F5438A because of the RAM issue and was able to calibrate the clock at 20MHz - although there was some flickering, it suited the project brief well enough. Thanks for your replies guys!
- 5 replies
-
- msp430g2553
- tlc5940
-
(and 6 more)
Tagged with:
-
@Roadrunner & Tripwire - Thanks for all your help guys!. Mission accomplished! Here's another terrible video of my results!
-
I'm using the H/W UART on the MSP430F5438 board which can do greater than 9600 baud, with a USB-to-Serial converter cable connected to an RS-232 shifter board. The UART RX at 115200 baud is working because previous to this, I created a program in which I could control each pixel with buttons on my keyboard through HyperTerminal, . Also, my code is weird? Right, I see. It is essentially the same code. I'll compare the results with the previous and see if it makes a difference. As usual Roadrunner - the most helpful dude ever!
-
Okay, thanks for clearing that up. I had a look through the ASCII character table and there are some extended characters such as ? (ASCII value 189) which could maybe be used? Using the command line is only for testing purposes to see if the program was mapping the RX'd bytes to the correct RGB component of the correct pixel. So for now if I am using the command line I'll only put one character in the x="?" so that only one byte is transmitted. I wanted to be able to send a whole byte array using that program from here, that is why I wanted to use the gimp (.c) source file to use as a byte
-
Sorry everyone for posting several of the same post. My connection froze and i clicked refresh a bunch of times. I didn't realise I'd posted anything until I went back to the General section of the forum and saw them. That's it fixed now, so just ignore this.
-
Hello! I know I've been posting loads of problems which you have all been very helpful with and I appreciate it. I'm at the last stage in my project where I have to send an image as a byte array (values from 0-255) via serial communication, use H/W UART to receive bytes and map them onto my RGB LED display to create the image. I've configured the UART at 115200 BAUD, clock at 18MHz, I'm using the UCA0 ISR routine to map the received bytes into a 3D array "image[8][8][3]" where the 1st, 2nd, and 3rd terms are row, column, RGB component, respectively. I am seeing results on the display whe
-
@@tripwire Does this mean that the green component would be at [ ( 7+ ( 2 * gimp_image_width )) *2] ? and the blue at [ ( 7+ ( 2 * gimp_image_width )) *1]
-
@roadrunner84: I just decided to leave the h/w SPI for the shift register because the shiftOut function works absolutely fine as it is. I didnt realise how difficult it would be to map the G2553 code over to the F5438A device! That's me got my previous code working now though. I looked back at this to try and continue with the final part of the project and I'm still not quite sure about hwo to extract the R,G and B values from the long string. Say I wanted the data for pixel(7,2). Then the equation above would be: [ (7 + (2 * 16) ) * 3 ] = 117? But how would you find the RGB values from
-
@@roadrunner84, I thought I was on the right track. Anyways, I made the adjustments that you suggested but to no avail. For some reason the correct columns are lighting up, as well as random columns popping up but at different brightness levels. I'm thinking this could be because of a timing issue? I might just revert back to the shiftOut function that I've been using, since its so easy to do. void SPI_shift(u_short data) /* If you're intending to write 16 bits of information, go for a short instead of a long */ { u_char low_byte, high_byte; /* let's declare the variables to store the
-
@@roadrunner84, that's me got the MSP430F5438 board! It has a ridiculous number of pins compared to the G2553. Anyways, as usual I'm running into problems It'll probably be a trivial task for you. I thought since I now have enough pins to use H/W SPI for the shift register (drives the columns), i'd try and give it a go. But I'm not sure I'm doing it right. Since the TXBuffer is only 8-bits in length, would I need to split the desired output "data" into two, like upper byte and lower byte? Something like this: // In main hsv2rgb(......); SPI_shift(0x8001); // so the first and last colum
-
Yeah that was the initial plan, but I've just been informed that I may get my hands on the F5438 board which has 16kB of RAM which would solve all of my problems. Could've done with that about a year ago... :-P Thanks for your help though cde!
-
That does sound pretty complicated :? ..... I'm not sure I'm well-versed enough in MSP430 C programming to be able to attempt something like that. I just wanted to check if something that would be possible . The "splitting the display into two" idea might be a good shout, again I'll try my best to make something work :-P Thanks again, you the man!
-
@@roadrunner84 - I've not managed to find time to fix my code yet, but I was just thinking there: "I've got another Launchpad, with another G2553 device. Could I somehow utilise the RAM on that device as well?" Cos that would be excellent!