Show Posts
Pages: 1 2 3 [4] 5 6 ... 416
46  Development / Other Software Development / Re: New and growing well-documented, feature-complete I2C device library on: August 06, 2011, 01:02:06 pm
I think having a one second default is a better idea. It won't block unless the device doesn't respond and in that case does it matter if the error is returned in one second rather than 250ms? (in the previous code, the error condition would cause it to block indefinitely)

The advantage of a longer default time-out is that inexperienced users won't get false errors when using devices that do take longer than 250ms. Experienced users can increase or decrease the time-out if they want, but it seems more friendly to have a default that minimizes the chance that errors could be reported even when the system if functioning correctly. The longer default time-out has no impact on performance on systems where the I2C devices are responding correctly.

The I2Cdev class is ...is designed to be used by device libraries like the ADXL345 class or ITG3200 class. ...The only time anyone has to worry about specific timeout settings is if they are actually writing a new device class, in which case it seems very likely that they would know to specify an extra long timeout value in their "observeTortoiseMarathonPath()" method.

For this reason, it seems more useful overall to have a legitimate failure come back faster rather than slower. But honestly, I'm willing to change it to 1 sec if you would still recommend it in light of the viewpoint I laid out above (and maybe you clearly understood all of that before and my explanation was redundant anyway). No hard feelings in either case; I'm just trying to be diligent.

    Jeff

Certainly no hard feelings, its your library so no-one should begrudge your right to choose the default values you prefer. But I still think  a longer default timeout is better.

(Hopefully) good coders will read the datasheet and determine and set the appropriate timeout. It's the less diligent people using this code on some otherwise unsupported device that can come unstuck. And if they are not careful enough to check that the default value is set correctly they may not be diligent enough to handle the false error if it does timeout.  But go with your instinct on this, I am sure you have more important  things to do than debate this point.

Michael

47  Using Arduino / Programming Questions / Re: Time and TimeAlarms Libraries – Ask here for help or suggestions on: August 06, 2011, 12:45:54 pm
Rob, did you try to use it in the Arduino IDE?
If so, a brief example would be useful.
48  Using Arduino / Programming Questions / Re: Time and TimeAlarms Libraries – Ask here for help or suggestions on: August 06, 2011, 12:20:26 pm
Many C compilers have a function named ctime that produces a date string but I don't think its available with the arduino tools. I have always used multiple print statements to display the data, is there a reason you can't do that for your application?
49  Using Arduino / Motors, Mechanics, and Power / Re: Wish list for Servo library enhancements on: August 06, 2011, 12:05:13 pm
@mem
(unsigned  vs signed etc)

Quote
If you can convince the Arduino team to change the rest of the API I will be more than happy to update the core Servo library accordingly.

Defining values that can't be negative as unsigned int, helps to prevent bugs that can be caught at syntax level, aka compile time. This fits the Arduino philosophy!!

As far as I can see my proposed changes (wrt signed/unsigned)  will not lead to backwards trouble as negative values would lead to errors, e,g, what would a write(-45) mean?  The param represent an absolute angle (my proposal) not a relative one. Maybe that is a point to consider too, using more descriptive names for the params/vars so people understand better when diving into the code.  

I think you missed my point that the Arduino APIs for things like Servo and analogWrite were defined from the start as signed types. Perhaps its a question of style but changing some of these abstractions but not others does not seem a good idea to me. Anyway, the API for the core libraries are the prerogative of the Arduino team so further discussion on signed vs unsigned arguments should be addressed to the developers list if you feel strongly about this point.

However, a richer and more rigorous API can be provided with a superServo wrapper that would remain compatible with the documented Arduino Servo functionality.

 



50  Using Arduino / Motors, Mechanics, and Power / Re: Wish list for Servo library enhancements on: August 06, 2011, 06:07:06 am
superServo

The current sevo library uses relatively little RAM and the very good suggestions from bill2009 and vinceherman would increase this even if the new features were not used.

What do you guys think about adding new features into a class built on top of Servo? This library would derive from Servo and contain additional fields as necessary for the new features. It could also have the API tweaks Rob suggested earlier in the thread.
51  Using Arduino / Motors, Mechanics, and Power / Re: Wish list for Servo library enhancements on: August 06, 2011, 06:06:05 am
Quick look in the lib:

Servo::write
1) negative values make no sense , replace  by unsigned int types ?
2) I don't like it that the param value in write() can have two distinct meanings.

Servo::attach
1) negative value make no sense , replace by unsigned int?
2) test MIN_PULSE_WIDTH <= min <= max <= MAX_PULSE_WIDTH?

Servo::read
1) strange values if ( this->servoIndex == INVALID_SERVO ); readMicroseconds returns value 0 << SERVO_MIN.

Servo::readMicroseconds
1) return type of function differs from internal var pulsewidth; which is stricly speaking not needed
2) using -1 for invalid values..

Rob, thanks for your input.  I do agree that the argument types for Arduino libraries such as this appear less than ideal.  The current Servo library was  a drop in replacement for the one used prior to version 0017 and the argument and return types were deliberately kept the same.
ints are used throughout Arduino code to express values that cannot be negative, for example see analogRead and digitalRead.  If you can convince the Arduino team to change the rest of the API I will be more than happy to update the core Servo library accordingly.

Your point about the dual nature of write is well taken. It was included for backwards compatibility with an earlier library but  in hindsight I should have removed this capability from the initial release of this library when it went into the Arduino core. If its not too late I will see if I can make this change for the 1.0 release.

There may be a way to address all your points without changing the core, see later post regarding a superServo library.

Michael
52  Using Arduino / Motors, Mechanics, and Power / Re: Wish list for Servo library enhancements on: August 05, 2011, 07:58:48 am
Trim and Reversing are features in most RC transmitters.
I added those features to the servo library (a few versions old) for my own use.

Yes, they are standard features on an RC transmitter, but I wonder if the ease of adding a map function to get this capability into a sketch is one reason why more people don't request this feature. How many bytes of RAM did you use for the trim functions.

One way of implementing trim without using and RAM is to modify the min and max values that can be set in the attach method. The resolution of these values is currently 4 microseconds, I wonder if that would be fine enough for trim settings?
53  Using Arduino / Motors, Mechanics, and Power / Re: VarSpeedServo - a modified Servo library with speed control on: August 04, 2011, 04:17:38 pm
(My sweep code has an advantage that I can do something synchronized with two servos. In an built in function one would need to change the sweep rate for each "ratio".)

What do you mean by the ratio? Perhaps you can say more about the functionality.

I don't want to hijack this thread so I have created a new thread here: http://arduino.cc/forum/index.php/topic,68474.0.html
54  Using Arduino / Motors, Mechanics, and Power / Wish list for Servo library enhancements on: August 04, 2011, 04:14:43 pm
A couple of recent threads have discussed servo enhancements such as setting the rate of servo movement or automatically sweeping at user provided speeds.
I would be interested to hear if these or other features would be a popular addition to the Servo library. No promises that suggestions will be quickly implemented but if a number if people want enhancements that fit within the spirit of the current library then it could be considered for a future release.

see: http://arduino.cc/forum/index.php/topic,61586.0.html
and: http://arduino.cc/forum/index.php/topic,68305.msg504226.html
55  Using Arduino / Networking, Protocols, and Devices / Re: I2C buffer limit on: August 04, 2011, 11:57:44 am
The second one is in twi.h   

the buffers are defined in twi.c
56  Using Arduino / Programming Questions / Re: Stalker V2 Help!! Set the time? RFID Logger on: August 04, 2011, 11:50:34 am
sure, try this:
Code:
#include <RTC.h>
#include <Time.h>
#include <Wire.h>
 
void setup() {
 
  Serial.begin(9600);
  if (RTC.begin()) {
     Serial.println("Valid RTC device initialised");
     setSyncProvider(RTCget);  // register the get function
  }
  else {
    Serial.println("Problem initialising RTC"); 
  }

 
 
}
 
void loop() {
}
57  Using Arduino / Motors, Mechanics, and Power / Re: Help with 19 servos and Mega on: August 04, 2011, 10:17:15 am
Chris,

You can use any of the outputs, including any of the unused PWM or analog input pins.
58  Using Arduino / Microcontrollers / Re: Boards file for 3.3v 12mhz atmega328p? on: August 04, 2011, 09:56:00 am
Thanks for the replies so far smiley Bummer though, thought it would be easier. For now I am just running it at 5v at 16mhz to maintain my speed. I don't know how to rewrite the bootloader if I want to give this a go some other time, do you guys know any write ups or places to begin if I want to get going at it?

Unless you are looking forward to tinkering with non-standard bootloaders and software that is not properly handling CPU speed, you may be better of sticking with 8MHz and looking to make your application efficient enough to run at that speed. What is it that you want to do that 8MHz can’t cope  with?
59  Using Arduino / Sensors / Re: Simultaneous pulse counter inputs on: August 04, 2011, 07:56:02 am
You can use a combination of hardware (Interrupts) and software counting for your project.
Arduino provides two versatile interrupt handlers but you can detect pin pulses on more pins with the right software
Have a look at the library here: http://www.arduino.cc/playground/Main/PinChangeInt

i have not used it but the examples seem to provide a good basis for detecting and counting pulses on three pins

Have fun
60  Using Arduino / Motors, Mechanics, and Power / Re: VarSpeedServo - a modified Servo library with speed control on: August 04, 2011, 07:46:48 am
I am interested to know if adding variable speed sweep would be good enough for most applications?  Most of the additional RAM needed in VarSpeedServo is for the target position, but this is not needed if the sweep is between the min and max positions set in the attach method because only the speed and current direction need to be stored and these can be held in a single byte if the max speed is limited to 127.

Would something like that be useful or will most people want the capability to control speed when moving the servo to any given?
Pages: 1 2 3 [4] 5 6 ... 416