Arduino.ru

Решение http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

Я не даром написал про комментарии из исходника wiring.c, что они не используют delay_us по причине того, что на малых задержках дает некорректные задержки. Цитирую: "В комментария функции (см. файл wiring.c) написано, что использование стандартной функции delay_us из avrlib не дает желаемых задержек на 1-2мкс, потому реализована своя функция."

В общем дело хозяйское, жедлающие могут вызвать delay_us.
Пока проверить не могу, но решение для 12МГц кварца достаточно простое, (добавлены строки 65-68):

/* Delay for the given number of microseconds.  Assumes a 8 or 16 MHz clock. */
void delayMicroseconds(unsigned int us)
{
	// calling avrlib's delay_us() function with low values (e.g. 1 or
	// 2 microseconds) gives delays longer than desired.
	//delay_us(us);
#if F_CPU >= 20000000L
	// for the 20 MHz clock on rare Arduino boards

	// for a one-microsecond delay, simply wait 2 cycle and return. The overhead
	// of the function call yields a delay of exactly a one microsecond.
	__asm__ __volatile__ (
		"nop" "\n\t"
		"nop"); //just waiting 2 cycle
	if (--us == 0)
		return;

	// the following loop takes a 1/5 of a microsecond (4 cycles)
	// per iteration, so execute it five times for each microsecond of
	// delay requested.
	us = (us<<2) + us; // x5 us

	// account for the time taken in the preceeding commands.
	us -= 2;

#elif F_CPU >= 16000000L
	// for the 16 MHz clock on most Arduino boards

	// for a one-microsecond delay, simply return.  the overhead
	// of the function call yields a delay of approximately 1 1/8 us.
	if (--us == 0)
		return;

	// the following loop takes a quarter of a microsecond (4 cycles)
	// per iteration, so execute it four times for each microsecond of
	// delay requested.
	us <<= 2;

	// account for the time taken in the preceeding commands.
	us -= 2;
#else
	// for the 8 MHz internal clock on the ATmega168

	// for a one- or two-microsecond delay, simply return.  the overhead of
	// the function calls takes more than two microseconds.  can't just
	// subtract two, since us is unsigned; we'd overflow.
	if (--us == 0)
		return;
	if (--us == 0)
		return;

	// the following loop takes half of a microsecond (4 cycles)
	// per iteration, so execute it twice for each microsecond of
	// delay requested.
	us <<= 1;
    
	// partially compensate for the time taken by the preceeding commands.
	// we can't subtract any more than this or we'd overflow w/ small delays.
	us--;
#endif

	// busy wait
	__asm__ __volatile__ (
		"1: sbiw %0,1" "\n\t" // 2 cycles
#if F_CPU == 12000000L
		"nop" "\n\t"
		"nop" "\n\t"
#endif
		"brne 1b" : "=w" (us) : "0" (us) // 2 cycles
	);
}

В двух словах. Только для 12МГц ЦЗ увеличивается в полтора раза, с 4 циклов до 6 циклов, т.е. то же время 0.5мкс на ЦЗ, как и для 8МГц, т.е. всё должно работать нормально.

PS Исправлялся исходник ArduinoIDE v1.0.5

Не знаю кто это там написал, сам тоже не проверял, других источников об этой проблеме не нашел и в описании самой библиотеки об этом ничего нет . Может это справедливо только при вызове _delay_us() из тела функции delayMicroseconds(), но никто не мешает воспользоваться директивой #define.

#define delayMicroseconds(us) _delay_us(us)

/* Delay for the given number of microseconds.  Assumes a 8 or 16 MHz clock. */
void delayMicroseconds(unsigned int us)
{
	// calling avrlib's delay_us() function with low values (e.g. 1 or
	// 2 microseconds) gives delays longer than desired.
	//delay_us(us);

Дело совсем не в вызове, я смотрел исходники delay_us в avrlib, там неоптимизированная задержка и на малых значениях действительно будет совсем другая задержка.
 

Вот исходник, если кому интересно (из тулчейна ArduinoIDE v1.0.5)

/**
   \ingroup util_delay

   Perform a delay of \c __us microseconds, using _delay_loop_1().

   The macro F_CPU is supposed to be defined to a
   constant defining the CPU clock frequency (in Hertz).

   The maximal possible delay is 768 us / F_CPU in MHz.

   If the user requests a delay greater than the maximal possible one,
   _delay_us() will automatically call _delay_ms() instead.  The user
   will not be informed about this case.
 */
void
_delay_us(double __us)
{
	uint8_t __ticks;
	double __tmp = ((F_CPU) / 3e6) * __us;
	if (__tmp < 1.0)
		__ticks = 1;
	else if (__tmp > 255)
	{
		_delay_ms(__us / 1000.0);
		return;
	}
	else
		__ticks = (uint8_t)__tmp;
	_delay_loop_1(__ticks);
}

Теперь не нужно калечить LiquidCrystal #15 для корректной работы на 12 мегагерц.

*проверил - всё работает.

Спасибо! А то пока не на чем проверить. ЛА подключать надо, по хорошему. Да прогнать по малым величинам.

Ребята, как решили проблему?...что-то я не вкурил) 

У меня кварц внутренний т.е. на 8 МГц...проблема в дисплее - вылазят иногда кракозяблы, хотя до этого вроде не было проблем сним и все работало. Решит ли эту проблему ваше решение?

Для 8 не нужен патч и так должно работать, я фиксил для 12МГц.
Могу предположить, что на 8 никто не тестил. К сожалению мне проверить сейчас не на чем

на 8 тестировал, вроде правильно все

Да у меня тоже работало всё....видимо причина в другом. Буду искать

Как правило задержки виноваты, если проблемы при инициализации, иначе может и питание, хотя у меня проблем не было ни с атмега16, ни с стм32, на Ардуино не пробовал.