[CCC DEV] The transterpreter and die(..)

[Omer Kilic]

Michael Pirrone-Brusse wrote the following on/at 14/07/2010 22:02:
>     As an example, one place I keep catching myself up on -- and were I 
> figure a lot of little mistakes will be coming from -- are places were 
> I've set up symbolic constants for interfacing with, let's say, the 
> analog pins on the arduino. To get ADC working the Right Way on the 4th 
> analog pin, one is supposed to call  `adc (A4, some, stuff?)`, and what 
> I keep doing is calling `adc (4, some, stuff?)`. Since A4 != 4, bad 
> things happen in the guts of the analog to digital conversion, and it 
> actually looks like error is in the adc code I've already written and 
> tested, rather than the program I'm writing to show it off.
> 
>     Now, I am planning on implementing a pretty simple double-checking 
> pattern to take care of that problem, but if someone who wasn't me ran 
> into that little syntax hiccup, it would be the most nice if they saw 
> "Sorry, pin 4 isn't an analog pin. Did you mean pin A4?"


Hmm, it would be nice to see useful error messages for most cases but as 
you have mentioned in your first message if the UART is connected to 
another device then BadThings(tm) might happen  :)

I suppose you could check for a debug variable that you can set in your 
sources if you want those nice error messages (and you are willing to 
sacrifice your UART for that purpose*) and transmit them accordingly 
using a 'wrapper' PROC that initialises the UART if it is not already 
running but this is an additional level of complexity and definitely not 
an elegant solution!


Cheers,
Omer.


* With an Arduino Mega, you have the luxury of having multiple UARTs at 
your disposal so you can think about having a dedicated one as a 
'console' for debug/error messages.


> On Wed, Jul 14, 2010 at 4:30 PM, Omer Kilic <omer at concurrency.cc> wrote:
> 
> 
>     Hi Drew,
> 
>     Michael Pirrone-Brusse wrote the following on/at 14/07/2010 21:23:
> 
>            My gut reaction - and a solution Matt seemed to think of and
>         dismiss faster than I did - was using serial to print those
>         message. Obvious problem is if serial hasn't been setup, nothing
>         gets printed. Even worse is if a device that isn't your computer
>         is hooked up to the serial port, and all of a sudden it gets
>         clobbered by a fun little string while you're trying to figure
>         out why the lights stopped blinking...
> 
>            If anyone has any better thoughts on getting them die
>         messages printed, I'd greatly appreciate a shout,
> 
> 
>     Not sure how useful this will be but a very common solution to this
>     in the embedded world is to use a single output pin, which can be
>     hooked up to an LED (i.e: Pin 13), to 'signal' messages in the form
>     of blinks.
> 
>     It's not as verbose as a serial output, but as long as you define a
>     few distinct 'signals' you should be able to debug things easily.
> 
> 
>     HTH,
>     Omer.
> 
>