Comments
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 — кодеры такты процессора не считают. Эволюция давно уже идет от нативного программирования к архитектурному, коллективному, и управлению процессом кодинга уделяется больше внимания чем самому коду.
Микрофреймворк кстати не так уж плох, если не пугаться и познакомиться с ним поближе. Практически няшечка, если не идти на принцип сурового олдскула.
Микрофреймворк кстати не так уж плох, если не пугаться и познакомиться с ним поближе. Практически няшечка, если не идти на принцип сурового олдскула.
Only those users with full accounts are able to leave comments. Log in, please.
Запускаем .NET MicroFramework на STM32F4Discovery (перевод)