В этом году Texas Instruments запустили в производство новую серию микроконтроллеров MSP432. Пока в серии только один МК MSP432P401R, который уже доступен для заказа в конторах, торгующих электронными компонентами. Также для этой серии имеется отладочная плата MSP432-Launchpad, в которую интегрирован отладчик XDS110. Основные характеристики серии:
- 32-х разрядное ядро Cortex-M4 с FPU
- Тактовая частота до 48 МГц
- Заявлена совместимость по периферии с MSP430
- Ультранизкое энергропотребление (как для MSP430)
- Совместимость с GCC для ARM
Об остальных характеристиках можно прочитать на сайте TI. Для меня наиболее важным является заявленная совместимость с MSP430, поэтому я приобрёл MSP432-Launchapd, и решил проверить это на практике. Периферия для MSP430 значительно проще в программировании, чем STM32 и 8-битные МК, поэтому MSP432 выглядит очень заманчиво.
Под катом будет рассказано как собрать и прошить минимальный проект (светодиодоморгалку) для MSP432, используя GCC для ARM на платформе Linux. Никакая IDE не используется.
Железо
Внешний вид платы MSP432-Launchpad можно видеть на КДПВ до ката. Здесь ничего особенного. На плате собственно сам МК, разъём microUSB, гребёнка для подключения к портам МК, разъём JTAG, три кнопки (RESET и для подключены к портам МК) и два светодиода (красный и трёхцветный). Имеется встроенный преобразователь USB-UART. К МК подключен кварц, от которого работает система тактирования.
Подготовка инструментов
Компилятор
Первым делом понадобится установить то, чем мы собираемся компилировать и прошивать. В качестве компилятора можно использовать любую сборку GCC для ARM, которая поддерживает Cortex M4. Внутри у MSP432 обычный Cortex, и никаких особенностей здесь нет. Например GCC для ARM можно установить, используя пакетный менеджер вашего дистрибутива. Нужно установить пакет gcc-arm-none-eabi. Если его нет, то GCC для ARM можно взять здесь: https://launchpad.net/gcc-arm-embedded/+download
Прошивка
С прошивальщиком для MSP432 дела обстоят значительно хуже. OpenOCD не поддерживает эту архитектуру. Поэтому здесь возможны два выхода:
- Использовать утилиту Uniflash от TexasInstruments http://www.ti.com/tool/uniflash Она доступна для всех платформ.
- Использовать экспериментальную сборку OpenOCD отсюда: https://github.com/ungureanuvladvictor/openocd-code
Использование Uniflash
Uniflash — это утилита для прошивки, которая работает в режиме GUI или CLI. Использовать её не так удобно, как OpenOCD, но другого варианта пока нет.
После того как скачали и установили Uniflash, нужно сгенерировать Shell-скрипт и XML-конфиг для прошивки. Для этого нужно запустить GUI Uniflash, возможно от пользователя root. GUI это исполняемый файл nw в каталоге node-webkit. Подключаем плату и запускаем его. Видим следующее окно, в котором нужно выбрать
MSP->MSP432 Launchpad и XDS110.
Теперь нужно сгенерировать конфиг и скрипт-прошивальщик. Для этого нажимаем Start и выбираем Satndalone Command Line. Потом жмём Generate:
Создаётся архив, содержащий сгенерированный прошивальщик. Распаковываем его куда-либо и следуем инструкции, отображаемой в окне Uniflash. Чтобы запустить прошивку, нам нужен будет скрипт dslite.sh и путь к файлу конфигурации для нашей платы. Допустим, мы распаковали сгенерированный архив в /opt/uniflash, а прошивка находится в файле device.hex. Тогда прошить плату можно командой:
/opt/uniflash/dslite.sh --config=/opt/uniflash/user_files/configs/msp432p401r.ccxml device.hexПрошивка получается после компиляции проекта. Об этом будет рассказано в следующем разделе.
Неофициальная сборка OpenOCD
OpenOCD не поддерживает MSP432. В поставке имеются файлы конфигурации для MSP432. Используя драйвер CMSIS-DAP, можно успешно соединиться с платой. Но при попытке записи во флэш выдаётся ошибка, т.к. драйвер флеша для MSP432 отсутствует.
Имеется неофициальная версия openOCD с поддержкой MSP432. Исходный код доступен здесь: https://github.com/ungureanuvladvictor/openocd-code Чтобы его использовать, нужно собрать и установить openOCD. Так как данная ветка неофициальная, заменять им системный openOCD не рекомендуется. Лучше его установить например в /opt/oocd-msp432 Сборка и установка производится стандартно:
git clone https://github.com/ungureanuvladvictor/openocd-code
cd openocd-code
./bootstrap
./configure --enable-cmsis-dap --prefix=/opt/oocd-msp432
make
make installТеперь можно соединиться с платой, используя мой конфиг для MSP432: msp432.cfg :
/opt/oocd-msp432/bin/openocd -f msp432Прошить файл device.bin можно при помощи следующей последовательности команд OpenOCD, которую следует вписать куда-либо в Makefile:
init
reset halt # Стоп
msp432p4 init 0 # Инициализация Flash
msp432p4 mass_erase 0
msp432p4 init 0
flash write_image device.bin # Запись во Flash здесь
reset run # Заупск
shutdownЕсли всё нормально, то получаем следующий вывод от OpenOCD:
Open On-Chip Debugger 0.9.0-dev-g42aa8fa-dirty (2016-11-17-13:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x2ba01477
Info : cortex_m.cpu: hardware has 6 breakpoints, 4 watchpointsПравила udev
Чтобы можно было работать с платой от обычного пользователя, следует создать файл правил для udev в каталоге /etc/udev/rules.d Например, назовём его 60-msp432-launchpad.rules. Содержимое фала следующее:
KERNEL=="hidraw*",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="bef3",MODE="0666"
SUBSYSTEM=="usb",ATTR{idVendor}=="0451",GROUP="plugdev",MODE="0666"
SUBSYSTEM=="usb_device",ATTR{idVendor}=="0451",GROUP="plugdev",MODE="0666"Затем нужно перезагрузить правила udev.
Светодиодоморгалка для MSP432
Структура проекта
Чтобы написать и собрать программу для MSP432 понадобится CMSIS и скрипт линкера. Всё можно взять с сайта TI: Нужен msp432-gcc-support-files.zip, в котором находится всё вышеназванное. Но можно воспользоваться моим шаблоном проекта, который содержит CMSIS, Makefile, и минимальную программу. Только следует исправить пути к компиляторам и т.п. Взять его можно здесь: https://github.com/ra3xdh/msp432_template Далее будем рассматривать этот тестовый проект.
Итак, проект на MSP432 должен иметь следующую структуру:
msp432_template¦
+-- Makefile
+-- cmsis
¦ +-- include
¦ ¦ +-- CMSIS
¦ ¦ ¦ +-- cmsis_gcc.h
¦ ¦ ¦ +-- core_cm4.h
¦ ¦ ¦ +-- core_cmFunc.h
¦ ¦ ¦ +-- core_cmInstr.h
¦ ¦ ¦ L-- core_cmSimd.h
¦ ¦ +-- msp.h
¦ ¦ +-- msp432.h
¦ ¦ +-- msp432p401m.h
¦ ¦ +-- msp432p401m.lds
¦ ¦ +-- msp432p401m_classic.h
¦ ¦ +-- msp432p401r.h
¦ ¦ +-- msp432p401r.lds
¦ ¦ +-- msp432p401r_classic.h
¦ ¦ +-- msp_compatibility.h
¦ ¦ +-- system_msp432p401m.h
¦ ¦ L-- system_msp432p401r.h
¦ L-- src
¦ +-- interrupts_msp432p401m_gcc.c
¦ +-- interrupts_msp432p401r_gcc.c
¦ +-- startup_msp432p401m_gcc.c
¦ +-- startup_msp432p401r_gcc.c
¦ +-- system_msp432p401m.c
¦ L-- system_msp432p401r.c
L-- main.cВ корне лежит файл main.c и Makefile, в подкаталоге cmsis находится CMSIS. Здесь содержатся заголовки общие для Cortex-M4 и описание периферии MSP432 в файле msp432.h.
Makefile можно посмотреть в моём шаблоне проекта. Опции компилятора и линковщика — стандартные для Cortex-M. Команда make без целей собирает проект. Получаются файлы ELF, BIN, и HEX, которые нужно прошивать в МК. Цель make burn программирует МК при помощи Uniflash, а make flash — при помощи OpenOCD.
Минимальная программа
Собственно программа находится в файле main.c. Вот его содержимое:
#include "msp432.h"
int main(void)
{
SystemInit();
P1DIR = 0x01;
P1OUT = 0x01;
while(1);
return 0;
}Здесь мы зажигаем красный светодиод, подключенный к ножке P1.0 и уходим в бесконечный цикл. Как можно видеть, пример значительно проще чем аналогичный для STM32. Не требуются ни SPL, ни Cube, ни HAL, ни Libopencm3. От аналогичного примера для MSP430 отличается только двумя строками: вместо msp430.h нужно писать msp432.h, и появляется функция SystemInit(). На ней нужно остановиться подробнее. Функция берётся из CMSIS и инициализирует систему тактирования, WDT и т.п. В частоности, там инициализируется тактовая частота. Чтобы её поменять, нужно найти файл cmsis/src/system_msp432p401r.c и отредактировать в нём строку:
#define __SYSTEM_CLOCK 3000000Из названия понятно, что макрос __SYSTEM_CLOCK задаёт тактовую частоту в Герцах. Последняя строка return 0 нужна, чтобы подавить warning от GCC.
Как видим, пока всё хорошо, заявленная совместимость с MSP430 выполняется на 100%.
Скомпилировать и прошить этот проект можно стандартным способом:
make
make burnСветодиодоморгалка
Напишем более сложную светодиодоморгалку. Будем мигать трёхцветным светодиодом (он подключен к порту P2) и параллельно красным светодиодом. Для этого будем использовать таймер TMRA, который присутствовал в MSP430. Нам понадобится использовать прерывания. Код светодиодомоглаки main.c выглядит так:
#include "msp432.h"
#include <stdint.h>
int main(void)
{
SystemInit();
P1DIR = 0x01;
P1OUT = 0x00;
P2DIR = 0x07;
P2OUT = 0x00;
// Инициализируем таймер А
TA0CTL = TASSEL_1 + MC_1 + TACLR + TAIE ;
TA0CCTL0 = CCIE;
TA0CCR0 = 0xF000;
// Разрешаем прерывания
NVIC_EnableIRQ(TA0_0_IRQn);
__enable_irq();
__wfi();
for (;;) {
for (uint32_t i=0;i<0xFFFFF;i++) {
__no_operation();
}
P1OUT ^= 0x01;
}
return 0;
}
// Прерывание по таймеру
void TA0_0_IRQHandler()
{
static uint16_t led = 0;
if (TA0IV==0x0E) {
led ++;
if (led>7) led = 0x00;
P2OUT=led;
}
TA0CCTL0 &= (~CCIFG);
}Здесь требуется переписывать реализацию прерываний. В первый раз это не очень понятно как сделать, но потом становится ясно. Отличия от MSP430 следующие:
Разрешать прерывания нужно двумя макросами:
__enable_irq(); __wfi();
В MSP430 для этой цели служил один
``__enable_interrupt(). Здесь же первый макрос собственно разрешает IRQ, а второй означает "ждать прерывания" (wait for interrupt).
- Кроме того, нужно разрешить номер IRQ через NVIC. Обозначения прерываний можно найти в файле
interrupts_msp432p401r_gcc.c
Но тем не менее, совместимость с MSP430 на хорошем уровне. Код инициализация таймера и тело обработчика прерываний совпадают с аналогичным кодом для MSP430 на 100%. Программировать под MSP432 приятней, чем под STM32, что отмечают все, кто работал с этими двумя семействами МК. Прошиваем и запускаем эту программу и видим мигающие светодиоды на плате:
Заключение
В данной статье рассмотрено создание простейшего проекта для MSP432. Как видно, MSP432 имеет достаточно хорошую совместимость с MSP430. Код для MSP430 может быть портирован после некоторой адаптации. Поэтому данная архитектура может заинтересовать тех, кто уже знаком с MSP430. Также периферия MSP432 отличается значительной простотой. Чтобы программировать, не требуется библиотек наподобие SPL или Libopencm3. Но имеются и недостатки. Это плохая поддержка со стороны open-source решений для прошивки и отладки и недостаток информации по данной архитектуре. Для STM32 имеется громадной количество статей и примеров, развитое сообщество, форумы и т.п. Для MSP432 же основной источник информации — даташиты и руководства от TexasInstruments.
Полезные ссылки
- MSP432 Family guide: http://www.ti.com/lit/pdf/SLAU356
- Даташит MSP432P401R: http://www.ti.com/lit/gpn/msp432p401r
- Руководство по портированию кода с MSP430 на MSP432 (MSP432 porting guide) http://www.ti.com/lit/an/slaa656b/slaa656b.pdf
- Шаблон проекта для MSP432 и GCC-ARM: https://github.com/ra3xdh/msp432_template
- Неофициальный форк OpenOCD c поддержкой MSP432: https://github.com/ungureanuvladvictor/openocd-code
Комментарии (42)
Immortal_Buka
18.11.2016 19:01а куда 0 возвращать хотите?
vv_kuznetsov
18.11.2016 19:01Это нужно, чтобы подавить warning от GCC. Естественно, он никуда на самом деле не вернётся.
Bismuth208
20.11.2016 09:55Можно не писать return 0; если сделать так:
__attribute__ ((OS_main)) int main(void) { // your code }LampTester
20.11.2016 11:48Еще один вариант (которым я обычно и пользуюсь) — прописать параметр вызова -Wno-main.
LampTester
20.11.2016 11:49На самом деле, есть варианты. :) Я делал это для avr-gcc, но здесь, думаю, должно работать аналогично.
saw_tooth
18.11.2016 19:06+14 раза упомянули в статье:
проще чем аналогичный для STM32
А вот никакой простоты я особо не заметил, открыл msp432p401m.h увидел спагетину из дефайнов и такие же структуры как в stm
А открыв исходник sysinit увидел аналогичную инициализацию как SPL STM32 (файним частоту, препроцессор выбирает инициализационный код)
Так что собственно проще то?vv_kuznetsov
18.11.2016 19:23+1Так что собственно проще то?
Простота состоит в том, что обеспечена обратная совместимость с MSP430, где для того, чтобы программировать не требовались библиотеки типа SPL. Чтобы зажечь светодиод, требуется установить два регистра, а не использовать структуры из SPL и т.п. как для STM32.
А открыв исходник sysinit увидел аналогичную инициализацию как SPL STM32
Это единственное место, где используется такой способ. Далее структуры оттуда не требуются. Можно сделать SystemInit() и забыть про него. Далее можно программировать так же как и для MSP430, с некоторыми поправками на обработку прерываний и т.п.
ColdPhoenix
19.11.2016 15:26+2в stm32 тоже можно без них, вам разве запрещают?
я вижу разве что тут не надо тактование включать на ножки, в отличие от STM32
saw_tooth
18.11.2016 19:22+1usb нет, sdio нет, контроллера паралельной шины тоже нет, таймеров только два (может они многоканальные. не разбирался) зато есть АЕS-256 непонятно зачем
golf2109
18.11.2016 20:03«таймеров только два»
не правда
– 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 — нет, это очень плохо
lorc
18.11.2016 20:02+2__wfi() — это не разрешение прерываний. Это Wait For Interrupt — мы ждём какое-нибудь прерывание (не обязательно то, которое только что настроили).
olartamonov
19.11.2016 12:20Причём не просто ждём, а уходим при этом в сон с низким энергопотреблением: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15473.html
vv_kuznetsov
20.11.2016 10:25В статье имел ввиду, что эти две инструкции являются заменой того, что делалось в MSP430 одной инструкцией
__enable_interrupt()Теперь добавил более подробное пояснение в статью.lorc
21.11.2016 17:54+1Не знаком с MSP430. Можете рассказать зачем __enable_interrupt() ждет прерывания? На первый взгляд это кажется несколько нелогичным.
man55
19.11.2016 10:17+2ИМХО, тупиковая ветка у TI
мощь ядра M4F при более чем скромном ОЗУ и периферии — крайне узкая сфера применения
скорость развития линейки очень медленная, roadmap туманный
вместо того, чтобы развивать наследие Luminary Micro и конкурировать с ST, решили эти линейки похоронить (информация получена непосредственно от TI неделю назад в Мюнхене на Электронике-2016)
а жаль, TIVA — отличная линейка, с отличной периферией на уровне NXP (в отличие от ST, где банальное UART FIFO черезжопуDMA приходится реализовывать, которых и так мало)
судя по всему, TI сосредоточился на ядрах CortexA и CortexM0, заточенных под связь и датчики, а «средние» процессора делать не будет
после фактических похорон NXP останется только ST в сегменте M3-M4-M7yunushkin
19.11.2016 11:07А что случилось c NXP? А то хотел беспроводное что-то попробовать у них.
man55
19.11.2016 13:41Qualcomm купил весь NXP. На корню. С фабриками. Qualcomm сам по себе — fabless компания.
Складываем 2+2 и получаем общее мнение ведущих вендоров (в Мюнхене давеча не раз звучало), что Квалком купил их только ради производственных мощностей и сейчас начнет загружать их производством СВОИХ процессоров, а остальные линейки либо будут плавно сниматься, либо периодически будут в allocation попадать, что для серийного производства слабо приемлемо.
olartamonov
19.11.2016 12:43Под связь и датчики у TI как раз Cortex-M3.
А микроконтроллеров общего назначения среднего класса на Cortex-M у них никогда и не было, TIVA — ещё более странное творение, с гигантскими корпусами и гигантским энергопотреблением.man55
19.11.2016 13:47+1Под связь и датчики — почти везде либо чистый М0, либо двухядерные М0 под app specific и М3 под код пользователя, причем М3 относительно слабые — периферии мало, памяти мало и т.п. Но в общам для решаемых задач — близко к идеалу. Либо датчики с микропотреблением, где производительность не нужна, либо датчик (беспроводка) с HOST-процессором М3 на том же кристалле для нетребовательных приложений.
По поводу среднего класса (М3\4) — от того и непонимание мое — нахрена было покупать Luminary Micro, если эту недостающую нишу не развивать.
А по поводу TIVA — самые высокоинтегрированные контроллеры на рынке были до выхода М7. Сделали на них пару железок — очень даже прямо ничего штука. Аналоги ST 407(409)\427(429) проигрывают по всем статьям, кроме цены, да и тут не сильно много. Корпусировка 129NCPDT — 1 кв.см, проблем никаких. По потреблению разве что в принципе не знаю, не наша ниша.olartamonov
19.11.2016 14:52+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 просто нет.man55
19.11.2016 15:21+1Смысла с Вами спорить не вижу, кто-то делает калькуляторы и однобитные поделки, кто-то промышленные контроллеры на полсотни дискретных каналов и 5-6 независимых интерфейсов, ниши рынка разные.
У нас реально железка ценой в $100, а в ней 6UART, 3-4 SPI c управлением CS врукопашную на высоконагруженной банкированной realtime SPI-памяти, 4Ethernet IEEE1588, параллельно выполняется БПФ и прочие «радости».
Ставить туда Sitara и прочее — автоматом тянет обвязку не на один десяток баксов, так что живем на том, что живем. Нужны топовые М4\М7 кристаллы, а их, кроме ST и TIVA нету вообще от слова совсем.
На питание пофигу, устройства стационарные, нет питания — нечего измерять.
Так что применительно к теме — MSP432 всетаки непонятная ниша. Производительности нет, периферии нет, ничего вообще нет, отличающего кардинально от конкурентов. При этом линейки продуктовой тоже нет. В электропитании не силен — возможно, что единственный козырь именно там.olartamonov
19.11.2016 15:32+1Так что применительно к теме — MSP432 всетаки непонятная ниша
Вот с этим ни разу не спорю. Я как бы от преемника MSP430 ожидал что-то класса STM32 L-series и EFM32JG, а пока — ни рыба, ни мясо.
В электропитании не силен — возможно, что единственный козырь именно там
По даташиту — всё очень хорошо, но не лучше, чем у STM32L4 или EFM32JG.
vv_kuznetsov
20.11.2016 10:29MSP432 всетаки непонятная ниша
Здесь как раз всё понятно. MSP432 нацелено на тех, кто раньше разрабатывал под MSP430, но потом зачем-то решил перейти на Cortex. Так как заявленная совместимость по периферии выполняется, то можно легко перенести существующий код и использовать все свои заготовки.
Costic
20.11.2016 09:56Вы бы написали про свои успехи с CC13xx/CC26xx, а то недавно TI опубликовали errata вторую и всё те же грабли с 50kbps и с частотами т.д. То есть чип сырой, вы из него что-то смогли выжать?
olartamonov
20.11.2016 10:00Мы ими последнее время особо не занимаемся, основные силы на LoRa переключились — а там у нас в модеме STM32 банальный.
Стандартные режимы (50 kbps на 1310, 250 на 2650) у нас работают, 6LoWPAN работает. Более высокими скоростями не занимались, нам куда интереснее Long Range Mode — однако про LRM на Contiki в TI прямо сказали «текущий драйвер не поддерживает, надо — пишите свой».man55
20.11.2016 20:11уверены в LoRa?
проприетарный закрытый стек с моделью «работает только в Москве или берите нашу базу задорого»
ИМХО проприетарность и модель «база-абонент» вместо mesh перечеркивает насмерть все плюсы
От приложения, конечно, сильно зависит, но вот у нас всегда найдется абонент, до которого не будет радиовидимости от базы. И это будет не 0.0001%, а случай, когда капля говна в бочке меда превращается все в бочку говна. Извините за русский, из анекдота слов не выкинешь.olartamonov
20.11.2016 21:44Эмммм… вы её путаете с Sigfox, кажется.
1) LoRa — это физуровень, у него вообще стека нет.
2) MAC-уровень для сотовых сетей LoRaWAN — открытый, https://github.com/Lora-net/LoRaMac-node. В России я знаю полдесятка компаний, которые эти сети планируют строить. И вообще можно свой MAC-уровень сделать, если поддержка сторонних сетей не нужна.
3) Базу можно брать чью угодно, равно как и делать свою.
А меш в данных условиях вообще неработоспособен:
а) самый ценный ресурс — радиоэфир, меш грузит его значительно выше, чем звезда, более того, по направлению к граничному роутеру загрузка эфира возрастает
б) меш невозможен без регулярно расположенных роутеров с внешним питанием
в) в меше невозможны (точнее, экономически неоправданны) такие средства по разгрузке эфира, как частотное или кодовое разделение — они приводят к сильному удорожанию роутера, что делает всю затею бессмысленной
Ну и наконец — дальность у CC1310 в LRM таки ощутимо меньше, чем у LoRa. Можно, конечно, и на том же СС1310 пилить свой UNB-протокол, как делают Стриж или Альтоника, но, во-первых, у UNB нерешаемых проблем тоже изрядно (меш в UNB невозможен в принципе), а во-вторых, зачем?man55
21.11.2016 08:10Под проприетарностью я имел в виду конечно физический уровень — там безальтернативно Semtech.
Модель «дешевый и простой абонент — дорогая и навороченая база» подходит далеко не для всех приложений, наши клиенты не готовы платить ни за дорогие, но свои базы, ни за подписку на сервисы, предоставляемые сторонней компанией.
А вот mesh с моделью «каждое устройство — роутер» модходит идеально. Аппаратная реализация — чипы от TI 2530/1350/2650 и т.п. стоят сравнимо с LoRa трансиверами.
По поводу эфира — не так все и плохо, сейчас проекты по 250-300 точек в mesh-сегменте на один координатор, несколько сегментов по эфиру слышат друг друга, но при сборе данных с приборов затыков нет. Территориально сами объекты автоматизации такие, что больше 1-2-3 км расстояний в принципе нет и географическое распределение объектов равномерное — идеальное для mesh топологий.
Так что каждому рынку — свое решение.olartamonov
21.11.2016 11:22А вот mesh с моделью «каждое устройство — роутер» модходит идеально
Куда подходит? На счётчики воды, где устройство должно 6 лет минимум на одной батарейке работать? На многоканальные датчики температуры с 3 годами на батарейке?man55
21.11.2016 11:33Я же Вам написал ранее — что вопрос энергопотребления и энергоэффективности для нас вообще не стоит. Нет питания — нечего измерять. Нечего измерять — нечего и передавать. Именно туда и подходит.
Зато когда питание включено, железка должна сама придумать себе способ доставки данных до ближайшего концентратора и сообщить «я нашлась». Когда их тысячи и десятки тысяч — никто из клиентов в своем уме не согласится конфигурировать связь вручную, должно быть по принципу plug&play.olartamonov
21.11.2016 11:36Так он для вас не стоит, а про великие достоинства меша вы рассказываете за всех.
При этом, что характерно, на 250-300 абонентов и в LoRa базу можно поставить за 100-200 баксов.
Когда их тысячи и десятки тысяч
Когда у вас их там будут тысячи и десятки тысяч — меш немного умрёт.
никто из клиентов в своем уме не согласится конфигурировать связь вручную, должно быть по принципу plug&play
Ок. Да. А LoRa тут при чём?man55
21.11.2016 12:26Не понимаю, чем вызван Ваш тон, я вроде не рассказываю «про великие достоинства меша», да еще и за всех.
Посмотрим, как развиваться будет LoRa и подобные системы точка-точка. Наш выбор — mesh сети, гибридные, с несколькими физическими каналами (очень грубо говоря, 2.4/868/проводной), объединенными в общее топологическое mesh-поле.olartamonov
21.11.2016 12:40ИМХО проприетарность и модель «база-абонент» вместо mesh перечеркивает насмерть все плюсы
я вроде не рассказываю «про великие достоинства меша», да еще и за всех.
ВООБЩЕ-ТО ДА. ;)
vv_kuznetsov
20.11.2016 10:33ИМХО, тупиковая ветка у TI
Жалко будет, если MSP432 закопают. Мне понравилась идея сделать 32-х разрядный МК, совместимый с уже существующим 16-разрядный.
LampTester
20.11.2016 09:55+1Как можно видеть, пример значительно проще чем аналогичный для STM32. Не требуются ни SPL, ни Cube, ни HAL, ни Libopencm3.
Вот что бывает, когда производитель слишком активно навязывает свои библиотеки — у людей создается впечатление, что без них вообще нельзя.
На самом деле, и под STM32 можно спокойно писать без всех этих тяжеловесных порождений безудержного маркетинга. Просто ST, к моему глубокому сожалению, ориентируется не на тех, кто вдумчиво делает качественное обрудование, а на тех, кому надо, чтобы продукт вышел на рынок еще вчера, и неважно, что софт будет представлять из себя нагромождение неудобоваримых библиотек, а как он работает, не будет понимать даже сам разработчик.
mezastel
21.11.2016 10:50Никакая IDE не используется.
А вообще IDE поддерживают подобную разработку?
grossws
21.11.2016 18:20Если про bare metal, то некоторые поддерживают: начиная от коммерческих (Keil, IAR) и заканчивая FOSS (Eclipse, QtCreator). Всякие вещи типа debug'а, отображения регистров и памяти есть у всех. Более специфичные вещи типа прошивки, показа io registers/io mem с расшифровкой — хз кто и что сейчас умеет. С прошивкой, в большинстве случаев можно использовать openocd или указать команду типа
st-flash path/to/bin.hex.
vv_kuznetsov
del