Comments 13
вообще-то это ОДНА запись в регистр, если чтоНе то, чтобы я так уж был на стороне MBED, но все-таки это изменение значения в регистре, так что если не использовать BitМapping, тут нужно 6 команд и где-то 6-8 тактов в зависимости от требуемых битов только на работу, не считая вызова. Конечно, это не 13*48=624 такта, но и не 1 такт.
Ну а теперь по существу — а зачем менять направление пина? Настроили на открытый коллектор, включили подпитку (или поставили внешнюю — я стараюсь так делать, уж больно нестабильные внутренние подпитки) подали нолик, подали единицу, сделали задержку и считывайте. Не может быть, чтобы библиотека такого не позволяла, если не позволяет, тогда да, в топку ее.
0
Возможно что и с открытым коллектором бы получилось, хотя тоже уже надо посмотреть глубже, чем предполагает фреймворк… Но вот для InterruptIn пина подать на него ничего нельзя штатными средствами…
0
Хм, а почему нельзя? Функция бросает отказ? Или просто не проходит информация? Надо будет посмотреть.
А так Вы верно вопрос подняли, но, похоже, что-то одно, или универсальность, или эффективность.
А так Вы верно вопрос подняли, но, похоже, что-то одно, или универсальность, или эффективность.
0
Да ладно, mbed — ну оберточка просто, коих множество… Они же туда (в контроллеры) всякие явы на пару с .NET подтягивают.
0
Ну для этого нужны контроллеры попроизводительнее чем Cortex M0…
0
я за .NET и прочие фреймворки типа джавы.
Потому что:
всё равно будет необходимость быстрого прототипирования и будет потребность переноса уже существующего кода для ПК и встраиваемых компов в МК. Особенно если задача рулить чем то простым и очень медленным, например климатом.
Я сам так делаю: пишу код на Си и отлаживаю и провожу юнит тесты для сигнальной обработки под MinGW 32 бита. А потом импортирую в 32 битный микроконтроллер. И когда сам взял Eclipse и допилил его до возможности компилировать под MinGW и STM32, то стало на порядок удобнее и быстрее вести разработку. И там и там GCC, оба 32 бита, и там и там исходники нормально работают и всё удобно и переносимо. В добавок у меня есть своя прослойка наподобии ардуино которая обеспечивает переносимость кода между всеми семействами STM32 и NXP которую я разработал лет 6 назад. Да у неё те же косяки с быстродействием как в данной статье, но в замен я просто забываю про конкретный камень и быстро делаю что мне надо и это работает как в производстве так и у клиентов замечательно.
А если нужно реально быстро ножками дёргать, например для управления двигателем или светодиодами RGB, то пожалуйста: есть FPGA, CPLD и замечательный язык AHDL где просто таблицей можно описать что тебе надо получить на выходе, в зависимости от входа и внутреннего состояния вообще не парясь как это будет внутри сделано. Плис реально ускоряют разработку — ты за час делаешь в лоб то, что настроить на таймерах STM32 займёт неделю. И часто плис нужна там где можно поднять себестоимость на 1000р смело, и даже на 10тр будет не так критично.
Потому что:
всё равно будет необходимость быстрого прототипирования и будет потребность переноса уже существующего кода для ПК и встраиваемых компов в МК. Особенно если задача рулить чем то простым и очень медленным, например климатом.
Я сам так делаю: пишу код на Си и отлаживаю и провожу юнит тесты для сигнальной обработки под MinGW 32 бита. А потом импортирую в 32 битный микроконтроллер. И когда сам взял Eclipse и допилил его до возможности компилировать под MinGW и STM32, то стало на порядок удобнее и быстрее вести разработку. И там и там GCC, оба 32 бита, и там и там исходники нормально работают и всё удобно и переносимо. В добавок у меня есть своя прослойка наподобии ардуино которая обеспечивает переносимость кода между всеми семействами STM32 и NXP которую я разработал лет 6 назад. Да у неё те же косяки с быстродействием как в данной статье, но в замен я просто забываю про конкретный камень и быстро делаю что мне надо и это работает как в производстве так и у клиентов замечательно.
А если нужно реально быстро ножками дёргать, например для управления двигателем или светодиодами RGB, то пожалуйста: есть FPGA, CPLD и замечательный язык AHDL где просто таблицей можно описать что тебе надо получить на выходе, в зависимости от входа и внутреннего состояния вообще не парясь как это будет внутри сделано. Плис реально ускоряют разработку — ты за час делаешь в лоб то, что настроить на таймерах STM32 займёт неделю. И часто плис нужна там где можно поднять себестоимость на 1000р смело, и даже на 10тр будет не так критично.
0
Я может ерунду сморожу… Но нельзя ли завести две ножки In, Out на стороне МК и подключить их параллельно к ножке датчика?
0
В общем-то можно. Если обеспечить, чтобы Out оставался «в воздухе» когда датчик ведет передачу. Но зачем тогда в библиотеке класс для InOut пина?
+1
Видимо для небыстрых переключений. Если четко не задокументировано, то явная утечка в абстракции.
Вообще софтовая реализация кастомного протокола всегда небыстрая.
Я, кстати, потому долго возился с подбором частоты и битности SPI для протокола WS2811, что иначе Bit Banging производительность убьюет.
Вообще софтовая реализация кастомного протокола всегда небыстрая.
Я, кстати, потому долго возился с подбором частоты и битности SPI для протокола WS2811, что иначе Bit Banging производительность убьюет.
0
Автору спасибо! Теперь точно знаю, на чем и как лучше программить. Не ищите легких путей! А автору респект!
0
Sign up to leave a comment.
MBED, или о дырявых абстракциях