Show Posts
Pages: 1 ... 413 414 [415]
6211  Forum 2005-2010 (read only) / Uno Punto Zero / Re: internal pullup resistors & digitalWrite on: March 21, 2010, 02:35:45 am
The benefit of pinMode(9,INPUT_PULLUP) is that its more obvious what the code does than  pinMode(9, INPUT, true);
If the user was not familiar with pulls-ups than context sensitive help on  INPUT_PULLUP would get him relevant information.

Or, if you prefer the three argument version, you could define PULLUP as true and use:  pinMode(9, INPUT, PULLUP)
6212  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Developer Request: Sketch Require Hardware on: February 16, 2010, 10:43:38 am
BenF, as Eberhard pointed out in post #3, knowing the processor may not give enough information to determine the capabilities of the board.

But even knowing the board may not be sufficient for a sketch to ensure that all needed resources are available as there is currently no way of determining if and when resources like pins and timers are being used by a library.  This is an issue being looked at by the developers but its not an easy one to solve.
6213  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Areas for discussion. on: April 03, 2010, 01:33:49 pm
Quote
mem - how did you get your example to be in colour?
to get the syntax coloring, from the ide edit menu, select 'copy for forum'

Code:
Serial.print("x ");
Serial.print(x);
Serial.print(" y ");
Serial.print(y);
Serial.print(" z ");
Serial.println(z);  
I think beginners find that ungainly.
There has got to be a better way that does not look scary.
6214  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Areas for discussion. on: April 03, 2010, 12:06:22 pm
Quote
Just to emphasise the point, who can see the error in the operator overloading example?

Code:
Serial << "GPS unit #" << gpsno << " reports lat/long of " << lat << "/" << long;

The IDE highlights keywords so the bug is easy to spot:
Quote
#include <Streaming.h>

int gpsno, lat;

void setup()
{
  Serial.begin(9600);
  Serial << "GPS unit #" << gpsno << " reports lat/long of " << lat << "/" << long;

}

void loop()
{}


Quote
I would observe that this has been referenced several times in this thread, and presumably read, and no one has raised this concern. I think it suggests that it is not easy to understand.

As I mentioned in my earlier post, I do think that the C++ syntax looks a little scary to beginers. I am not clear what concern you feel has not been raised?

I hope this post doesn't come across as argumentative, I suspect we are in agreement that a simpler way to format output would be most welcome.
6215  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Areas for discussion. on: April 03, 2010, 12:25:10 am
That line defines the output capability but it does not need to be visible within the sketch. there is a version that hides that line  in a library: http://arduiniana.org/libraries/streaming/

the downloid is here: http://arduiniana.org/Streaming/Streaming4.zip

I have just modifed the playground article to include the link to Mikal's less scary library version.
6216  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Areas for discussion. on: April 02, 2010, 11:06:13 pm
I like gbulmer's suggested enhancements to serial monitor, and I would add one more – an option to send  '\r' at the end of the string when the Send button is pressed to make it easier for a sketch to determine the end of an input string.

 think that tabular output is needed as much with LCD as with Serial, so would want to see something along the lines of roypardi's suggestion that includes the ability to control the padding between fields so they can be lined up.

The ability to print multiple fields can be done now using a method published by Mikal Hart here: http://www.arduino.cc/playground/Main/StreamingOutput
Its syntax is a C++ standard but I wonder if it looks a little scary to non-technical people?

so for me, the higher priority is something simple that can print a line at a time that includes control over the width of a field so printed values can line up on serial or lcd (or ethernet).  
6217  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Areas for discussion. on: April 02, 2010, 04:16:30 am
I agree with gbulmer that providing the ability to do a tabular layout would be very desirable, although I would vote for implementing this in the print statement. This would enable  LCD, Ethernet and any other classes that inherit  print capability to also align columns of values using the same code.  So my vote is to add some simple formatting capability to print that controlled the width and padding of  a printed value would enable a sketch to align columns on any output device that supported print.

That's not to say that serial monitor would not benefit from enhancements, particularly the support of'\r' so that output can be kept to the same line.
But if Arduino core development resources are limited, then more sophisticated Serial terminal functionality can be obtained by using one of the many open source Serial utilities that can be downloaded for free.
6218  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Variable types in the documentation? on: March 21, 2010, 02:56:51 am
The down side of including the type in the reference is that the type is usually not needed and many beginners would find its inclusion intimidating.

In my opinion, the friendlier solution would be to add a statement in the reference saying something like:  The highest valid frequency value is 32767
6219  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Our very own extention? on: March 12, 2010, 09:29:05 am
Wiring predated Arduino so its more uncle than nephew.

Wiring does use the same extension
6220  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Our very own extention? on: March 12, 2010, 08:10:45 am
Quote
It doesn't really matter what extention really is used IMHO
Just live with .PDE....
try using Processing (Arduino's sibling environment) and see how easily you can live with clicking on sketches and have the wrong environment come up.

6221  Forum 2005-2010 (read only) / Uno Punto Zero / Re: Our very own extention? on: February 18, 2010, 06:44:52 am
There was a discussion on this topic here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1248240393
6222  Forum 2005-2010 (read only) / Uno Punto Zero / Re: 1.0 Standard Hardware platform and profiles idea on: March 12, 2010, 01:57:41 am
It sounds like zageek is suggesting the need for a mechanism for users to identify what resources a particular sketch requires to run so the correct board can be chosen.

Perhaps he can clarify the problem he is trying to solve by providing some example use cases.
6223  Forum 2005-2010 (read only) / Uno Punto Zero / Re: It is brilliant - lock it down. on: March 01, 2010, 03:48:19 am
Quote
analogWrite stays...
I think the request is not to eliminate analogWrite but to eliminate the confusion caused by analogWrite not working the way beginning Arduino users expect it to.
6224  Forum 2005-2010 (read only) / Uno Punto Zero / Re: It is brilliant - lock it down. on: February 25, 2010, 06:03:59 pm
It's certainly a valid point of view. But as a number if beginners have noticed, analogWrite is not a  very good simulation of analog output if you try to read the output from analogWrite on another arduino using analogRead (or anything else that needs a true analog signal).

The simplification would be less troublesome if analogWrite did not have significant differences from the way analogRead is used.
6225  Forum 2005-2010 (read only) / Uno Punto Zero / Re: It is brilliant - lock it down. on: February 25, 2010, 03:13:36 pm
Quote
is the compiler smart enough to know what to do to eliminate this?
Yes, the compiler is smart enough not to include code that is not called, so a duplicated function with a different name would not add any overhead (assuming only one of the function names was called in a sketch).  

analogWrite may sound like a nice intuitive name but its not really very helpful because its behaviour appears odd to people that don't understand why only certain pins can be used, and only if some other library is not using them, and with values that have a different range from analogRead.

I have seen many non-technical people come unstuck when introduced to  analogWrite because they expect it to be similar to analogRead - in the same way as digitalWrite is similar to digitalRead.  

There is so much code out there using analogWrite that this should continue to be supported. But I expect many non-technical people would prefer to be introduced to a new function named something like pwmWrite that is clearly explained, rather than glancing at analogWrite and expecting it to behave like an output version of analogRead.
Pages: 1 ... 413 414 [415]