Regarding pinMode(), that's curious. You mean it has no effect on A6/A7 because of their analog, input-only nature?

Because the page http://arduino.cc/en/Tutorial/AnalogInputPins actually uses pinMode() on an analog pin. Ok, that's obviously to set it as OUTPUT. INPUT should be redundant, since they are input by default. But I thought it was a good measure to set them to INPUT, just in case some code previously had set them in OUTPUT mode...

The first six analog pins do have digital circuitry behind them, so pinMode and digitalWrite work just fine. It's just pins A6 and A7 on the surface mount '328 which are analog-only.

Cheers!

On the Mega, PortB is on different pins. Refer to the schematic, basically its pins 51 52 53 54 10 11 12 13. Maybe not that order though.

The code works but you have to match it to the hardware.

Cheers!

I have a routine I have to get the internal temperature on the 32u4. The only part I wasn't 100% sure of was the returned value, but the research I did in the Atmel documentation led me to believe it's the absolute temperature in kelvin. Here's the routine:

Code:

int getTemperature() {
  // routine provided by TCWORLD in Sparkfun forums - thank you very much TCWORLD!
  // see here for details: http://forum.sparkfun.com/viewtopic.php?f=32&t=32433
  ADMUX = 0b11000111;                  // set the adc to compare the internal temp sensor against
  ADCSRB |= (1 << MUX5);               // the 2.56v internal reference (datasheet section 24.6)
  delay(5);                            // wait a moment for the adc to settle
  sbi(ADCSRA, ADSC);                   // initiate the first conversion - this one is junk as per datasheet
  while (bit_is_set(ADCSRA, ADSC));    // wait for the conversion to finish
  delay(5);                            // another little extra pause just in case
  sbi(ADCSRA, ADSC);                   // initiate the second conversion - this is the good one
  while (bit_is_set(ADCSRA, ADSC));    // wait for the conversion to finish
  byte low  = ADCL;                    // read the low byte
  byte high = ADCH;                    // read the high byte
  int temperature = (high << 8) | low;     // result is the absolute temperature in Kelvin * i think *
  temperature = temperature - 273;     // subtract 273 to get the degrees C
  temperature = temperature * 18;      // times by 90 & divide by 5 (.1 precision without floats)
  temperature = temperature + 320;     // then add 320 to get degrees F x 10
  temperature = temperature / 10;      // then divide by 10 to get degrees F
  return temperature;
}

Cheers!

This website uses Java where? I have Java disabled in my browser and can navigate and use this site just fine.

The website does use Javascript, which is entirely different and unrelatd to Java.

Similar to the OP's concerns, I've seen it suggested lately that it's time to put Java to bed - that 90% of computer users never use it, that Java's risks outweigh the gains. Eg. http://www.pcworld.com/article/261843/time_to_give_java_the_boot.html  I don't know how valid the report is, but it seems to be a cause for concern.

How would that affect Arduino,if Java was no longer available (or at least no longer pre-installed) on new computers?

Either of your examples will run fine.

The only difference is in the first example, it is possible that the value of millis() can change between each if statement. With the second example, all of your if statements will be testing against the same value.

Whether that difference is important or not would depend on what exactly you are looking for.

Cheers!

Thanks for the info Lefty!

I'll have to try both, 12MHz and 16MHz and see how it goes. I should be able to code around the millis() problem at 12MHz but 16MHz would be much nicer... on the other hand, debugging can be hard enough as it is, without having to worry about random logic errors from running the uC out of spec.

I'm not using it for anything health & safety related - no nuclear cats or reactive scanners. It's basically just running an array of sensors. But I like things to work correctly, even if they're not mission-critical.

Cheers!

I've been looking at this lately as I'm running a home-made Arduino at 3.3v and find 8MHz is a bit too slow for my purposes.

At 12 MHz it appears that the millis() function will be out by 5.333 microseconds per millisecond. That is, the actual 'microseconds per timer0 overflow' appears to be 1365.333 but the millis() calculation is going to be based on 1360 microseconds per timer0 overflow. (Based on my understanding of the maths involved.)

That seems to be off by only about 0.4% - but in my application I'm relying on the time to be accurate, for a software RTC. It updates several times per day via GPS but in between updates it's relying on millis() for the timekeeping.

So I'm wondering, what sort of problem could happen if the microprocessor is run 'too fast'? Would that shorten the lifespan of the chip? Or does runing it out of spec lead to logic errors or something like that?

Essentially, what is the risk of running the arduino too fast?

Thanks!

Sorry if this is off topic - I've been following this and similar threads as I'm using the '1284P in a custom project.

I'm wondering what is the advantage of using Optiboot on the 1284? I understand that fitting the bootloader in 512 bytes is a big improvement on a '168 or a '328 because the overall flash size is much smaller, but the '1284 has loads of flash. And the smallest bootloader you can specify with fuses is 1024 bytes.

Are there other advantages to Optiboot, beyond it having a small footprint?

FWIW I'm using a 'standard' Arduino bootloader that fits inside 2048 bytes, and it is working fine for me. My board is using a ceramic resonator at 8MHz and I've set the bootloader for 57600 baud.

As long as you understand how the pins file is utilized (and do make a backup or keep a copy of the original) there aren't any real concerns about fiddling with it.

Worst-case scenario, you can always reinstall the IDE if things got totally messed up. But just keeping a backup copy of that one file should be all you need.

I've done what you're discussing with Sparkfun's pro micro (a Leonardo clone), created my own pins_arduino.h for it that suited my requirements.

The only other caveat is if you are using any libraries, just make sure you update any hardcoded references they have, eg. the SD card library has d4 hardwired as the chip select pin, so if you've redefined d4 then you might need to modify the library.

Cheers!

I'm working on just such a thing. Can you elaborate on what some of the Leonardo's quirks are?

Mike

Off the top of my head:

Quirks to the Arduino 32u4 implementation in general: there's no Timer2 so any library or sketch that uses it won't work, the bootloader's auto-reset process can be overwhelmed by a bad sketch which can require you to manually reset to get a new sketch in (or in worst conditions you might need to use an ISP to reburn the bootloader but I think that's really rare). The various 'standard pins' are all moved around, eg. SPI is on different pins, I2C on different pins. The USB libraries take a huge whack of space so out of your 32kB you lose 4kb to the bootloader and another 3kb in 'overhead' (i.e. any sketch you write will be 3kb bigger because of the USB libraries). The TX/RX LEDs are (IMHO) handled a bit wierd and one of them is the hardware SPI SS pin, so any libraries that are hardwired to use the hardware SPI SS pin won't work.

Quirks specific to the Leonardo: SPI is only available on the ICSP pins so any shield that expects to find SPI on pins 11..13 won't work. I2C is moved as well so any shield expecting I2C to be on A4-A5 won't work.

Quirks specific to the Pro Micro: it's missing a few digital pins that appear on the Leonardo (I think it's 11, 12, 13 that are missing). I know they've released a newer version than mine, but if you have an older version, the bootloader is not compatible with Leonardo. There are errors on the schematic that may or may not be fixed now, relating to the assignment of analog pins on the digital side (eg. A8 may or may not be D8, etc).

That may sound like a lot of issues but mainly it boils down to what you are doing and if you're using certain shields and libraries. And of course, if you're comfortable modifying libraries then you can usually fix any glitches that come up there.

I'm still a big fan of the Pro Micro, and I think the Leonardo has a place in the lineup. I've just seen a lot of comments from people with problems about the SPI and I2C pins, i.e. not understanding they're in a different place. And I've seen some comments (and experienced it myself) where an out of control sketch can prevent the bootloader from auto-resetting. Then you think your Arduino is bricked because you can't load a new sketch. But it's usually fixable with manual reset (sometimes you have to get the timing just right but it usually works.)

There's advantages too, to balance it out.  The 32u4 has 512 more bytes of RAM than a '328. And the 32u4 has more analog pins, IIRC there's 8 analog inputs you can use. And of course, you can take advantage of the native usb ability, to do keyboard or mouse stuff.

Cheers!

Fantastic work!

I don't have an FT857, I do have some of their other rigs though (mobile & handhelds).

It's also great to see a fellow ham on here!

Cheers & 73 de
Stephanie
va3uxb

For the heck of it, I gave it a shot to extract the sketch name without using the dreaded String class.

Code:

    char fullPath[] = __FILE__;
    char *slash;
    slash = strrchr(fullPath, '/');
    slash++;
    strcpy(fullPath, slash);
    byte length = strlen(fullPath);
    char fileName[20] = "";
    strncpy(fileName, fullPath, (length - 4));
    strcat(fileName, ".ino");
    Serial.print(fileName);

I don't know if my non-String version is much better (I don't really get C), or if the whole excercise is pointless, but there it is.

It sounds like a baud rate problem to me.

Despite the datasheet saying 9600 baud, for some reason I seem to recall using 4800 with the UP501.

Try setting your GPS.begin to 4800 and see if that helps?

Cheers!

I will probably first prototype this on an Atmega32u4, since I like having the direct USB connection, but I want to make this available as an arduino library, and I was wondering if there are any conventions, which timers should be used by addon libraries (e.g. "TMR0 is used by the milis() function, don't use that one" or "the servo library already uses TMR2",...)

The 32u4 doesn't have a timer2... a great reason why it would be nice to let the user decide which timer to use.

You can try loading a simple sketch (eg. Blink), just use the manual reset button on the Leonardo about a second after clicking the upload button in the IDE. If it's timed right, the bootloader and the IDE will see each other while the IDE is attempting to send the sketch. If it doesn't work on the first attempt, try a couple more times. I've been in the same position and was able to rescue my Arduino this way.

Of course, reloading the bootloader is always an option too if you have a programmer or another Arduino to use.

Cheers!