OK hooking up a speaker is way too much work.

Here's the code

/* Test delayMicroseconds() with param of zero
*/

int tdelay;
unsigned long i, hz;
unsigned long time, timeForOnes, timeForZeros;
int outPin = 11;

void setup(){
  pinMode(outPin, OUTPUT);
  Serial.begin(9600);
  Serial.println("start");
}

void loop() {
    time = millis();               // get start time of  loop
    for (i = 0; i < 4000; i++){  // time 100,000 cycles through the loop
       delayMicroseconds(1);
    }
    timeForOnes = millis() - time;      // compute time through inner loop in milliseconds
  
    time = millis();               // get start time of  loop
    for (i = 0; i < 4000; i++){  // time 100,000 cycles through the loop
       delayMicroseconds(0);
    }
    timeForZeros = millis() - time;      // compute time through inner loop in milliseconds
  
  Serial.print("ones = ");
  Serial.print(timeForOnes, DEC);
  Serial.print("   zeros =  ");
  Serial.println(timeForZeros, DEC);
  
  
}

Here's the result:


ones = 11   zeros =  4118

ones = 11   zeros =  4120

ones = 13   zeros =  4119


DelayMicroseconds(0) appears to take about 1026 us.

delayMicroseconds(0) appears to malfunction and return (delay really) a much larger value, instead of returning asap.

I discovered this experimenting with a sound synthesis program with a variable for the delayMicroseconds param.

Maybe this should be in the docs?

I'm pretty sure we don't want to fuss with the function or put a conditional statement in it, and change all the timing.



You can hear this if you set up a speaker or headphone connected to ground on one side and two 5k resistors on the other wire, the other ends of the resistors go to  pins 3 & 4 .

void loop()        // delayMicroseconds bug?
{

  for (int x = 1; x < 20; x++){
    pinMode(3, OUTPUT);
    pinMode(4, OUTPUT);
    digitalWrite(3, HIGH);  
    delayMicroseconds(1);   // change this to 0 and listen
    digitalWrite(4, HIGH);  
    delayMicroseconds(1000);    
    digitalWrite(3, LOW);    
    delayMicroseconds(1);    // change this to 0 and listen
    digitalWrite(4, LOW);    
    delayMicroseconds(1000);    
    pinMode(4, INPUT);
    pinMode(3, INPUT);
  }
  delay(100);
 
}

Thanks to all who have worked on new shiftout function, it's great to see this happening.

I'd like to put in a request for a variable frame size, if and when the right function gets packaged up and included in core. I programmed an LED sign with the TI PWM chip TLC5940 and it had a frame size of 14 bits I believe.

There are a couple of other arcane issues such as whether the data line gets left high or low and the relationship of clock to data. I didn't really study the protocols that much, just tried the options included in SBC docs until I found ones that worked. There seemed to be three or four flavors of the protocol I recall.

What about the native SPI hardware? Isn't this the real path to speed, plus unloading the chip for other duties?

There's 6 cents worth.

Note that I did put this line in the tutorial - but maybe it's not too clear.
The idea is that students could fix the tutorial and learn something on the way

Code:

    // routine to report elapsed time - this breaks when delays are in single or double digits. Fix this as a coding exercise.

But since mikalhart fixed it so elegantly, I'll deprive all those future generations of students of the work required to fix it, and paste the code in. Please test it and post back here if it doesn't work.

What if remainder is zero? Shouldn't we really display three zero's after decimal point for consistency?


paulb

Some sleep commands would be handy things to have. Maybe one that used timer interrupts and one that used external interrupts to come out of sleep - perhaps both could be implemented together. There also seems to be some choices as to the level of shutdown one wants to implement.

I've had students who would like to try this out but are put off diving into the AVR code.

This seems like another thing that is implemented on other entry-level microcontroller environments, that seems to be basically worked out, but languishing, in the Arduino environment.

There was a thread on this in the Software Development forum section that had all the code fixes. Don't know if the library ever got changed though. It's easy enough to tell.

The fix is trivial - just use a separate variable (or better, array) for the pins, and use that for indexing. The original code just wasn't really up to snuff as a general-purpose library.

There was another thread in this discussion group  (bugs & suggestions) on LCD's, I think, where the LCD libraries were discussed. Mellis was talking about rewriting them himself I believe.

BUT FIXING THE OBVIOUS ANNOYING BUGS NOW WOULD BE A GOOD START.  

Paul

The 4bit LCD library has some too-clever coding that should probably be changed.

Code:

int DB[] = {7, 8, 9, 10};  //wire these to DB4~7 on LCD.


  for (int i=DB[0]; i <= DB[3]; i++) {

    digitalWrite(i,val_nibble & 01);
    val_nibble >>= 1;

  }

the for loop will break if the pin values for DB[0] - DB[3] are not in order.
This came up on a board with the pins hardwired to an LCD, so it's not just theoretical.

I think this is the fix, although I haven't tested it. I'm not sure whether I can declare variable
j there, but you get the idea.

Code:

 for (int i=0; i <= 3; i++) {
 
   int j = DB[i];
    digitalWrite(j,val_nibble & 01);
    val_nibble >>= 1;

  }

One of my customers put together a patch to do the above modifications, which, to review, are intended to make the FTDI cable do autoreset with Linux.

It's called LinuxFixArduino.zip, and may be found here. I haven't looked at it, since I don't have a Linux machine [use for my Wintel box?]

But comments and suggestions could be posted on the Modern Device Forum.

http://moderndevice.com/connect.shtml

Paul Badger

Hi Tim,

Thanks for posting this. I've had a request from some Linux users who are also using the cable, for a fix to this issue. If you wouldn't mind sending me  the patched version, I'll put it up on my site for people who are having this issue, and maybe we can also get it tested with a Diecimila to make sure it doesn't break anything.

Probably someone will test it and report back here before too long though. I'm also hoping that this fixes the need to check "set RTS on close" in the windows version.

Have you patched v 11 in a similar manner?

Paul Badger
pbadger  a _t_  verizon d_ t net

All this could lead to some useful commands in the Arduino language too, since we're trying to build an easy-to-use language for beginners.

Proposed:

ResetBoard()
SetWDT(pin,  time, (HIGH/LOW/CHANGE))     // lets user setup the WDT to reset the board if it doesn't see activity on a pin within a certain time frame.
ClearWDT()

Brian Evans compiled one version of the reference section - he might be open to collaborative update of his latest effort. I will also volunteer to edit / write some of it.

From discussions with Brian, I think it's important to come up with some editorial style, and organizational guidelines before starting off.  

Lots of educators would like to have a well edited version of this material too.

I think that Brian's first experience with open office was a bit frustrating but you can track him down and see what he has to say about the current state of his tech. I don't want to post his email so I'll post mine.

pbadger  -   verizon  - net

OK some experiments with the AREF pin have yielded the following results.

The internal connection to the AVCC pin, when using the DEFAULT setting, appears to be a low impedance connection, and the 5K pot I connected to the pin appeared to make very small differences on ADC readings. So in this sense,  low impedance connections of other voltages to the AREF pin might very well do some damage, and should be avoided. Hence the recommendation of connection through a 5k resistor.

This value was picked by shorting ground to AREF pin while using the DEFAULT setting - with an ACD reading of 1014 - it changes the value only 1 - to 1015. I also figured an extra mA of current though most circuits was not going to harm anything. Probably 10K would be just as good a recommendation and might tend to be in more students' boxes of parts, since we recommend that value for pullup/pulldown resistors. (Oops - just checked that resistor an it turned out to be 47K not 4.7K - more later on best value)

However the 1.1 volt source is a different story. I tried measuring the voltage on the AREF pin (with nothing connected externally) and my digital meter failed completely, however I succeeded in reading the voltage with a jfet input analog meter. When I connected the 5K pot to the AREF pin, it just completely overrode the internal reference and governed the ADC readings completely. So this setting doesn't really require the protection of the resistor but it does require explaining why it won't work with anything connected externally to the AREF pin.

I took a shot at updating the docs. Comments and critiques welcome. Look for them to get moved to someplace more obscure really soon  

Paul

Here's the datasheet description of the AREF pin

ADC Voltage Reference
The reference voltage for the ADC (VREF) indicates the conversion range for the ADC. Single
ended channels that exceed VREF will result in codes close to 0x3FF. VREF can be selected as
either AVCC, internal 1.1V reference, or external AREF pin.
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.


My take on this is that because the internal sources are high impedance sources that the external source will just take precedence over the internal ones - and no harm will be done. Some testing is in order but the way I read this now, we don't have to worry about connecting two things at once at all - it's just that the external source is going to govern the analog system, no matter what the software says about the internal connection.

Other opinions? Maybe a question to the Atmel engineers is in order.

I revised the warning on the AREF page, but it's actually incorrect if my reading above is true because any resistance would cause the internal resistance to act as a voltage divider, changing the desired AREF voltage. If we get this settled maybe deleting the warning is the best idea.

Is there a way to allow users to mark something as spam, that would then banish the post until it could get looked at? It doesn't make the work load less, but might spread it around.

This test program reports the same thing for each type so that seems to indicate there isn't any processing that's different with the types, so the takehome is that  AVR float == double ?

/* Float double test */

float vfloat;                            
double vdouble;                        

long start;
void setup()
{
 Serial.begin(9600);
}
 
void loop()
{
   start = millis();
  for(vfloat = 0 ; vfloat <= 100000; vfloat+=.111) // fade in (from min to max)
  {
 
  }
  
  Serial.println(millis() - start);
  
  start = millis();
  for(vdouble = 0 ; vdouble <= 100000; vdouble+=.111) // fade in (from min to max)
  {
  }
  
  Serial.println(millis() - start);
}