fk0

Ну даконечно. Мокрософт поработил... DOS не нужен. ВООБЩЕ. Ламукс лучше дос чем дос.

[CENSORED] С такой дискредитацией чуть ли не софтварно делается DDS с синусом. На выходе понятно band pass на операционнике. Меандром тоже можно, но, как ни странно, трудней даже ввиду ограничений на коэффициент делителя и тактовую счётчика. Но среди AVR'ок помнится были у которых ядро на ~16МГц, а счётчики и т.п. на все 64. Кажется, что-то из мелких тиней.

Адекватные ассемблеры позволяют @@locallabel или накрайнял числовые метки вида "3:". Все вопросы к билу гейцу.

5 раз смотрел, ничего не понял. Я знаю, что для кодировании информации выбора одного из N надо минимум log2(N)+1 битов. А тут ерунда какая-то. Напиши какие значения этого бита у 9 последовательных записей. (т.е. чистый флеш, записали раз, записали два...) Сколько кстати блоков флеша? Не больше 8-и? Если это работает, значит старые записи таки переписываются, хотя бы этот бит сбрасывается.

По сути да.

У меня тоже счётчик. Надо сказать с ним есть непределённость определённая... Вобщем или кодов для счёта будет БОЛЬШЕ числа страниц flash для перезаписи. Или нельзя сказать чётко какая последняя. С битом -- это по-моему бред. Как там последнюю найти? Только если не удалять сразу неактуальные записи. Я вот не удаляю, стираю только при записи. А дописываю как есть по кругу (есть пул flash-страниц для циклической перезаписи). Да, когда у меня было всего 2 страницы в другом приборе, там было 2 БИТА. Ибо по 1 биту нифига непонятно кто последний в таком случае. А так есть серия номеров последовательно с разрывом (зацикленность опускаем), соответственно тот что перед разрывом -- последний. Поэтому номеров и БОЛЬШЕ должно быть чем страниц. Да, про неопределённость. Это когда разрывов в нумерации больше одного. Тут хоть по rand() выбирай нужный блок...

Коллекторные сасут. Ибо BLDC (безщёточные) позволяют рулить синхронно в т.ч. даже если без интегрированных датчиков холла. По обратной ЭДС в обмотке определяется положение ротора. У атмела есть аппнота (ключевые слова brushless, bldc motor control). Никаких энкодеров действительно не надо в таком случае. Ключевое слово -- синхронно. ПИД не нужен.

Куда смотреть? См . application note AVR446... Да, грабли с переполнением или потерей точности в целочисленных вычислениях там разложены весьма хорошо (и в аппноте тоже...) Там в конце ссылка на оригинал, рекомендуется сравнить с аппнотой в плане формул. Чо за кривая я вообще х.з. Я думаю разгон с постоянным ускорением рационален в том смысле, что если со скоростью не растёт сопротивление и не падает мощность движка -- это разумно в физическом смысле (что в реальности, увы, не совсем так). График скорости от времени ниже: ________________________ / \ / \ / \ / \ / \ / \ |<>|<-------------->|<>| уск. равн. движ. тормоз (по вертикали скорость, по горизонтали *время* (а не шаги для ШД)...)

Только эти клятые москали себе позволяют забывать о существование жизни за МКАД. Тут и думать нечего.

Оптимизация стартовых скриптов. Сам линух грузится за пару-тройку секунд. Я ниасилил, что ЭТО, но для работы с linux нужен linux, а не DOS или windows. Linux конечно можно запустить из доса. Но абсолютно не нужно. Вам необходимо просто иметь ОБРАЗ СИСТЕМЫ на любом подходящем (например, compacf flash через переходник в IDE) носителе, который вы на обычном ИБМ-ПЦ с установленным линухом доведёте до ума и переставите накопитель в специальный компутер.

В таком случае надо отключить TWI модуль от ножек и вручнуню манипулируя SCL и SDA на мастере выдать 8 битов и выдать stop condition. Чтоб слейв отключился. Помогает восстановить связь только аппаратный резет. :-))) Вариации на тему ёмкости нагрузки, подскакивания земли из-за тока нагрузки, прилетание помехи по воздуху -- всё может быть. Как и некорректная обработка прерываний (пока флаг не сбросишь, внутренний автомат дальше не продвинется). Вообще у AVR вроде не глючит. Не то, что у AT91SAM7...

СТАНДАРТНАЯ -- это описанная в соответствующем стандарте. Так вот ни в каком из cprintf никогда не было. Это, подозреваю, огрызки библиотеки фирмы Hitech или чего-то микрочиповского. И не в памяти, а в "консоли" (х.з. вообще что там является консолью). Видимо в uart таки. Ибо Console printf. Вот у hitech точно есть: int _doprnt(void (*cputc)(char), const char *fmt, va_list args); int cprintf(const char *fmt, ...) { va_list args; va_start(args, fmt); _doprnt(putch, fmt, args); va_end(args); return 0; /* num. of printed chars... */ } Через putch куда-то оно попадает. Ну да. Там ламиры с плавучкой софты пишут, а тут мегаспециалисты прямо инты в порт пихают. Конечно с потерей. Сколько именно? Считал? Ну да конечно. Вот ещё загадка. Как в таком канале понимать, что один инт кончился и пошёл следующий? Нет, мне в принципе понятно, что он может даже не инт, а uint16_t в little endian и занимает 2 байта. Вопрос после какого из байтов он кончился? Можно. Как *не нужно* это делать: fwrite(&variable_of_double_type, sizeof(double), 1, stdout)... Как *нужно* это делать: printf("%lf\n", variabla_of_double_type). Ещё можно задаться вопросом, что использовать double для представления значения 10-разрядного АЦП -- это перебор (при том что float 24-разрядный в первом приближении... кроме того на мелких платформах часто double эквиэвалентен float'у).

Пусть ADC -- будет 10-битным регистром или переменной, содержащей считанное из АЦП значение. Пусть также ADC_REF будет значением опорного напряжения АЦП. А ADC_BITS -- разрядность АЦП. Тогда напряжение в вольтах можно получить как ADC_REF * ADC / (1<<ADC_BITS) - 1). Поскольку выполнение вычислений с плавающей точкой в пик-контроллерах любительского уровня типа AVR затруднительно, а необходимая точность вычислений ограничивается всего парой десятичных знаков можно перейти к вычислениям как бы с фиксированной точкой. А на самом деле посчитать всё в целых числах, попросту домножив всё подряд на вес этих двух разрядов -- на 100. А дробную часть отбросив. При этом правда вместо округления (как это получается, если выводить десятичные числа через printf() -- там всё *непросто* кто тут против printf() выступает, особенно с плавучкой -- чаще ламиры) получится целая часть числа во-первых, но это легко исправляется прибавлением ещё 0.5 единицы (хорошо, умножаем на 200, прибавляем 1, потом делим на 2) и некорректно обрабатываются отрицательные числа -- на последнее мы забьём, ибо там много возиться и легко облажаться со знаком и правильным округлением. Т.е. что мы имеем: DeciVolts = (200 * ADC_REF * ADC / ((1<<ADC_BITS)-1) + 1) / 2; Если CPU умеет легко умножать на произвольные числа на этом можно и остановиться. Т.е. вывести вначале значение Volts = DeciVolts/100, потом точку, а потом DeciVolts % 100. Да, при умножениях надо оценивать необходимую разрядность переменных. Если процедура умножения для CPU занимает эдак 1500 тактов... А деления аж а 2000... Как может быть на Z80 (мегарулез всех времён и народов). Тогда быстренько становится заметным, что деление на 2, на (1<<ADC_BITS) заменяется сдвигами. Домножать для простоты (путём переноса младшего байта в старший и так далее) на 256 и получить число несколько подвышенной точности, которое один хрен потом на 10 много раз делить для перевода в десятичную систему. И что можно вообще не делить, а умножать и не в двоичной, а в двоично-десятичной. Только рассказывать это всё я ниасилю. С листингами на ассемблере тем более. Особенно если незачем и не для кого. [/code] А для вывода чисел есть printf(). То что он тяжёлый и тормозит -- для плавающей точки оправдано вполне, а без плавающей точки нифига он не тормозит, только не всякая библиотека умеет позволять плавающий или только целочисленный printf() -- вот это немножко проблема для мелких контроллеров где мало ПЗУ. Если это так беспокоит можно свой написать для только int, листинги 10000 раз приводили уже... Ну эта как бы HTTP. Он там тип в заголовке потока передаёт... Прo mime-кодирование в электронной почте тоже рассказывать? Там просто меганеэффективно. Это, мягко выражаясь, информация не соответствующая действительности. Через RS232 передаются символы. Вплоть до 5-битных. Или 9-битных. A через TCP сокет не только байты могут приходить. Впрочем по RS232 тоже. Угу. Вся виндовс -- это жосткое порно. Я полностью поддерживаю это мнение. Ну да. Вопрос чиста конкретный. КАК ПРИНЯТЬ НА ПЦ int. А это ничего, что даже в области эхотага он вот из моей практики чиста с самыми что ни на есть любительскими и ширпотребными пик-контроллерами фирмы Atmel и Cygnal, int аж тремя разными методами передаётся? И только один из них совпадает с тем, в котором он хранится в памяти ПЦ.

SUPER-что? Напряжения в виде "Зю" -- это сильно конечно. Не представляю себе как это даже. dtostrf() -- это какая-то внутренняя функция конкретной C-библиотеки. В нормальных программах такие функции использовать нельзя. да и не особо должно получаться ибо их и в *.h файлах быть не должно. Для перевода числа в заданной системе счисления из строки в собственно число есть функция strotol(), например и родственные. Это в современных библиотеках. В не очень современных можно положиться на sscanf() (для 8-ричных, 10-ричных и 16-ричных чисел только). Для чисел с плавающей точкой -- strod() или sscanf(). Вообще рекомендуется прочтение что-либо, дающего обзорную информацию по стандартной библиотеке C. Хотя бы info libc (имеется ввиду документация GNU Libc выпущенная FSF -- у них прямо с сайта читать можно).

Матрица 128x128. google://KS0108. По-моему очевидно. Разъём у них у всех почти (дисплеев) одинаковый, умом дойти если что во всяком случае можно по аналогии с винстаровскими, например.