Show Posts
Pages: 1 2 [3] 4 5 ... 416
31  Development / Other Software Development / Re: Notepad++ User Defined Language for Arduino on: January 01, 2013, 09:54:17 am
Thanks Riva, this is a welcome addiiton for those of us that use NPP.

And the install was delightfully simple: after downloading the xml file linked in the first post, in NPP I opened the 'Defined Language dialog' (under the View menu option), clicked "Import" and navigated to the downloaded "userDefineLang.xml" file

Very nice!
32  Using Arduino / Programming Questions / Re: Alarm.alarmRepeat at midnight on: December 31, 2012, 11:05:18 pm
Not sure if you are aware of this, but alarmRepeat does not work for midnight. E.G.

Hi Guy,

0,0,0 is currently ignored by the alarm code. I am traveling at the moment so can't test any code changes, but you are welcome to try the following:

In the updateNextTrigger() function in TimeAlarms.cpp, change :
  if( (value != 0) && Mode.isEnabled )
to:
  if( Mode.isEnabled )  // remove check for value != 0
33  Using Arduino / Project Guidance / Re: Ability to use TinyGPs and Arduino Mini Pro on: December 14, 2012, 07:55:13 am
Can you use the hardware serial (on pins 0 and 1) for the GPS?

How does one do this?

Have a look at the tutorial here: http://www.sparkfun.com/tutorials/176

And remember that you may need to disconnect the GPS when uploading a new sketch.
34  Using Arduino / Project Guidance / Re: Ability to use TinyGPs and Arduino Mini Pro on: December 07, 2012, 01:30:50 am
> How do I know what speed my mini is?
From the IDE, click on Tools>Boards, your are running at 16MHz if your selected board is "Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328"

The Pro Mini uses a ceramic resonator which is not as precise as the quartz crystal in the Uno and that may be a reason that SoftwareSerial can't cope with the baud rate. Can you use the hardware serial (on pins 0 and 1) for the GPS?
35  Using Arduino / Project Guidance / Re: PPM decoder with failsafe on: December 06, 2012, 02:29:40 am
It would help if you explicitly stated what you did want to the application to do. I guess you want 8 or more channels to controlled directly from the transmitter when the the receiver has a good signal, but switch some or all of the channels into preset failsafe values when the PPM signal is invalid.

If that is the case then you may want to try using ServoDecode running in a controller that has two (or more ) 16 bit counters, such as the teensy. In  this configuration, the decode would run off on timer and the servos off another. I wonder if someone has already tried this to see if the two timer interrupts would cause any noticeable jitter.

Michael
36  Using Arduino / Project Guidance / Re: Ability to use TinyGPs and Arduino Mini Pro on: December 05, 2012, 06:07:00 am
I don't have that combo but the link to the gps in your post indicates that the baud rate is 57600. If that is correct then it may be too fast for the pro  mini, particularly if its the 8MHz version.   

What baud rate are you using?
37  Using Arduino / Project Guidance / Re: PPM decoder with failsafe on: December 05, 2012, 05:44:00 am
As you can see from the posts here, there are many approaches you can take. If you say more about your project then it would be easier to suggest which ones would work best for you.

Other than the failsafe, do you want to analyze the individual channel signals? If so, can you say a little more about what you want the Arduino to do with the channel data.

Michael
38  Using Arduino / Programming Questions / Re: Time and TimeAlarms Libraries – Ask here for help or suggestions on: September 19, 2011, 07:19:51 am
Hi all,

I'm using the time library for my home energy monitoring project.
The problem :
Very frequently I get crappy output in the date/time string part, like this :

It seems that sometimes a kind of buffer overflow occurs. Initially, I used the String object, but that made it even worse! (PString is a buffer overflow save string object).
Could you please check what could be the reason for this strange output?

Kind regards,

Bart.

Bart,
You can check if the problem is due to the chrDT buffer overflowing by testing with a hard coded string of the correct length for the date.
If you still have the problem this is probably not a Time library issue and if that is the case then best to move the discussion to a new thread.
39  Using Arduino / Programming Questions / Re: Time and TimeAlarms Libraries – Ask here for help or suggestions on: September 19, 2011, 07:00:34 am
Hi,

I'm trying to use the Time library with arduino 1.0-beta4  for OSX (library is located at ~willem/Documents/Arduino/Libraries/Time) when I compile I get

UdpNtpClient_WE.cpp:1:18: error: Time.h: No such file or directory

I guess something has changed for IDE 1.0 (beta) .... who knows the solution ?

Cheers, Willem.
Here is an NTP code for Arduino 1.0:
Code:
/*
 * Time_NTP sketch
 * Example showing time sync to NTP time source
 *
 * This sketch uses the Time library
 * and the Arduino 1.0 Ethernet library
 */

#include <Time.h>
#include <SPI.h>         // needed for Arduino versions later than 0018
#include <Ethernet.h>
#include <EthernetUDP.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192, 168, 1, 44 }; // set this to a valid IP address (or use DHCP)

unsigned int localPort = 8888;      // local port to listen for UDP packets

IPAddress timeServer(192, 43, 244, 18); // time.nist.gov NTP server

const int NTP_PACKET_SIZE= 48; // NTP time stamp is in first 48 bytes of message
byte packetBuffer[ NTP_PACKET_SIZE]; // buffer to hold incoming/outgoing packets

time_t prevDisplay = 0;    // when the digital clock was displayed

// A UDP instance to let us send and receive packets over UDP
EthernetUDP Udp;

void setup()
{
  Serial.begin(9600);
  Ethernet.begin(mac,ip);
  Udp.begin(localPort);
  Serial.println("waiting for sync");
  setSyncProvider(getNtpTime);
  while(timeStatus()== timeNotSet)
     ; // wait until the time is set by the sync provider
}

void loop()
{
  if( now() != prevDisplay)   //update the display only if the time has changed
  {
    prevDisplay = now();
    digitalClockDisplay();
  }
}

void digitalClockDisplay(){
  // digital clock display of the time
  Serial.print(hour());
  printDigits(minute());
  printDigits(second());
  Serial.print(" ");
  Serial.print(dayStr(weekday()));
  Serial.print(" ");
  Serial.print(day());
  Serial.print(" ");
  Serial.print(monthShortStr(month()));
  Serial.print(" ");
  Serial.print(year());
  Serial.println();
}

void printDigits(int digits){
  // utility function for digital clock display: prints preceding
  // colon and leading 0
  Serial.print(":");
  if(digits < 10)
    Serial.print('0');
  Serial.print(digits);
}

/*-------- NTP code ----------*/

unsigned long getNtpTime()
{
  sendNTPpacket(timeServer); // send an NTP packet to a time server
  delay(1000);
  if ( Udp.parsePacket() ) {
     Udp.read(packetBuffer,NTP_PACKET_SIZE);  // read packet into buffer


     //the timestamp starts at byte 40, convert four bytes into a long integer
     unsigned long hi = word(packetBuffer[40], packetBuffer[41]);
     unsigned long low = word(packetBuffer[42], packetBuffer[43]);
     // this is NTP time (seconds since Jan 1 1900
     unsigned long secsSince1900 = hi << 16 | low; 
     // Unix time starts on Jan 1 1970
     const unsigned long seventyYears = 2208988800UL;     
     unsigned long epoch = secsSince1900 - seventyYears;  // subtract 70 years
     return epoch;
  }
  return 0; // return 0 if unable to get the time
}

// send an NTP request to the time server at the given address
unsigned long sendNTPpacket(IPAddress address)
{
  memset(packetBuffer, 0, NTP_PACKET_SIZE);  // set all bytes in the buffer to 0

  // Initialize values needed to form NTP request
  packetBuffer[0] = B11100011;   // LI, Version, Mode
  packetBuffer[1] = 0;     // Stratum
  packetBuffer[2] = 6;     // Max Interval between messages in seconds
  packetBuffer[3] = 0xEC;  // Clock Precision
  // bytes 4 - 11 are for Root Delay and Dispersion and were set to 0 by memset
  packetBuffer[12]  = 49;  // four-byte reference ID identifying
  packetBuffer[13]  = 0x4E;
  packetBuffer[14]  = 49;
  packetBuffer[15]  = 52;

  // send the packet requesting a timestamp:
  Udp.beginPacket(address, 123); //NTP requests are to port 123
  Udp.write(packetBuffer,NTP_PACKET_SIZE);
  Udp.endPacket();
}
40  Development / Other Software Development / Re: Implementation for Microchip ENC28J60 Ethernet controller on: August 06, 2011, 01:10:26 pm
it would be easier to help if you said what the error was.

did you change also change the following?
   #define SPI_SS      8

did the sketch compile and run with the default CS/SS pin?
41  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

42  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.
43  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?
44  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.

 



45  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.
Pages: 1 2 [3] 4 5 ... 416