Jump to content

    

nk@

Участник
  • Content Count

    77
  • Joined

  • Last visited

Community Reputation

0 Обычный

About nk@

  • Rank
    Частый гость
  • Birthday 08/12/1969

Контакты

  • Сайт
    Array
  • ICQ
    Array
  1. Прошу прощения, за резкие слова, день, мля, тяжеловатый выдался :cranky: По теме: Я выше писал про FIFO и параллельную обработку итд итп. Если правильно реализовать, то общего времени приема "пачки" данных + время паузы достаточно, для выпихивания всего блока на 115200. FIFO потребуется не менее размера одной "пачки". Если все реализовать тщательно, то должно получится. С SPI не получится, тк клок внешний, бит 22, а он байт-ориентированный. Было-б 24 бита - самае оно, но увы. По качеству портов. У меня есть проект, где через com в устройство нужно загрузить firmware порядка 3.5МБ. Там протокольчик дуплексный вопрос-ответ, не я делал. Так вот у меня, на 2-х компах (чипсет nVidia), это получается через раз. Причина - в этих самых 1-2% отличия скорости (кварц 4МГц). Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу. Единственный комп, в котором стоит Intel-овская мама, работает без проблем. Вот такая вечная молодость.
  2. Вы возьмите и посчитайте. 115200 вполне достаточно, если правильно организовать обмен. Вы ветку сперва прочитайте, а потом уже высказывайтесь. Вот благодаря таким знаниям, мы имеем неработающие com-порты.
  3. Это если у Вас скорость порта заведомо выше скорости поступления данных, но у нас как раз наоборот(1.25Mbit ! против даже 1Мbit c FT-232). Прийдется организовывать FIFO, и по прерываниям с UART забирать данные, либо полингом смотреть статус UART в основном цикле, а это несколько больше одного out :) На 20 MHz отправить в UART нереально. Т.е. отправить реально, а принять без ошибок, на 115200 - не выйдет. Сейчас у мамок com-порты отвратительные, с подстройкой фазы все очень плохо (особенно "радуют" мамки на nForce - чуть в сторону и приехали). Потери - гарантированы. Нужно либо кварц типа 14.7456 или 18.432, либо паять FT-232 и на нестандартной скорости шпарить через "виртуальный com port". И все-же советую tiny (например 2313) и заюзать TWI. Я уже так делал - нужно было принимать последовательности по 28 бит. Почему не использовать аппаратный сдвиговый регистр? Код найти постараюсь сегодня вечером, по крайней мере, метода проверена:) PS: Я уже решал подобную задачу, и тут прийдется сильно поэкономить тактики :)
  4. +1 вот-вот + время на укладку байтов в FIFO. Да еще и в UART надо запхнуть. Время между пачками скока? 1.28*7 = 8.96 милисек. Вам, чтоб выпхнуть 37 слов на скорости 115200 потребуется 37*(22/8)*1000/(115200/10) = 9.63 милисека. Нужно параллельно с приемом данных, отправлять в UART. Без прерываний параллельную отпраку не сделать нормально. С прерываниями - софтверный прием обосрётся. Выводы неутешительны. Хотя можно подвесить FTDI-232 и запулить на 1Mbit. Вижу 3 варианта - 1. Внешний сдвиговый регистр, лучче CPLD, как посоветовал kovigor + UART на повышенной скорости. 2. Берите ARM 3. Cлабая надежда есть, на нестандартное использование модуля TWI - кмк, единственный шанс реализовать на AVR, без внешних схем. PS: 3-й вариант возможен тока на TWI tinyAVR. Еслиб было 24 бита - можно было-бы использовать SPI, но это не наш случай. PPS: Щас еще раз глянул даташиты - на tiny должно получиться c TWI. На mega TWI шибко умный, ничего не выйдет.
  5. Насчет кондерчиков по питанию, т.н. decoupling capacitors, у производителей микросхем всегда есть рекомендации. Читайте даташиты, там всегда есть требования на каком расстоянии от вывода микросхемы, и какую емкость нужно установить. Насчет развязок аналоговых и цифровых питаний рекомендуется почитать Application Notes (AN) и посмотреть Reference design плат. Это чтоб не гадать на кофейной гуще :) Я это к тому говорю, что многое уже давно придумано до/для нас :)
  6. Я бы не советовал использовать линейные стабилизаторы, из-за низкого КПД. Речь ведь идет о батарейном питании, каждый микроампер*час сберечь надо :) Импульсничек - самый подходящий вариант. Кстати, в хороших светодиодных фонариках - именно такой подход. При таких условиях выбор будет достаточно большим. Выбирайте сами, исходя из удобства применения. Например MAX756 (просто в столе валялся): Operates Down to 0.7V Input Supply Voltage, 87% Efficiency at 200mA, 60μA Quiescent Current Набираете в google слова "DC-DC step-up converter 5V 100mA" и выбираете то, что больше подходит.
  7. Я нигде не говорил, что это идеальное решение. Стек, в виде связанного стека - это, по Вашему, экономный расход памяти
  8. Любой, подходящий по мощности, step-up импульсный стабилизатор. Их существует некоторое множество. Какой ток потребления нужен? Вот, например: http://www.national.com/pf/LM/LM2621.html#Overview
  9. Нужно выделить память под хранение данных стека. Первый раз понятно - malloc(). Далее надо добавить в стек данных, для чего нужно увеличить "вместилище" стека. Как - realloc() подходит идеально. А без realloc() - связаный список указателей. Что-нить типа static int *stack_mem = NULL; static unsigned int stack_pointer = 0; int* stack_push(int data) { stack_mem=(int* )realloc(stack_mem, (stack_pointer+1)*sizeof(int)); if(stack_mem==NULL) return NULL; //out of mem stack_mem[stack_pointer++] = data; return (stack_mem + stack_pointer - 1); } int* stack_pop(int* data) { if(stack_pointer) { *data = stack_mem[--stack_pointer]; return (stack_mem + stack_pointer); } return NULL; //no data in stack } PS: Код есс-но надо доработать, я его за 10 сек "на коленке" набросал, чтоб идею пояснить :)
  10. Не буду этого отрицать :) Плохо, что топикстартер молчит, как рыба об лёд. Гадаем на кофейной (чайной) гуще И все-же никто не отписался о подобной проблеме, значит она не носит массовый характер. Интересно, где-же все-таки собака порылась?
  11. Намек понятен, тока realloc() не во всех реализациях stdlib имеется. Надо-бы топикстартеру платформу и ОС уточнить :)
  12. Парень, кмк, имел ввиду PLL :)
  13. ATTINY10

    Мда, как ловко тема с tiny10 сползла на m16. Флуд абсолютно бессмысленный пошел. У топикстартера ни слова не было про светодиоды, а вы уже китайские гирлянды развесили Предлагаю обсудить новый интерфейс для программирования - TPI. У меня AVRISPmkII "заапгрейдился" студией и теперь умеет программить tiny4/5/9/10. Может кто-нибудь просветИт нас насчет поддержки этих чипов другими, самодельными программаторами? Это будет по теме.
  14. Меня зацепило и я провел маленький эксперимент. Из стола извлечена плата, над которой производятся отладочные издевательства. Плата с mega16, импульсным стабилизатором 12V->5V, LCD1602, всякая мелочевка... Через TWI подключена QTouch клавиатурка. Все запитано 5V. Контроллер получает питание через ферритовый фильтрик, который отпаян, и вместо него включен тестер. Т.о. мы меряем потребления только контроллера. Чип на этой плате перешивался, думаю не меньше 1000 раз - тк на этой плате отлаживался достаточно большой проект, да еще и не один :) Ладно, пусть будет 500. Программатор - честный ATAVRISPmkII. Взял одинн из старых проектов, достаточно увесистый (использовано 82% flash). После инициализации всего железа, в цикле ожидания нажатия клавиши, (при нажатии генерится INT0) вставлен такой код DDRA = 0; All ports - input DDRB = 0; DDRC = 0; DDRD = 0; SFIOR |= 1<<PUD; //disable pull-ups set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_enable(); sei(); sleep_cpu(); sleep_disable(); Теперь результаты: При переходе в слип - ток потребления оказался порядка 30mкA! WTF? Оказалось, ток кушал программатор, при его отключении, ток сразу стал 0,9-1mkA :) Может у топикстартера такая-же проблема? Достал из коробки старенький ByteBlasterII - самопальный, LPT. Сделал 50 перепрошивок с помощью avrdude, с полным стиранием. Результат не удивил 0,9-1mkA. Вывод - деградация от количества перепрограммирований не обнаружена. PS: Еще нюанс замечен. При поднесении руки к плате ток начинает расти до 1.2 - 1.3 мкА - очевидно, сказываются наводки на "висящие в воздухе" ноги.
  15. Т.е. Вы предполагаете, имеет место деградация чипов из-за количества перепрограммирования некачественным программатором? Но как это возможно? В чем физика процесса? Все-же, кмк, проблема в чем-то другом.