Trying to install 012 on a Mac and get this

java.io.IOException: Target platform: "null" not found.
Make sure that "build.target" in the
preferences file points to a subdirectory of
/Applications/DevelopmentApps/arduino-0012/hardware/cores
... long string of java errors





There seems to be no "build.target" in my preferences file. I also tried deleting the old prefs file and restarting Arduino to insure that it built a new one.

Any ideas?

The problem turned out to be easy - and my student eventually found the updated panel in Windows to set the serial port. Most of the confusion just resulted from me working with a French version of Vista. I still haven't really had time to look at the English version.

So I guess the postscript is that there is no real problem here - just keep poking around until you find the panel for the serial port settings.

Paul

Does anyone have any experience with Vista and the FTDI cable. I was
trying to troubleshoot a student's computer with the labels in French
so I was really confused anyway, but it seems the whole virtual
serial port options have changed considerably. The "Set RTS on close"
checkbox was nowhere to be found. Any idea where this option is, or
if it still exists. I couldn't seem to get reset to trigger
successfully.

Thanks in advance for anyone who can help me with this.

Please excuse the cross-post with hardware troubleshooting topic, I'm hot to get this resolved.

paulb

I'm trying to compile the bootloader with the included Makefile

And I get this in my terminal window

Paul-Badgers-Computer:/Applications/*DevelopmentApps/arduino-0008/Boot168 paul$ make
make: *** No targets.  Stop.

I take this to be some kind of path problem. The bootloader code and makefile are in a folder, in the arduino folder.

I'm on a Mac using 10.3.9

Thanks in advance for anybody that can shed some light on this.

paul badger

I see that the delayMicroseconds doc no longer mention the bug of long delays being generated by a parameter of zero or a negative number.

I'll just repeat that a fix for this bug (one or two) lines exists and has been tested, and also seems to have absolutely no effect on timing. But as there seems to be no interest in fixing this - you might at least continue to document its ill effects.

Beginning coders using a variable in delayMicroseconds() could be forgiven for not understanding why their code is behaving bizarrely from the seemingly innocuous mistake of allowing a zero as a parameter in the function.

Paul

February 01, 2010, at 01:30 PM by David A. Mellis -
Changed lines 37-40 from:

To ensure more accurate delays, this functions disables interrupts during its operation, meaning that some things (like receiving serial data, or incrementing the value returned by millis()) will not happen during the delay. Thus, you should only use this function for short delays, and use delay() for longer ones.

delayMicroseconds(0) will generate a much longer delay than expected (~1020 us) as will using negative numbers as a parameter.
to:

As of Arduino 0018, delayMicroseconds() no longer disables interrupts.
Restore

I needed a link and figured I'd post this for other users who might need a link to where the math docs are. For some reason the admin has decided this information should not even be in extended reference.


http://arduino.cc/en/Math/H

Arduino trig and exponential functions use the avr-libc library. The library includes a great number of useful mathematical functions for manipulating floating point numbers.

The Atmega8 chip, which is now dated, but still supported, does not have enough memory to be able to use the math.h library so you will probably need to update to an Atmega168 if you wish to use any of these functions.

The full docs for math.h may be found http://www.nongnu.org/avr-libc/user-manual/group__avr__math.html

List of more common functions with descriptions

This is just a partial list - check the docs for more obscure functions

double  cos (double __x)   // returns cosine of x in radians
double       fabs (double __x)  // absolute value of a float
double       fmod (double __x, double __y) // floating point modulo
double       modf (double __value, double *__iptr) // breaks the argument value into
                                              // integral and fractional parts
double       sin (double __x)   // returns sine of x in radians
double       sqrt (double __x)  // returns square root of x in radians
double       tan (double __x)   // returns tangent of x in radians
double       exp (double __x)   // function returns the exponential value of x.
double       atan (double __x)  // arc tangent of x
double       atan2 (double __y, // arc tangent of y/x
double       log (double __x)   // natural logarithm of x
double       log10 (double __x) // logarithm of x to base 10.
double       pow (double __x, double __y) // x to power of y
double  square (double __x) // square of x



See also

    * float
    * double

I'd like to see this get implemented. It seems like an elegant memory solution at the expense of some perhaps clunky code.

Maybe change the pic to 4 AA's? I haven't tested any servos at three volts but would bet at least some would be sluggish or inoperative.

pb

Just documenting this here since it apparently is not to be included in the official docs.

Previous version of the Servo Library Write function docs:

write()
Description

Writes a value to the servo, controlling the shaft accordingly. On a standard servo, this will set the angle of the shaft (in degrees), moving the shaft to that orientation. On a continuous rotation servo, this will set the speed of the servo (with 0 being full-speed in one direction, 180 being full speed in the other, and a value near 90 being no movement).

Parameter values between 544 and 2400 passed to the write method will be interpreted in microseconds (uS), exactly the same as the writeMicroseconds method.



servo.write(angle  OR microseconds)

angle: in degrees, from 0 to 180
microseconds: the angle value in uS, from 544 to 2400

Arduino: We like it when you do it our way.

paulb

I hesitate to keep repeating myself, but occasionally with nagging things get changes.

This is the kind of easy, sensible stuff that could easily be addressed if more than one person were working / making decisions on the IDE code. Users were asking for this change years ago.

Is still would be nice to see the Arduino team loosen up and add some other people's code and contributions to the core, without having to micromanage, nitpick, and agonize over every change. Find rough consensus, Get some jobs done. Move on. The Arduino team's efforts have / have had plenty of bugs in them. Errors by others are no more intolerable than native Arduino team errors (v 17 just the latest example).

The biggest mystery is: Why does the Arduino team feel the need to reject one of the largest advantages of open-source software?

This one has been suggested by many other people. It caused a bit of dustup on the developer forum with several people supporting the idea and two members of the arduino team insisting that the feature was "too complex for beginners" or something like that.

Others may characterize the discussion in other ways. I found it too boring to do more than observe at a distance and the arc of the outcome was obvious.

Apparently a barely functional IDE is part of Arduino's charm.

paulb

Please add "const" as keyword to language.

paulb

Pepe34,

Where did the 32K input impedance reference show up in the datasheet? I didn't find it.

PaulB

Thanks for the info Pepe34, & BenF,

I wrote the analog reference entry based on my, and others, reading of the datasheet and some experiments I did on the pin, but I was never satisfied with the ambiguity in the datasheet, and have always thought about writing to the Atmel engineers for clarification - or to see if they had a schematic of the AREF system.

I missed entirely the 32K input impedance reference - but this still doesn't make it a voltage divider unless the 32k is connected on one end to ground.  which the math you post seems to indicate. Does the datasheet mention there is a 32k load resistor to ground?

If there really is some input impedance input at the AREF pin, which I have always suspected, then the 5K recommendation doesn't seem to make any sense and we should tell people to just hook up a low impedance voltage source to AREF.

I've got a lot of chips around and I'll do some experiments with current draw and the like, but I expect to find no problems with connecting low impedance sources to the pin. Except of course, that the voltage will override the expected reference voltage.

Using the resistor does make it possible to switch sources on the fly - but at the expensive of fussing with the voltage divider effect. I guess if the input is grounded through a 32K resistor when it's in the EXTERNAL setting a resistor to a uC pin could be used to generate the voltage, then switched off for the 1.1 or 5V setting.

Let me know if you think my interpretation is incorrect. If anyone wants to try some experiments, I'll be glad to send out new chips to users who think they may have damaged their chips in the service of science.

This is from the 328 datasheet.

AVCC is connected to the ADC through a passive switch. The internal 1.1V reference is generated
from the internal bandgap reference (VBG) through an internal amplifier. In either case, the
external AREF pin is directly connected to the ADC, and the reference voltage can be made
more immune to noise by connecting a capacitor between the AREF pin and ground. VREF can
also be measured at the AREF pin with a high impedance voltmeter. Note that VREF is a high
impedance source, and only a capacitive load should be connected in a system.

If the user has a fixed voltage source connected to the AREF pin, the user may not use the other
reference voltage options in the application, as they will be shorted to the external voltage. If no
external voltage is applied to the AREF pin, the user may switch between AVCC and 1.1V as reference
selection. The first ADC conversion result after switching reference voltage source may
be inaccurate, and the user is advised to discard this result.

"If the user has a fixed voltage source connected to the AREF pin, the user may not use the other
reference voltage options in the application, as they will be shorted to the external voltage."

This does seem to indicate that something bad may happen - other than just malfunction, but just  malfunction seems like one way it could be interrpreted.


PaulB

OK - fixed. Let us know if that doesn't get it.

paulb