Comments 13
вообще-то это ОДНА запись в регистр, если что
Не то, чтобы я так уж был на стороне MBED, но все-таки это изменение значения в регистре, так что если не использовать BitМapping, тут нужно 6 команд и где-то 6-8 тактов в зависимости от требуемых битов только на работу, не считая вызова. Конечно, это не 13*48=624 такта, но и не 1 такт.
Ну а теперь по существу — а зачем менять направление пина? Настроили на открытый коллектор, включили подпитку (или поставили внешнюю — я стараюсь так делать, уж больно нестабильные внутренние подпитки) подали нолик, подали единицу, сделали задержку и считывайте. Не может быть, чтобы библиотека такого не позволяла, если не позволяет, тогда да, в топку ее.
Возможно что и с открытым коллектором бы получилось, хотя тоже уже надо посмотреть глубже, чем предполагает фреймворк… Но вот для InterruptIn пина подать на него ничего нельзя штатными средствами…
Хм, а почему нельзя? Функция бросает отказ? Или просто не проходит информация? Надо будет посмотреть.
А так Вы верно вопрос подняли, но, похоже, что-то одно, или универсальность, или эффективность.
Почему нельзя? В классе просто нет соответствующей функции. Можно конечно свой класс написать, доступ к регистрам же есть :) Но это же опять сильно глубже чем просто взять и попользоваться фреймворком.
Да ладно, mbed — ну оберточка просто, коих множество… Они же туда (в контроллеры) всякие явы на пару с .NET подтягивают.
Ну для этого нужны контроллеры попроизводительнее чем Cortex M0…
я за .NET и прочие фреймворки типа джавы.
Потому что:
всё равно будет необходимость быстрого прототипирования и будет потребность переноса уже существующего кода для ПК и встраиваемых компов в МК. Особенно если задача рулить чем то простым и очень медленным, например климатом.

Я сам так делаю: пишу код на Си и отлаживаю и провожу юнит тесты для сигнальной обработки под MinGW 32 бита. А потом импортирую в 32 битный микроконтроллер. И когда сам взял Eclipse и допилил его до возможности компилировать под MinGW и STM32, то стало на порядок удобнее и быстрее вести разработку. И там и там GCC, оба 32 бита, и там и там исходники нормально работают и всё удобно и переносимо. В добавок у меня есть своя прослойка наподобии ардуино которая обеспечивает переносимость кода между всеми семействами STM32 и NXP которую я разработал лет 6 назад. Да у неё те же косяки с быстродействием как в данной статье, но в замен я просто забываю про конкретный камень и быстро делаю что мне надо и это работает как в производстве так и у клиентов замечательно.

А если нужно реально быстро ножками дёргать, например для управления двигателем или светодиодами RGB, то пожалуйста: есть FPGA, CPLD и замечательный язык AHDL где просто таблицей можно описать что тебе надо получить на выходе, в зависимости от входа и внутреннего состояния вообще не парясь как это будет внутри сделано. Плис реально ускоряют разработку — ты за час делаешь в лоб то, что настроить на таймерах STM32 займёт неделю. И часто плис нужна там где можно поднять себестоимость на 1000р смело, и даже на 10тр будет не так критично.
Так ведь и чистые С или ассемблерные вставки никто не запрещал, или во фреймворках они принципиально не доступны?
Доступны. Только инкапсуляцию нарушают, о чем и речь, собственно.
Я может ерунду сморожу… Но нельзя ли завести две ножки In, Out на стороне МК и подключить их параллельно к ножке датчика?
В общем-то можно. Если обеспечить, чтобы Out оставался «в воздухе» когда датчик ведет передачу. Но зачем тогда в библиотеке класс для InOut пина?
Видимо для небыстрых переключений. Если четко не задокументировано, то явная утечка в абстракции.
Вообще софтовая реализация кастомного протокола всегда небыстрая.

Я, кстати, потому долго возился с подбором частоты и битности SPI для протокола WS2811, что иначе Bit Banging производительность убьюет.
Автору спасибо! Теперь точно знаю, на чем и как лучше программить. Не ищите легких путей! А автору респект!
Only those users with full accounts are able to leave comments. Log in, please.