GDI

Тут надо определить что главнее индикация или чтение температуры, по моему индикация главнее, к тому же температура читается неоправданно часто. При 12бит разрешении что устанавливается для датчика температуры, он преобразование температуры делает 750мс. Температуру надо читать не чаще этого времени, я в свое время читал температуру раз в секунду, правда библиотеку от CodeVision-а пришлось заменить самопальной и там уже был полный контроль над процессом считывания температуры, в нужных местах стояли запреты прерываний, потому никакие другие прерывания, а их в системе было много, не мешали.

VNC1L тут вряд ли поможет, разве что внутрь встроить ЮСБ-Хаб и к нему подключить флешку и само устройство, ведь само устройство, как я понял, тоже имеет интерфейс ЮСБ. Другой вариант - брать контроллер с ЮСБ и реализовывать там мультидевайс из масс-стораджа и собственной функциональности устройства. Выбо за Вами, что вам по цене/трудоемкости дешевле реализовать.

А сигнал CS вас на каждый байт будет или на всё сообщение? Какова длина линии передачи и в каких условиях она будет работать, цех, лаборатория и т.п., где будет использоваться ваше устройство? Вообще то нормальные протоколы имеют признаки начала пакета, это может быть какой-то специальный символ или пауза в передаче, как в ModbusRTU, или, в вашем случае это может быть отдельный сигнал CS, тогда он должен переходить в "0" в начале пакета, и подниматься в "1" после передачи последнего 12го байта. Еще нормальные протоколы имеют контроль целостности пакета в виде какой-то контрольной суммы, передаваемой в конце пакета.

Для начала, SPI - это интерфейс, а не протокол, а вот Ваши передачи по 12 байт - это уже некий протокол, но не называйте его SPI. Ответ очевиден - посчитать байты в прерывании, т.е. вести некую переменную как счетчик байтов, после принятия 12 байт, его нжно обнулять. Не совсем понятно как Вам надо работать, у Вас сперва мастер передает 12 байт, а потом дает еще 96 имрульсов на SCK чтобы считать Ваш ответ или Вы должны отвечать байтом ответа на каждый принятый байт? Да и вообще, слишком мало данных Вы даете по Вашей задаче.

Это хорошие слова, еще чуть-чуть и будет конечный автомат, осталось только отказаться от манипуляций со стеком и выходов из прерываний не по reti.

А сколько длится обработка предыдущей команды? Там тоже есть что-то для задержек? Но самое правильное решение - сделать конечный автомат, очень рекомендую изучить что это такое, тогда у Вас из лексикона уйдет слово "немогу".

Вот потому я и сказал что у вас глобальная мысль идет неверно. Как вы эту задержку делаете, пустым циклом, что мешает в этот пустой цикл вставить проверку нажатия кнопки и выход на нужную подпрограмму? вариант по сложнее - сделать задержку sleep-ом, с периодическим просыпанием по прерыванию от таймера с подсчетом прошедшего времени и засыпанием дальше (либо заводить двигатель для прогрева) и по прерыванию от кнопки с соответствующими действиями. Ну, а про то что вешать кнопку на прерывание не есть хороший тон, вам уже выше написали, как минимум в этом прерывании нужно сделать компенсацию дребезга, а то вы рискуете с вашим методом перезаписи стэка. В общем есть корректные пути решения проблем. P.S. Надеюсь, Вы делаете проверку что передача не включена перед стартом двигателя? P.P.S. Может стоит перейти на Си, чтобы решать задачи без усложнения кода?

Вместо такого описания, лучше бы нарисовали алгоритм, а там, глядишь и сами бы разобрались как надо правильно сделать. Я ничего не понял из Вашего описания, но у меня создалось стойкое ощущение что у Вас что-то глобально не правильно в программе, т.е. сама концепция программы не верна. И что значит "команды от кнопок будут обрабатываться мгновенно не дожидаясь выполнения подпрограмм"?

Я в то время работал с этим программатором на CentOS 4, и ничего не отключалось. А для помощи мало данных, надо бы каким-нибудь сниффером посмотреть что там на шине юсб происходит. Вот сообщение http://electronix.ru/forum/index.php?showt...st&p=822176 у человека под дебианом работает. Для ХИД не нужны никакие патчи ядра, попробуйте с непатченным ядром сперва.

Может камень в конверт и почтой? :)

Нет, та прошивка называлась именно "mydoper", она работает по протоколу STK500. Насколько я помню, она работает медленнее чем AVR910-USB с AVRProg, но с остальными программами типа AVRStudio, AVRDoper, она работает быстрее. Это прошивка от программатора AVRDoper, но адаптированная к железу AVR910-USB Prottossa.

Я работал с этим программатором под Линуксом, только прошивка была mydoper - переделанный под данное железо AVRDoper и работала она в режиме HID. Исходник этой прошивке я брал в этой теме и перекомпилировал его на поддержку HID. Тут где то еще была тема про работу с АВР с Линуксе, там я описывал что-то, было это давно, года 3-4 назад. Примерно в то-же время я делал сравнение скорости работы программатора с разными прошивками (1.05 и Mydoper), это было так же 3-4 года назад.

Вы, наверное, не знаете что есть AVReal и иже с ним AVRDude?

Если есть часовой кварц для часов, то можно и от него калиброваться.

Что мешает сперва стереть всё, а потом зашить прогу и массив без промежуточного стирания?

Для ответа на этот вопрос надо знать какой у Вас компилятор. Как правило в препроцессоре есть директивы по размещению констант по определенному адресу. Но вот не помешает ли это линкеру размещать остальные переменные и саму программу?

А зачем использовать транзисторы? Нельзя этот резистор завести на какую-то ножку контроллера и ей управлять? Просто нужно будет пересчитать его сопротивление, если контроллер питается напряжением отличным от 3.3В. Такой способ управления широко используется в тех же FTDI и других специализированных контроллерах, там же никто не ставит внешних транзисторов для этого.

Мы сейчас в проекте используем часы М41Т93, так они кушают 365нА (самое оно для нано-часов:)), ионистора на 1Ф хватает на 20 дней. У них еще и кварц встроенный, так что не надо париться с кварцем и его подключением, да чтоб не убегало и не отставало и с завода +/-5ппм обещают.

А чем не подходит метод описанный в AVR121: Enhancing ADC resolution by oversampling? Там можно и до 16 бит довести при полосе пропускания 3Гц. И шум опорного напряжения там не мешает, а наоборот его даже специально усиливают.

Почему бы не применить 20-мегагерцовые атмеги?

RS485 не годится? И модбас на нем и тогда, если в будущем, понадобиться, то можно без переделок сделать и 10, и 30 метров расстояние. Можно и развязать его при желании, хотя сейчас есть драйверы которые позволяют работать при перекосах питания до 70в. И еще один плюс - надо всего 2 провода, землю тянуть не придется.

Конечно будет работать, для того и придуманы эти переходники, более того в вашем программаторе этот переходник реализован программным способом.

Это же opensource! Если Вам что-то надо, то сделайте это сами. Правда есть проблема: те кому надо, обычно не могут, а когда они дорастают до момента когда смогут, то им уже и не надо :). "Начинающие" могут только попробовать как-либо заинтересовать "Гуру", чтобы те допилили что-то. Как минимум надо составить грамотное ТЗ.

Кстати, возвращаясь к Maxim-у с его iButton, там есть таблетки и с шифрованием, с однократной записью, с защищенными адресами в памяти и много чего еще, я не интересовался никогда этими вопросами, просто слышал что у них есть подобные возможности. Правда и цена на такие вещи довольно высока.

Чтож Вы такое выпускаете, что Вас даже Китайцы подделывают? Может Вам тоже свое производство в Китае разместить, чтоб уровнять себестоимость?