Jump to content

    

nk@

Участник
  • Content Count

    77
  • Joined

  • Last visited

Community Reputation

0 Обычный

About nk@

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

Контакты

  • Сайт
    http://
  • ICQ
    0
  1. Цитата(rx3apf @ Apr 12 2011, 12:59) Я не знаю, какие там неработающие порты _Вы_ имеете, но больше пока никто не жаловался. Вы занимаетесь натуральным сочинительством на ровном месте. Прошу прощения, за резкие слова, день, мля, тяжеловатый выдался По теме: Я выше писал про FIFO и параллельную обработку итд итп. Если правильно реализовать, то общего времени приема "пачки" данных + время паузы достаточно, для выпихивания всего блока на 115200. FIFO потребуется не менее размера одной "пачки". Если все реализовать тщательно, то должно получится. С SPI не получится, тк клок внешний, бит 22, а он байт-ориентированный. Было-б 24 бита - самае оно, но увы. По качеству портов. У меня есть проект, где через com в устройство нужно загрузить firmware порядка 3.5МБ. Там протокольчик дуплексный вопрос-ответ, не я делал. Так вот у меня, на 2-х компах (чипсет nVidia), это получается через раз. Причина - в этих самых 1-2% отличия скорости (кварц 4МГц). Когда идет обмен с паузами - все хорошо, а вот дуплекс на большом объеме им не под силу. Единственный комп, в котором стоит Intel-овская мама, работает без проблем. Вот такая вечная молодость.
  2. Цитата(rx3apf @ Apr 12 2011, 11:46) На 115200 - прекрасно, ошибка менее двух процентов. И на 230400 тоже. Вы возьмите и посчитайте. 115200 вполне достаточно, если правильно организовать обмен. Вы ветку сперва прочитайте, а потом уже высказывайтесь. Цитата(rx3apf @ Apr 12 2011, 11:46) Ой, ну да ладно страсти-то какие-то рассказывать, а ? Какие-такие "подстройки фазы" ? Вот благодаря таким знаниям, мы имеем неработающие com-порты.
  3. Цитата(rx3apf @ Apr 12 2011, 00:38) Как раз наоборот - ведь вывод одного набранного байта это всего лишь один out Это если у Вас скорость порта заведомо выше скорости поступления данных, но у нас как раз наоборот(1.25Mbit ! против даже 1Мbit c FT-232). Прийдется организовывать FIFO, и по прерываниям с UART забирать данные, либо полингом смотреть статус UART в основном цикле, а это несколько больше одного out Цитата(rx3apf @ Apr 12 2011, 00:38) Однако на 20 MHz, пожалуй, реально. Реально даже если входные пакеты идут без пауз, непрерывно. А вот уложиться в паузу 9 mS - трудновато. На 20 MHz отправить в UART нереально. Т.е. отправить реально, а принять без ошибок, на 115200 - не выйдет. Сейчас у мамок com-порты отвратительные, с подстройкой фазы все очень плохо (особенно "радуют" мамки на nForce - чуть в сторону и приехали). Потери - гарантированы. Нужно либо кварц типа 14.7456 или 18.432, либо паять FT-232 и на нестандартной скорости шпарить через "виртуальный com port". И все-же советую tiny (например 2313) и заюзать TWI. Я уже так делал - нужно было принимать последовательности по 28 бит. Почему не использовать аппаратный сдвиговый регистр? Код найти постараюсь сегодня вечером, по крайней мере, метода проверена PS: Я уже решал подобную задачу, и тут прийдется сильно поэкономить тактики
  4. Цитата(stells @ Apr 11 2011, 22:07) 16 тактов на прием одного бита - сомнительно, на грани фола +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. Цитата(ukpyr @ Apr 11 2011, 12:19) после DC-DC - любой LDO с малым падением Я бы не советовал использовать линейные стабилизаторы, из-за низкого КПД. Речь ведь идет о батарейном питании, каждый микроампер*час сберечь надо Импульсничек - самый подходящий вариант. Кстати, в хороших светодиодных фонариках - именно такой подход. Цитататок не больше 100мА.. При таких условиях выбор будет достаточно большим. Выбирайте сами, исходя из удобства применения. Например 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. Цитата(SysRq @ Apr 11 2011, 12:15) Использовав память неопределенного размера Быть может, в задании вашем от вас хотят всего лишь new[]\delete[] для, к примеру, массива, с задаваемым с клавиатуры числом элементов, а вы городите что-то такое-эдакое... -- Ага, фрагментация, двукратное потребление памяти, и непрогнозируемые задержки на копированое данных. Идеально для стека, да Я нигде не говорил, что это идеальное решение. Стек, в виде связанного стека - это, по Вашему, экономный расход памяти
  8. Цитата(Станис @ Apr 11 2011, 10:47) А что тогда можно применить чтоб было стабильно +5В? например от пары батареек на 1,2В... Любой, подходящий по мощности, step-up импульсный стабилизатор. Их существует некоторое множество. Какой ток потребления нужен? Вот, например: http://www.national.com/pf/LM/LM2621.html#Overview
  9. Цитата(sergeeff @ Apr 10 2011, 22:23) А на кой в стеке realloc? Нужно выделить память под хранение данных стека. Первый раз понятно - malloc(). Далее надо добавить в стек данных, для чего нужно увеличить "вместилище" стека. Как - realloc() подходит идеально. А без realloc() - связаный список указателей. Что-нить типа CODEstatic 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. Странное поведение ATTINY44A

    Цитата(defunct @ Apr 11 2011, 01:12) Вывод немного другой. Вот такой: ваш "environment" был свободен от помех и с лично вашим программатором вроде бы проблем нет. Не буду этого отрицать Плохо, что топикстартер молчит, как рыба об лёд. Гадаем на кофейной (чайной) гуще И все-же никто не отписался о подобной проблеме, значит она не носит массовый характер. Интересно, где-же все-таки собака порылась?
  11. Цитата(sergeeff @ Apr 10 2011, 17:34) Вовсе не обязательно! Намек понятен, тока realloc() не во всех реализациях stdlib имеется. Надо-бы топикстартеру платформу и ОС уточнить
  12. Цитата(XVR @ Apr 10 2011, 18:29) Как найдете - напишите в Xilinx. Они не в курсе, что в их FPGA есть внутренний генератор Парень, кмк, имел ввиду PLL
  13. ATTINY10

    Мда, как ловко тема с tiny10 сползла на m16. Флуд абсолютно бессмысленный пошел. У топикстартера ни слова не было про светодиоды, а вы уже китайские гирлянды развесили Предлагаю обсудить новый интерфейс для программирования - TPI. У меня AVRISPmkII "заапгрейдился" студией и теперь умеет программить tiny4/5/9/10. Может кто-нибудь просветИт нас насчет поддержки этих чипов другими, самодельными программаторами? Это будет по теме.
  14. Странное поведение ATTINY44A

    Меня зацепило и я провел маленький эксперимент. Из стола извлечена плата, над которой производятся отладочные издевательства. Плата с mega16, импульсным стабилизатором 12V->5V, LCD1602, всякая мелочевка... Через TWI подключена QTouch клавиатурка. Все запитано 5V. Контроллер получает питание через ферритовый фильтрик, который отпаян, и вместо него включен тестер. Т.о. мы меряем потребления только контроллера. Чип на этой плате перешивался, думаю не меньше 1000 раз - тк на этой плате отлаживался достаточно большой проект, да еще и не один Ладно, пусть будет 500. Программатор - честный ATAVRISPmkII. Взял одинн из старых проектов, достаточно увесистый (использовано 82% flash). После инициализации всего железа, в цикле ожидания нажатия клавиши, (при нажатии генерится INT0) вставлен такой код CODE 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. Странное поведение ATTINY44A

    Цитата(defunct @ Apr 10 2011, 09:31) Пока причина не найдена - ни один вариант нельзя отбрасывать, каким бы нереальным он не казался. Т.е. Вы предполагаете, имеет место деградация чипов из-за количества перепрограммирования некачественным программатором? Но как это возможно? В чем физика процесса? Все-же, кмк, проблема в чем-то другом.