[sdiy] OBJECT ORIENTED C in synth programming

[dan snazelle]

On Apr 8, 2011, at 3:26 PM, Scott Gravenhorst wrote:

> dan snazelle <subjectivity at hotmail.com> wrote:
>> Ok
>> 
>> While we are on the topic of Learning about TYPEDEF's and 
>> STRUCTURES, can anyone recommend a book that covers C in relation 
>> to AVRs well? 
>> 
>> The reason I ask is that the C books I have, so often fall back 
>> on using PRINT as their example. 
>> 
>> It would be great to have a book on C that related things to the 
>> world of ADCs and DACS and TIMERS. 
> 
> Welcome to the world of digital design.
> 
> While printf et al works great with a screen, you are correct that such
> an expression is useless where there is no screen.
> 
> I've not worked with an AVR, but I have worked with PICs, other
> microprocessors and FPGA development boards.  Such things will often
> have LEDs that can be controlled by the micro or other device. 
> Sometimes that's all you get and sometimes not even that.  
> 
> In my work, I've managed to survive with only a few LEDs (8 if I'm
> lucky), an oscope and the DAC.  I can route information to the LEDs -
> that's pretty easy.  But sometimes I need different information.  I can
> scope the DAC to see if anything is happening at all (perhaps way to
> slow to hear or maybe using so few bits that I can't hear it).
> 
> When having trouble, I will route specific information to the LEDs in
> such a way that the LEDs aren't flashing at 10 kHz but rather are stead
> state so I can see and "read" them.  This can be somewhat tedious as I
> move through the code, but the points where I put code to write to LEDs
> are intended to indicate - "This is definately working" or "this is
> definately not working" and work from that.
> 
> You need to be as much of an engineer about designing temporary
> diagnostic features (such as using LEDs) as you are about designing
> your synth, special effect, noisemaker or whatever.
> 
> If your device has a UART, then that can be used to spray out numbers
> or whatever.  Connecting to a PC COM port with a terminal program
> running allows you to see them.
> 
> Bottom line is that you need to be clever regarding what you have at
> your disposal and learn to code with those attributes.
> 
> It is wise to do some hello-world stuff with those things so that you
> can apply them with confidence in a malfunctioning design.
> 
> -- ScottG
> ________________________________________________________________________
> -- Scott Gravenhorst
> -- FPGA MIDI Synthesizer Information: home1.gte.net/res0658s/FPGA_synth/
> -- FatMan: home1.gte.net/res0658s/fatman/
> -- NonFatMan: home1.gte.net/res0658s/electronics/
> -- When the going gets tough, the tough use the command line.
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
> 



THANKS FOR SOME GREAT ADVICE

This gives me some hints for how to DEBUG which is something I have been messing with a bit.

I am finding that right now, one of the big headaches when trying to understand code which is complex, is to figure out which functions or variables are doing what.
and yes, I have figured out how to make a variable spit out via the UART


i think people trying to make synths or noisemakers have a hard time from the start as so few texts spend any time on it!

I will try your led advice

thanks