Как стать автором
Обновить

Комментарии 42

а куда 0 возвращать хотите?

Это нужно, чтобы подавить warning от GCC. Естественно, он никуда на самом деле не вернётся.

Можно не писать return 0; если сделать так:
__attribute__ ((OS_main)) int main(void) {
// your code
}
Еще один вариант (которым я обычно и пользуюсь) — прописать параметр вызова -Wno-main.
На самом деле, есть варианты. :) Я делал это для avr-gcc, но здесь, думаю, должно работать аналогично.
4 раза упомянули в статье:
проще чем аналогичный для STM32

А вот никакой простоты я особо не заметил, открыл msp432p401m.h увидел спагетину из дефайнов и такие же структуры как в stm
А открыв исходник sysinit увидел аналогичную инициализацию как SPL STM32 (файним частоту, препроцессор выбирает инициализационный код)
Так что собственно проще то?
Так что собственно проще то?

Простота состоит в том, что обеспечена обратная совместимость с MSP430, где для того, чтобы программировать не требовались библиотеки типа SPL. Чтобы зажечь светодиод, требуется установить два регистра, а не использовать структуры из SPL и т.п. как для STM32.


А открыв исходник sysinit увидел аналогичную инициализацию как SPL STM32

Это единственное место, где используется такой способ. Далее структуры оттуда не требуются. Можно сделать SystemInit() и забыть про него. Далее можно программировать так же как и для MSP430, с некоторыми поправками на обработку прерываний и т.п.

А, ну простите… у stm небыло своего «msp430», поэтому несчем сравнить

в stm32 тоже можно без них, вам разве запрещают?


я вижу разве что тут не надо тактование включать на ножки, в отличие от STM32

usb нет, sdio нет, контроллера паралельной шины тоже нет, таймеров только два (может они многоканальные. не разбирался) зато есть АЕS-256 непонятно зачем
«таймеров только два»

не правда

– Up to Four 16-Bit Timers, Each With up to Five
Capture, Compare, PWM Capability
– Two 32-Bit Timers, Each With Interrupt
Generation Capability

вот АЦП и USB — нет, это очень плохо

АЦП же есть у него, 24 канала по 14 бит.

__wfi() — это не разрешение прерываний. Это Wait For Interrupt — мы ждём какое-нибудь прерывание (не обязательно то, которое только что настроили).
Причём не просто ждём, а уходим при этом в сон с низким энергопотреблением: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15473.html

В статье имел ввиду, что эти две инструкции являются заменой того, что делалось в MSP430 одной инструкцией __enable_interrupt() Теперь добавил более подробное пояснение в статью.

Не знаком с MSP430. Можете рассказать зачем __enable_interrupt() ждет прерывания? На первый взгляд это кажется несколько нелогичным.
Он их и не ждёт.
ИМХО, тупиковая ветка у TI
мощь ядра M4F при более чем скромном ОЗУ и периферии — крайне узкая сфера применения
скорость развития линейки очень медленная, roadmap туманный

вместо того, чтобы развивать наследие Luminary Micro и конкурировать с ST, решили эти линейки похоронить (информация получена непосредственно от TI неделю назад в Мюнхене на Электронике-2016)
а жаль, TIVA — отличная линейка, с отличной периферией на уровне NXP (в отличие от ST, где банальное UART FIFO через жопу DMA приходится реализовывать, которых и так мало)

судя по всему, TI сосредоточился на ядрах CortexA и CortexM0, заточенных под связь и датчики, а «средние» процессора делать не будет

после фактических похорон NXP останется только ST в сегменте M3-M4-M7
А что случилось c NXP? А то хотел беспроводное что-то попробовать у них.
Qualcomm купил весь NXP. На корню. С фабриками. Qualcomm сам по себе — fabless компания.
Складываем 2+2 и получаем общее мнение ведущих вендоров (в Мюнхене давеча не раз звучало), что Квалком купил их только ради производственных мощностей и сейчас начнет загружать их производством СВОИХ процессоров, а остальные линейки либо будут плавно сниматься, либо периодически будут в allocation попадать, что для серийного производства слабо приемлемо.
Под связь и датчики у TI как раз Cortex-M3.

А микроконтроллеров общего назначения среднего класса на Cortex-M у них никогда и не было, TIVA — ещё более странное творение, с гигантскими корпусами и гигантским энергопотреблением.
Под связь и датчики — почти везде либо чистый М0, либо двухядерные М0 под app specific и М3 под код пользователя, причем М3 относительно слабые — периферии мало, памяти мало и т.п. Но в общам для решаемых задач — близко к идеалу. Либо датчики с микропотреблением, где производительность не нужна, либо датчик (беспроводка) с HOST-процессором М3 на том же кристалле для нетребовательных приложений.

По поводу среднего класса (М3\4) — от того и непонимание мое — нахрена было покупать Luminary Micro, если эту недостающую нишу не развивать.

А по поводу TIVA — самые высокоинтегрированные контроллеры на рынке были до выхода М7. Сделали на них пару железок — очень даже прямо ничего штука. Аналоги ST 407(409)\427(429) проигрывают по всем статьям, кроме цены, да и тут не сильно много. Корпусировка 129NCPDT — 1 кв.см, проблем никаких. По потреблению разве что в принципе не знаю, не наша ниша.
А по поводу TIVA — самые высокоинтегрированные контроллеры на рынке были до выхода М7


Вся эта высокоинтегрированность в 98 случаях из 100 не нужна даже даром. А она ещё и не даром, а за счёт огромных корпусов и соответствующего ценника.

Ну не нужно в большинстве задач полсотни GPIO, пять UART'ов и три I2C. Не нужно.

Если говорить у нужных фичах у чипов TI — в CC13xx/CC26xx (Cortex-M3 + радио) сделали почти абсолютную гибкость переназначения ножек, любой цифровой интерфейс на любой ножке. Вот за это я готов обнять и расцеловать.

Корпусировка 129NCPDT — 1 кв.см, проблем никаких


Очень много по современным меркам. Мне PQFN 7x7 мм уже кажется большим, а корпуса типа LQFP мы вообще практически не используем (я бы сказал без «практически», но вспомнил, что есть одна железка c FT2232HL).

По потреблению разве что в принципе не знаю, не наша ниша


Порядка 800 мкА/МГц в рабочем режиме, 4,5 мкА в спячке с включёнными часами.

У STM32L4 — примерно в 10 (десять) раз меньше. То есть формально, конечно, TIVA к энергоэффективным сериям и не относится — но по факту энергоэффективных серий общего назначения у TI просто нет.
Смысла с Вами спорить не вижу, кто-то делает калькуляторы и однобитные поделки, кто-то промышленные контроллеры на полсотни дискретных каналов и 5-6 независимых интерфейсов, ниши рынка разные.
У нас реально железка ценой в $100, а в ней 6UART, 3-4 SPI c управлением CS врукопашную на высоконагруженной банкированной realtime SPI-памяти, 4Ethernet IEEE1588, параллельно выполняется БПФ и прочие «радости».
Ставить туда Sitara и прочее — автоматом тянет обвязку не на один десяток баксов, так что живем на том, что живем. Нужны топовые М4\М7 кристаллы, а их, кроме ST и TIVA нету вообще от слова совсем.
На питание пофигу, устройства стационарные, нет питания — нечего измерять.

Так что применительно к теме — MSP432 всетаки непонятная ниша. Производительности нет, периферии нет, ничего вообще нет, отличающего кардинально от конкурентов. При этом линейки продуктовой тоже нет. В электропитании не силен — возможно, что единственный козырь именно там.
Так что применительно к теме — MSP432 всетаки непонятная ниша


Вот с этим ни разу не спорю. Я как бы от преемника MSP430 ожидал что-то класса STM32 L-series и EFM32JG, а пока — ни рыба, ни мясо.

В электропитании не силен — возможно, что единственный козырь именно там


По даташиту — всё очень хорошо, но не лучше, чем у STM32L4 или EFM32JG.
MSP432 всетаки непонятная ниша

Здесь как раз всё понятно. MSP432 нацелено на тех, кто раньше разрабатывал под MSP430, но потом зачем-то решил перейти на Cortex. Так как заявленная совместимость по периферии выполняется, то можно легко перенести существующий код и использовать все свои заготовки.

Вы бы написали про свои успехи с CC13xx/CC26xx, а то недавно TI опубликовали errata вторую и всё те же грабли с 50kbps и с частотами т.д. То есть чип сырой, вы из него что-то смогли выжать?
Мы ими последнее время особо не занимаемся, основные силы на LoRa переключились — а там у нас в модеме STM32 банальный.

Стандартные режимы (50 kbps на 1310, 250 на 2650) у нас работают, 6LoWPAN работает. Более высокими скоростями не занимались, нам куда интереснее Long Range Mode — однако про LRM на Contiki в TI прямо сказали «текущий драйвер не поддерживает, надо — пишите свой».
уверены в LoRa?
проприетарный закрытый стек с моделью «работает только в Москве или берите нашу базу задорого»
ИМХО проприетарность и модель «база-абонент» вместо mesh перечеркивает насмерть все плюсы
От приложения, конечно, сильно зависит, но вот у нас всегда найдется абонент, до которого не будет радиовидимости от базы. И это будет не 0.0001%, а случай, когда капля говна в бочке меда превращается все в бочку говна. Извините за русский, из анекдота слов не выкинешь.
Эмммм… вы её путаете с Sigfox, кажется.

1) LoRa — это физуровень, у него вообще стека нет.

2) MAC-уровень для сотовых сетей LoRaWAN — открытый, https://github.com/Lora-net/LoRaMac-node. В России я знаю полдесятка компаний, которые эти сети планируют строить. И вообще можно свой MAC-уровень сделать, если поддержка сторонних сетей не нужна.

3) Базу можно брать чью угодно, равно как и делать свою.

А меш в данных условиях вообще неработоспособен:

а) самый ценный ресурс — радиоэфир, меш грузит его значительно выше, чем звезда, более того, по направлению к граничному роутеру загрузка эфира возрастает

б) меш невозможен без регулярно расположенных роутеров с внешним питанием

в) в меше невозможны (точнее, экономически неоправданны) такие средства по разгрузке эфира, как частотное или кодовое разделение — они приводят к сильному удорожанию роутера, что делает всю затею бессмысленной

Ну и наконец — дальность у CC1310 в LRM таки ощутимо меньше, чем у LoRa. Можно, конечно, и на том же СС1310 пилить свой UNB-протокол, как делают Стриж или Альтоника, но, во-первых, у UNB нерешаемых проблем тоже изрядно (меш в UNB невозможен в принципе), а во-вторых, зачем?
Под проприетарностью я имел в виду конечно физический уровень — там безальтернативно Semtech.
Модель «дешевый и простой абонент — дорогая и навороченая база» подходит далеко не для всех приложений, наши клиенты не готовы платить ни за дорогие, но свои базы, ни за подписку на сервисы, предоставляемые сторонней компанией.
А вот mesh с моделью «каждое устройство — роутер» модходит идеально. Аппаратная реализация — чипы от TI 2530/1350/2650 и т.п. стоят сравнимо с LoRa трансиверами.
По поводу эфира — не так все и плохо, сейчас проекты по 250-300 точек в mesh-сегменте на один координатор, несколько сегментов по эфиру слышат друг друга, но при сборе данных с приборов затыков нет. Территориально сами объекты автоматизации такие, что больше 1-2-3 км расстояний в принципе нет и географическое распределение объектов равномерное — идеальное для mesh топологий.
Так что каждому рынку — свое решение.
А вот mesh с моделью «каждое устройство — роутер» модходит идеально


Куда подходит? На счётчики воды, где устройство должно 6 лет минимум на одной батарейке работать? На многоканальные датчики температуры с 3 годами на батарейке?
Я же Вам написал ранее — что вопрос энергопотребления и энергоэффективности для нас вообще не стоит. Нет питания — нечего измерять. Нечего измерять — нечего и передавать. Именно туда и подходит.
Зато когда питание включено, железка должна сама придумать себе способ доставки данных до ближайшего концентратора и сообщить «я нашлась». Когда их тысячи и десятки тысяч — никто из клиентов в своем уме не согласится конфигурировать связь вручную, должно быть по принципу plug&play.
Так он для вас не стоит, а про великие достоинства меша вы рассказываете за всех.

При этом, что характерно, на 250-300 абонентов и в LoRa базу можно поставить за 100-200 баксов.

Когда их тысячи и десятки тысяч


Когда у вас их там будут тысячи и десятки тысяч — меш немного умрёт.

никто из клиентов в своем уме не согласится конфигурировать связь вручную, должно быть по принципу plug&play


Ок. Да. А LoRa тут при чём?
Не понимаю, чем вызван Ваш тон, я вроде не рассказываю «про великие достоинства меша», да еще и за всех.
Посмотрим, как развиваться будет LoRa и подобные системы точка-точка. Наш выбор — mesh сети, гибридные, с несколькими физическими каналами (очень грубо говоря, 2.4/868/проводной), объединенными в общее топологическое mesh-поле.
ИМХО проприетарность и модель «база-абонент» вместо mesh перечеркивает насмерть все плюсы


я вроде не рассказываю «про великие достоинства меша», да еще и за всех.


ВООБЩЕ-ТО ДА. ;)
ИМХО, тупиковая ветка у TI

Жалко будет, если MSP432 закопают. Мне понравилась идея сделать 32-х разрядный МК, совместимый с уже существующим 16-разрядный.

Как можно видеть, пример значительно проще чем аналогичный для STM32. Не требуются ни SPL, ни Cube, ни HAL, ни Libopencm3.


Вот что бывает, когда производитель слишком активно навязывает свои библиотеки — у людей создается впечатление, что без них вообще нельзя.

На самом деле, и под STM32 можно спокойно писать без всех этих тяжеловесных порождений безудержного маркетинга. Просто ST, к моему глубокому сожалению, ориентируется не на тех, кто вдумчиво делает качественное обрудование, а на тех, кому надо, чтобы продукт вышел на рынок еще вчера, и неважно, что софт будет представлять из себя нагромождение неудобоваримых библиотек, а как он работает, не будет понимать даже сам разработчик.
Никакая IDE не используется.

А вообще IDE поддерживают подобную разработку?

Если про bare metal, то некоторые поддерживают: начиная от коммерческих (Keil, IAR) и заканчивая FOSS (Eclipse, QtCreator). Всякие вещи типа debug'а, отображения регистров и памяти есть у всех. Более специфичные вещи типа прошивки, показа io registers/io mem с расшифровкой — хз кто и что сейчас умеет. С прошивкой, в большинстве случаев можно использовать openocd или указать команду типа st-flash path/to/bin.hex.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории