Комментарии 14
отличная интересная статья, спасибо!
Насколько глубоко реализована поддержка периферии? Таймеры, интерфейсы, USB — можно задействовать?
Кстати, mini-USB для питания использовать необязательно. Если соединить PA9 с 5V плата будет питаться от micro-USB.
Кстати, mini-USB для питания использовать необязательно. Если соединить PA9 с 5V плата будет питаться от micro-USB.
В избранное!
Вопрос про переферию меня тоже интересует, что то нигде не нашёл информацию как у них дела с переферией в порте обстоят…
Вопрос про переферию меня тоже интересует, что то нигде не нашёл информацию как у них дела с переферией в порте обстоят…
тоже имею такую плату, но пока дальше побаловаться встроенной прошивкой (эмуляция мыши управляемая через акселерометр) не зашло.
Проделал все указанное в статье, в целом всё работает. Несколько замечаний:
1. Делать Erase Chip и Erase Sectors имхо излишне — во-первых эти два пункта делают одно и тоже, во-вторых при прошивке все равно выполняется очистка. Но это мелочь.
2. После прошивки Tinibooter.hex система отказывалась видеть плату, резет или переподключение mini-USB ничего не дало. Помогла кнопочка Disconnect в ST-Link Utility.
3. В студии при нажатии Deploy Project система ушла в BSOD. Deploy Solution выполняется вроде бы успешно. Отладка работает!
4. С целью оценить оверхед, добавляемый фреймворком, заменил тело цикла на много повторяющихся строчек:
Итог довольно печальный: частота полученного сигнала ~47кГц. Для сравнения на чистом С будет 84МГц. Таким образом, разница в 3 порядка.
На «побаловаться» — сойдет. Но для чего-то более-менее серьезного пока сыровато. ПиСишный .NET хорош тем, что при запуске приложения IL компилируется в нативный код, поэтому особой разницы в производительности нет. Здесь же этого, видимо, не происходит (хотя я ожидал, что это произойдет при заливке кода на плату), поэтому имеем тормоза.
1. Делать Erase Chip и Erase Sectors имхо излишне — во-первых эти два пункта делают одно и тоже, во-вторых при прошивке все равно выполняется очистка. Но это мелочь.
2. После прошивки Tinibooter.hex система отказывалась видеть плату, резет или переподключение mini-USB ничего не дало. Помогла кнопочка Disconnect в ST-Link Utility.
3. В студии при нажатии Deploy Project система ушла в BSOD. Deploy Solution выполняется вроде бы успешно. Отладка работает!
4. С целью оценить оверхед, добавляемый фреймворком, заменил тело цикла на много повторяющихся строчек:
led.Write(true); led.Write(false);Итог довольно печальный: частота полученного сигнала ~47кГц. Для сравнения на чистом С будет 84МГц. Таким образом, разница в 3 порядка.
На «побаловаться» — сойдет. Но для чего-то более-менее серьезного пока сыровато. ПиСишный .NET хорош тем, что при запуске приложения IL компилируется в нативный код, поэтому особой разницы в производительности нет. Здесь же этого, видимо, не происходит (хотя я ожидал, что это произойдет при заливке кода на плату), поэтому имеем тормоза.
Для высокоуровневой логики и GUI — самое оно, чтоб не на С его клепать.
А там где скорость нужна, понятное дело, не стоит дотнет юзать.
А там где скорость нужна, понятное дело, не стоит дотнет юзать.
Я заранее прошу прощения. Далёк от схемотехники и embedded.
Вы говорите что на процессоре с частотой около 80Mhz (http://www.ti.com/ww/ru/mcu/cortex_m4f/) у вас тело цикла состоящее из 2х инструкций выполнялось с частотой 84Mhz?
Наверное я чего-то не понимаю. Объясните пожалуйста.
Вы говорите что на процессоре с частотой около 80Mhz (http://www.ti.com/ww/ru/mcu/cortex_m4f/) у вас тело цикла состоящее из 2х инструкций выполнялось с частотой 84Mhz?
Наверное я чего-то не понимаю. Объясните пожалуйста.
Не 80, а 168. По одному такту на инструкцию.
STM32F4
STM32F4
Забавно. А управление циклом ничего не кушает?
А вы замеряли или просто высказали догадку?
А вы замеряли или просто высказали догадку?
Я же писал
Аналогично для нативного кода будет примерно так:
Чем больше таких повторяющихся пар в теле цикла, тем меньше влияние лишней инструкции перехода.
И да, естественно замерял.
заменил тело цикла на много повторяющихся строчек:
led.Write(true); led.Write(false);
Аналогично для нативного кода будет примерно так:
GPIOA->BSRRL = 1;//set pinGPIOA->BSRRH = 1;//rst pinЧем больше таких повторяющихся пар в теле цикла, тем меньше влияние лишней инструкции перехода.
И да, естественно замерял.
Похоже судьба проекта .NET MicroFramework такая же как и у squawk(jvm) на этой платформе. Молодцы что разработчики портировали проект, народ почитает новость, попробует. А реально массово использовать в проектах никто не будет. java.net/projects/squawk/pages/BuildingSquawkForOtherMCUs
IMHO ардуиновский wiring более прост в изучении и эффективен для быстрого старта. Народ его использует. Реализация libmaple для stm32 вполне стабильна
IMHO ардуиновский wiring более прост в изучении и эффективен для быстрого старта. Народ его использует. Реализация libmaple для stm32 вполне стабильна
Интересно, а взлетит на STM32F103RBT6?
Только в параллельной вселенной, в которой бегемоты умеют летать. А в нашей это, может, и взлетит, но тормоза будут настолько чудовищны, что ничего серьёзнее «Hello, world» делать не будет смысла. Ещё нужно иметь ввиду, что периферия у STM32F4xx и STM32F10x разная, в том числе GPIO — значит, в .NET MicroFramework должны быть библиотеки для последних, а также способ выбора конкретной серии МК.
Не кипешуйте, все нормально будет. Сейчас даже суровые native C — кодеры такты процессора не считают. Эволюция давно уже идет от нативного программирования к архитектурному, коллективному, и управлению процессом кодинга уделяется больше внимания чем самому коду.
Микрофреймворк кстати не так уж плох, если не пугаться и познакомиться с ним поближе. Практически няшечка, если не идти на принцип сурового олдскула.
Микрофреймворк кстати не так уж плох, если не пугаться и познакомиться с ним поближе. Практически няшечка, если не идти на принцип сурового олдскула.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запускаем .NET MicroFramework на STM32F4Discovery (перевод)