Memory is not the issue, speed is. Without missing any incoming serial data, I want the loop to run as many times per second as possible, so that if the audio mode is in use, no audio events will be missed. That is to say, If the user has "bass" selected for response, I don't want the code to miss an incoming peak corresponding to "bass" resulting in a delayed or missing "pulse" to the music. The simple setting for just choosing a color to display, won't have this problem, but the "color organ" functionality is time sensitive in relation to whatever happens to be playing at the moment.
and can you please unindent your { and } lines one level?
No, I'm so used to HTML that this is the structure I am used to seeing, and makes it easier for me to read my own code... Even my java looks like that...
Oh, and you're going to stop using String, aren't you?
I don't have to take serial data as String?
Here it would be prudent to do a bounds check before appending to the array, just in case.
From here on out, it is obvious to me that you are a much more advanced C++ programmer than myself. I have no idea what a bounds check is...
Also, wouldn't it be best to reset serialIn to zero and re-terminate the buffer every time you get a StartOfPacket character?
Yes, yes it would. Thank you!
I'd parse each message directly into an int array instead of building arrays of char * and cut out all that horribly repetitive chanxsort() stuff. If you parse and validate the channel field first, you can chuck the remaining fields directly into the relevant chanx array. I'd much prefer to see those stored in an array of arrays. In general, when you find yourself appending numbers to variable names, you should be looking for ways to put them in an array and consolidate the processing into common code.
Greek.
In any case, do you really need map() here? All you need is rojo = 4095 - rojo.
YES! THANK YOU! I never thought of doing it that way in all the nights of lying in bed, staring at the ceiling, coding in my head and wondering about another way to invert those values...
This code above that seems to be defining fading implies some code to detect an end time which will not deal correctly with timer overflow. Maybe you don't expect this to be kept powered up for the month or so it will take for that to happen, and I don't even know whether tlc_addFade() is your code, but make a mental note that this is not a good way to specify a time for things that are intended to happen in the future.
The original purpose of this lighting controller was a car underglow controller, it has grown to much more than that now, and so would need to be reset because of overflow when used indoors. Most of my target market is kids with civics, and they won't idle for a month... So battery or gas, the boards will get reset. Tlc_addFade is a part of the TLC5940 Library on google code and is the recommended method of using a TLC5940 with an arduino. Maybe something else you guys can help with. I passed DRC with my boards I sent to Seeedstudio's fusion PCB service, but after 10 days the sent me today, "Sorry, the lines are too clutter, could you please correct it and resend to pcb@seeedstudio.com ." They included the top layers of my board as an image.