esaulenka

Новый Unified Program and Debug Interface выглядит гораздо продвинутее старого debugWire'а. И с документацией сразу в даташите на камень. Как у него с обратной совместимостью, непонятно. Кажется, никак. Впрочем, я тот ещё специалист - последний AVR, под который я что-то писал, был ATmega8, с самым обычным SPI-подобным интерфейсом программирования.

Я пробовал "data logger" - мне выдали какие-то термометры-метеостанции-видеонаблюдение. А вот если "data logger shield" - всё становится гораздо интереснее. Спасибо. Видимо, так и сделаю - blue pill, этот самый шилд, МГТФ и термоусадка. Два. Хочется видеть передачу в обоих направлениях. Плюс нужна хорошая привязка этих двух каналов друг к другу: есть подозрения, что всё самое интересное начинается, когда пакет теряется и начинаются повторы (как водится, авторы протокола не подумали о сквозной нумерации пакетов)... Но вариант, да, спасибо. Спасибо. Несколько перебор, мне кажется.

А он вообще в принципе знает о новомодном 1-проводном способе программирования AVR'ок ?

Здравствуйте. Возникла необходимость логировать некую железку, которая общается с внешним миром по уарту. Делать какую-то плату очень не хочется. Что есть самое простое-дешёвое-компактное с SD-картой, 2 (лучше - 4-мя) уартами и, желательно, RTC ? Кстати, насколько софт-уарты на распберри работоспособны? Мнения в интернетах расходятся...

Похоже на правду. Единственное послабление - драйвер не будет держать dominant бесконечно, и достаточно быстро передатчик перейдёт в состояние ошибки.

К сожалению, на таком уровне понимания - закрыть куб, открыть ютуб, посмотреть 100500 роликов "стм+куб - моргаем светодиодиком". Когда доберётесь до роликов "осваиваем SPI", и поймёте, что там делают, можно возвращаться к имеющемуся кан-контроллеру. Не, можно, конечно, вбить в гугл "STM32 + MCP2551" (это вы тоже не делали?). Проблема только в том, что без понимания, что именно происходит, повторить даже пошаговую инструкцию будет сложно...

Ну, не очень хорошо, да. Хотя бы потому, что на фоточке написано 2551, а в Вашем сообщении - 2515. UPD: наоборот, конечно же. Чёртов микрочип, почему они такие похожие названия сделали? High-Speed CAN Transceiver и Stand-Alone CAN Controller with SPI Interface - штуки довольно-таки разные... Ну и было бы неплохо рассказать, а что же Вы сами уже сделали? Написали "подробно объясните мне всё" ? ...какой-нибудь заслуживающий уважения источник. Потому что от фразы "мой малыш в семи известном и любимом корпусе ATMEGA8 (LQFP32)" у местных жителей может и приступ случиться. Хорошо, если приступ хохота...

Вы не пробовали подобные вопросу гуглу задавать?

В этом даташите есть сноска, что PIC16LC - это то же самое, только низковольтовое. И да, eeprom там отсутствует.

К слову, у NXP где-то здесь был очень хороший appnote, как всё это работает.

Имеют, опосредственное. В тот момент, когда у вас появится много-много данных, и их надо будет затолкать в компьютер, а перед этим как-то предобработать, FPGA может пригодиться. Я, правда, не понял, откуда в этой штуковине (даже на 100+ каналов) МНОГО данных... Там характерная скорость изменения сигнала какая предполагается? Я не биолог совсем, но мне всегда казалось, что все биохимические процессы идут довольно медленно... PS а за статьи вам спасибо! Половина слов непонятна, но краем глаза посмотреть, какие сейчас космические корабли бороздят просторы биоинженерии, было очень интересно.

Какое-то странное лечение. По-хорошему, никаких пауз не надо. Если паузу убрать, переходник в компьютер отправленные байты видит? Вольтметр как запитан? Может, он просто запускается эти 1-2 секунды, а вы ему постоянно питание дёргаете? На первый взгляд, правильно всё написано... Предложения по отладке: - в прерывание на приём байта добавьте пересылку его в соседний порт. Скорость этого UART1 лучше поставить побольше (например, 115200), чтоб не мешал своими задержками. - также можно через некоторый промежуток (например, через секунду) после обмена с вольтметром отправить в этот UART1 всю интересующую информацию - в первую очередь, IndexStart / IndexEnd. - также ооочень рекомендую отладчик. Называется AVR JTAG ICE. Оригинал стоит каких-то неразумных, на мой взгляд, денег, но китайские клоны продаются за копейки (порядка 200 рублей). Правда, как работают клоны, я не знаю. "Пошагать" по программе у вас не получится (т.к. задействован вольтметр, а он ждать не будет), но посмотреть в любой момент значения переменных, да и за несколько секунд обновить программу - это очень упрощает работу.

В том месте, где вы брали кольцевой буфер, не было написано большими буквами, что его размер обязательно должен быть кратен степени двойки? В противном случае "магия" с маской работает совсем не так, как должна. И вот это безобразие: while (1) { if(get_data() == 0) //Если функция вернула 0, значит, в массиве нет новых данных { asm("nop"); //И тогда мы ничего не делаем } else if(get_data() == 1) //Если функция вернула 1, значит, какие-то данные всё же получены { read_byte_from_ring(local_buffer,index_number()); //Читаем полученные от вольтметра данные в local_buffer  } else { break; } uart_1_send(local_buffer[0]); //Отсылаем данные из local_buffer на ПК  } Должно быть как-то так: while (1) { if(get_data() == 1) //Если функция вернула 1, значит, какие-то данные всё же получены { char local; read_byte_from_ring(&local, 1); //Читаем полученные от вольтметра данные в local_buffer uart_1_send(local); //Отсылаем данные из local_buffer на ПК  }  }

Там какая-то наркомания с тем, куда в данный текущий момент указывает struct uip_udp_conn *uip_udp_conn; То есть я понимаю, конечно, что всё для фронта, всё для побе... лишь бы в мелкий 8-битник влезло, но с современными объемами памяти лучше использовать какие-то другие стеки, которые не позволят так легко стрелять себе в ногу.

TXC. TXCIE - это разрешение соотв. прерывания, только что в памяти освежал. Но тут вопрос чуть другой - что сработает первым - опрос в while'е этого флажка, или прерывание с автоматическим его сбросом. Как-то не выглядит надёжно (хотя... никогда не интересовался временем реакции контроллера прерываний атмеги. Может быть, там с запасом... :-) ).