У нас enc нормально питается от Arduino. Хотя формально ток enc больше допустимого тока на пине 3.3В, регулятор остается холодным. В какой момент происходит зависание? Старые версии драйвера висли при большом потоке пакетов.
Понял. На следующей неделе выложу внизу статьи ссылку на репозиторий с кодом avr-etherboot для Arduino Mega, а также укажу в README, как этим пользоваться.
Работа с мегой через UDP очень простая: мы просто получаем и принимаем пакеты средствами библиотеки EtherCard.
Дополнительный трюк: делаем геттер для буфера данных библиотеки и при приеме/отправке читаем/пишем сразу туда, без «лишнего» буфера в коде вне библиотеки.
Не хотелось жертвовать стабильностью, все-таки, провода, тем более — Ethernet, стабильнее, чем воздух и этот чип.
Мы смотрели, I2C не хватит по длине. Хотели использовать RS-485, но там возни с проводами больше, чем в ethernet. Тут просто вставил и оно заработало, а там нужно разбираться с терминаторами. Также пришлось бы придумывать что-то с выдачей адресов, диагностикой и т.п., а тут уже готовые DHCP и ping.
Думали насчет умного дома, но, опять же, захотелось гибкости. Очень нехорошо бы вышло, если бы сделали все на умном доме X, а потом бы оказалось, что новая фича от заказчика нереализуема на нем.
Я имел в виду, что некоторые прерывания уже заняты. Например, millis() использует для работы значение, изменяющееся в timer0_ovf_vect, если не ошибаюсь.
Возможно, можно было и оставить их код целиком, каким-то образом доработав. Но поскольку хотелось минимизировать источники неожиданных моментов (а куча чужого кода является таким источником) и обеспечить максимальную гибкость, было принято решение использовать «мини-ядро».
Понял. На следующей неделе выложу внизу статьи ссылку на репозиторий с кодом avr-etherboot для Arduino Mega, а также укажу в README, как этим пользоваться.
Работа с мегой через UDP очень простая: мы просто получаем и принимаем пакеты средствами библиотеки EtherCard.
Дополнительный трюк: делаем геттер для буфера данных библиотеки и при приеме/отправке читаем/пишем сразу туда, без «лишнего» буфера в коде вне библиотеки.
Если нужно, могу этот код тоже выложить.
Он в открытом доступе есть же. Какой конкретно код вас интересует?
Мы смотрели, I2C не хватит по длине. Хотели использовать RS-485, но там возни с проводами больше, чем в ethernet. Тут просто вставил и оно заработало, а там нужно разбираться с терминаторами. Также пришлось бы придумывать что-то с выдачей адресов, диагностикой и т.п., а тут уже готовые DHCP и ping.
Думали насчет умного дома, но, опять же, захотелось гибкости. Очень нехорошо бы вышло, если бы сделали все на умном доме X, а потом бы оказалось, что новая фича от заказчика нереализуема на нем.
P.S. ISR всегда забивается кодом arduino, см. [arduino]/hardware/arduino/avr/cores/arduino/wiring.c
Поставить свой код нельзя:
Возможно, можно было и оставить их код целиком, каким-то образом доработав. Но поскольку хотелось минимизировать источники неожиданных моментов (а куча чужого кода является таким источником) и обеспечить максимальную гибкость, было принято решение использовать «мини-ядро».
Задания придумывает заказчик вместе со специально нанятыми сценаристами.
Конкретно этот проект писался в vim и Qt creator. Но отладчиком не пользовались, поэтому разницы особой нет.