18.11.2016 15:19
vv_kuznetsov 42 7500 Источник

В этом году 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 не используется.


image


Железо


Внешний вид платы 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


Uniflash — это утилита для прошивки, которая работает в режиме GUI или CLI. Использовать её не так удобно, как OpenOCD, но другого варианта пока нет.


После того как скачали и установили Uniflash, нужно сгенерировать Shell-скрипт и XML-конфиг для прошивки. Для этого нужно запустить GUI Uniflash, возможно от пользователя root. GUI это исполняемый файл nw в каталоге node-webkit. Подключаем плату и запускаем его. Видим следующее окно, в котором нужно выбрать
MSP->MSP432 Launchpad и XDS110.
image


Теперь нужно сгенерировать конфиг и скрипт-прошивальщик. Для этого нажимаем Start и выбираем Satndalone Command Line. Потом жмём Generate:
image


Создаётся архив, содержащий сгенерированный прошивальщик. Распаковываем его куда-либо и следуем инструкции, отображаемой в окне 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, что отмечают все, кто работал с этими двумя семействами МК. Прошиваем и запускаем эту программу и видим мигающие светодиоды на плате:
image


Заключение


В данной статье рассмотрено создание простейшего проекта для MSP432. Как видно, MSP432 имеет достаточно хорошую совместимость с MSP430. Код для MSP430 может быть портирован после некоторой адаптации. Поэтому данная архитектура может заинтересовать тех, кто уже знаком с MSP430. Также периферия MSP432 отличается значительной простотой. Чтобы программировать, не требуется библиотек наподобие SPL или Libopencm3. Но имеются и недостатки. Это плохая поддержка со стороны open-source решений для прошивки и отладки и недостаток информации по данной архитектуре. Для STM32 имеется громадной количество статей и примеров, развитое сообщество, форумы и т.п. Для MSP432 же основной источник информации — даташиты и руководства от TexasInstruments.


Полезные ссылки


Поделиться с друзьями
-->

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


  1. vv_kuznetsov
    18.11.2016 19:01
    #9918848

    del


  1. Immortal_Buka
    18.11.2016 19:01
    #9918850

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


    1. vv_kuznetsov
      18.11.2016 19:01
      #9918852

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


      1. Emigrate
        19.11.2016 19:29
        #9920104

        Прошу прощения, случайно тут написал)


      1. Bismuth208
        20.11.2016 09:55
        #9920674

        Можно не писать return 0; если сделать так:

        __attribute__ ((OS_main)) int main(void) {
// your code
}


        1. LampTester
          20.11.2016 11:48
          #9920764

          Еще один вариант (которым я обычно и пользуюсь) — прописать параметр вызова -Wno-main.


    1. LampTester
      20.11.2016 11:49
      #9920766

      На самом деле, есть варианты. :) Я делал это для avr-gcc, но здесь, думаю, должно работать аналогично.


  1. saw_tooth
    18.11.2016 19:06
    #9918864
    +1

    4 раза упомянули в статье:

    проще чем аналогичный для STM32

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


    1. vv_kuznetsov
      18.11.2016 19:23
      #9918904
      +1

      Так что собственно проще то?

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


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

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


      1. saw_tooth
        18.11.2016 19:29
        #9918918
        -1

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


      1. ColdPhoenix
        19.11.2016 15:26
        #9919938
        +2

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


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


  1. saw_tooth
    18.11.2016 19:22
    #9918896
    +1

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


    1. golf2109
      18.11.2016 20:03
      #9919014

      «таймеров только два»

      не правда

      – 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 — нет, это очень плохо


      1. vv_kuznetsov
        20.11.2016 10:23
        #9920704

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


  1. lorc
    18.11.2016 20:02
    #9919010
    +2

    __wfi() — это не разрешение прерываний. Это Wait For Interrupt — мы ждём какое-нибудь прерывание (не обязательно то, которое только что настроили).


    1. olartamonov
      19.11.2016 12:20
      #9919832

      Причём не просто ждём, а уходим при этом в сон с низким энергопотреблением: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15473.html


    1. vv_kuznetsov
      20.11.2016 10:25
      #9920708

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


      1. lorc
        21.11.2016 17:54
        #9922580
        +1

        Не знаком с MSP430. Можете рассказать зачем __enable_interrupt() ждет прерывания? На первый взгляд это кажется несколько нелогичным.


        1. olartamonov
          22.11.2016 08:00
          #9923234

          Он их и не ждёт.


  1. man55
    19.11.2016 10:17
    #9919702
    +2

    ИМХО, тупиковая ветка у TI
    мощь ядра M4F при более чем скромном ОЗУ и периферии — крайне узкая сфера применения
    скорость развития линейки очень медленная, roadmap туманный

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

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

    после фактических похорон NXP останется только ST в сегменте M3-M4-M7


    1. yunushkin
      19.11.2016 11:07
      #9919752

      А что случилось c NXP? А то хотел беспроводное что-то попробовать у них.


      1. man55
        19.11.2016 13:41
        #9919874

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


    1. olartamonov
      19.11.2016 12:43
      #9919844

      Под связь и датчики у TI как раз Cortex-M3.

      А микроконтроллеров общего назначения среднего класса на Cortex-M у них никогда и не было, TIVA — ещё более странное творение, с гигантскими корпусами и гигантским энергопотреблением.


      1. man55
        19.11.2016 13:47
        #9919880
        +1

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

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

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


        1. olartamonov
          19.11.2016 14:52
          #9919930
          +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 просто нет.


          1. man55
            19.11.2016 15:21
            #9919936
            +1

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

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


            1. olartamonov
              19.11.2016 15:32
              #9919940
              +1

              Так что применительно к теме — MSP432 всетаки непонятная ниша


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

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


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


            1. vv_kuznetsov
              20.11.2016 10:29
              #9920714

              MSP432 всетаки непонятная ниша

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


          1. Costic
            20.11.2016 09:56
            #9920678

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


            1. olartamonov
              20.11.2016 10:00
              #9920684

              Мы ими последнее время особо не занимаемся, основные силы на LoRa переключились — а там у нас в модеме STM32 банальный.

              Стандартные режимы (50 kbps на 1310, 250 на 2650) у нас работают, 6LoWPAN работает. Более высокими скоростями не занимались, нам куда интереснее Long Range Mode — однако про LRM на Contiki в TI прямо сказали «текущий драйвер не поддерживает, надо — пишите свой».


              1. man55
                20.11.2016 20:11
                #9921262

                уверены в LoRa?
                проприетарный закрытый стек с моделью «работает только в Москве или берите нашу базу задорого»
                ИМХО проприетарность и модель «база-абонент» вместо mesh перечеркивает насмерть все плюсы
                От приложения, конечно, сильно зависит, но вот у нас всегда найдется абонент, до которого не будет радиовидимости от базы. И это будет не 0.0001%, а случай, когда капля говна в бочке меда превращается все в бочку говна. Извините за русский, из анекдота слов не выкинешь.


                1. olartamonov
                  20.11.2016 21:44
                  #9921318

                  Эмммм… вы её путаете с Sigfox, кажется.

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

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

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

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

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

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

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

                  Ну и наконец — дальность у CC1310 в LRM таки ощутимо меньше, чем у LoRa. Можно, конечно, и на том же СС1310 пилить свой UNB-протокол, как делают Стриж или Альтоника, но, во-первых, у UNB нерешаемых проблем тоже изрядно (меш в UNB невозможен в принципе), а во-вторых, зачем?


                  1. man55
                    21.11.2016 08:10
                    #9921554

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


                    1. olartamonov
                      21.11.2016 11:22
                      #9921788

                      А вот mesh с моделью «каждое устройство — роутер» модходит идеально


                      Куда подходит? На счётчики воды, где устройство должно 6 лет минимум на одной батарейке работать? На многоканальные датчики температуры с 3 годами на батарейке?


                      1. man55
                        21.11.2016 11:33
                        #9921800

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


                        1. olartamonov
                          21.11.2016 11:36
                          #9921806

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

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

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


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

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


                          Ок. Да. А LoRa тут при чём?


                          1. man55
                            21.11.2016 12:26
                            #9921886

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


                            1. olartamonov
                              21.11.2016 12:40
                              #9921922

                              ИМХО проприетарность и модель «база-абонент» вместо mesh перечеркивает насмерть все плюсы


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


                              ВООБЩЕ-ТО ДА. ;)


    1. vv_kuznetsov
      20.11.2016 10:33
      #9920718

      ИМХО, тупиковая ветка у TI

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


  1. LampTester
    20.11.2016 09:55
    #9920676
    +1

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


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

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


  1. mezastel
    21.11.2016 10:50
    #9921722

    Никакая IDE не используется.

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


    1. grossws
      21.11.2016 18:20
      #9922614

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