esaulenka

Похоже на правду. Единственное послабление - драйвер не будет держать 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'е этого флажка, или прерывание с автоматическим его сбросом. Как-то не выглядит надёжно (хотя... никогда не интересовался временем реакции контроллера прерываний атмеги. Может быть, там с запасом... :-) ).

Разумеется... :-( PORTE &= ~(1<<PORTE5); //Установить на PE5 низкий уровень (разрешение приёма) Тут правильно. PORTE &= ~(0<<PORTE5); //Установка на E5 выскокого уровня (разрешение отправки) А тут должно быть PORTE |= (1<<PORTE5); И, по-хорошему, это должно быть двумя микро-функциями Drv485_TxEn() и Drv485_RxEn() Мне не нравится эта идея. Хотя бы потому, что в ATmega есть ДВА регистра в UART'е - data register, куда записываются данные из программы, и shift register, из которого собственно идёт отправка. Вы вот можете поручиться, что прерывание по отправке первого байта сработает ДО того, как в буфер попадёт второй байт? Я, правда, не сильно понял, как вообще работает бит TXC. Если верить документации, он автоматически сбрасывается прерыванием. Т.е., непонятно, можно ли в принципе надёжно опрашивать его в основном цикле при включённом соотв. прерывании. Миллион лет не видел атмегу и никогда не видел rs485, но предлагаю следующий алгоритм: запрещаем прерываение по передаче; включаем передатчик MAX485, отправляем свои 8 байт, ждём TX Complete, выключаем передатчик. Предварительно читаем в даташите о необходимости заранее сбросить флаг TXC. Вот на фразе "после чего" у меня возникли некоторые сомнения. В коде нет никакого "после чего" - отправили данные, и сразу же записали в еепром всякий мусор. Что-то удивительное творится. А что такое databuffer и чему равна j в начале цикла? ...то мы сразу же наступаем на грабли с битовыми масками (см. в начале моего сообщения). А вообще - что вам помешало сразу прицепить параллельно ваш вольтметр, атмегу и usb-485 ? Хоть какая-то отладка... PS вопрос больше к общественности. В modbus сразу можно регистры устройства читать, или при появлении его в сети его надо как-то сконфигурировать? Может, дополнительно ещё и с этим проблемы?

Изрядная часть GPIO у STM'ок - 5 volt tolerant, и туда можно безболезненно подавать куда бОльшее напряжение, чем 3 вольта.

Это, простите, настоящий код с настоящего боевого проекта? Можно только позавидовать Вашей внимательности и усидчивости.

У меня всё никак не дойдут руки сделать что-нибудь полезное в плане ЦОС (на работе не нужно, а дома других забот хватает), но для этой задачи я бы смотрел в сторону работ дядьки Гёрцеля.

... а нечто под названием "member reputation" - есть :-)

Спасибо. Потому что, очевидно, знать все мануалы невозможно. А на сайте ST я сразу не нашёл нужную табличку.

Погодите-ка. Есть STM8L в корпусе мельче SO-8 ? Мне вот тоже контроллер нужен. Минимум функционала, минимум потребления, минимум цены и минимум места. Тинька устраивает (хотя ток надо перепроверить ещё раз), stm8s003f3u, в принципе, тоже.

У objcopy из комплекта gcc, кстати, есть похожие --redefine-sym и --redefine-syms

Вероятно, надо было задуматься сильно заранее о пропускной способности шины :-) А вообще, арбитраж в CAN штука очень простая и одновременно очень мощная. Арбитраж выигрывает тот узел, который передаёт dominant state (т.е. ноль). Таким образом, тот узел, который передаёт пакет с бОльшим количеством нулей в начале (т.е. с меньшим идентификатором) автоматически выигрывает арбитраж. Вам остаётся только назначить правильные идентификаторы "критичным датчикам".

1) Да. Потеря арбитража - совершенно штатное явление в сколь-нибудь нагруженной шине. 2) Прочитать документацию. Bit 18 ALST2: Arbitration lost for mailbox 2. This bit is set when the previous TX failed due to an arbitration lost. Ещё там же есть биты 10 и 2. Впрочем, при нормальной работе с шиной эти флажки не очень нужны. Для диагностики разве что...

Нет, нету там такого. Максимум - можно auto retransmit отключить, чтобы отправлять только одно сообщение, а не "долбить" шину без подтверждений, пока счётчик ошибок не переполнится. Своё сообщение тоже обратно не принимается, даже если кто-то "снаружи" выставил ACK. В STM'овском reference прямо указаны костыли, которые включаются в случае loopback mode. Каких-то других методов включить приём передаваемых пакетов я не знаю.

Интересные сведения, спасибо. Жаль, что неправильные, ну да ладно, мелочи...

http://libopencm3.org/

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