Чаму ў Windows Store няма праграм для разпрацоўшчыкаў прылад з Bluetooth Low Energy?

А адказ вельмі просты:

Праграма для Windows 8 / Windows Phone 8 мае магчымасць працаваць толькі з тымі сервісамі GATT, якія прапісаны ў маніфесце. Такім чынам не можа існаваць праграма, здольная працаваць з любым сервісам. Да таго ж, АС дае магчымасць шукаць прылады па сервісу, аднак сервісы ў прылады -- не.

Вось так выглядае маніфест праграмы BLEServiceBrowser (уваходзіць у Application Accelerator):

<m2:DeviceCapability Name="bluetooth.genericAttributeProfile">
  <m2:Device Id="any">
    <m2:Function Type="name:genericAccess" />
    <m2:Function Type="name:heartRate" />
    <m2:Function Type="name:battery" />
    <m2:Function Type="serviceId:00001800-0000-1000-8000-00805f9b34fb" />
  </m2:Device>
</m2:DeviceCapability>

Калі ў вас стандарнты сервіс, можна пазначыць яго па імені, інакш -- пазначце UUID.

Праграмаванне RL78/G10 праз паслядоўны порт

З версіі v0.4 у склад праграмы rl78flash уваходзіць асобная праграма для RL78/G10 -- rl78g10flash. Яна здольна пісаць і правяраць адпаведнасць CRC вонкавай памяці мікракантролераў RL78/G10. Апаратнае забеспячэнне можна выкарыстоўваць тое ж самае што і для ўсіх астатніх RL78, але RL78/G10 падтрымліваюць выключна хуткасць 115200 і аднаправодны рэжым.

Вядомы пераўтваральнік USB-UART з невядомымі VID/PID у Linux

Спіс вядомых VID/PID  для кожнага пераўтваральніка прашыты ў зыходным кодзе адпаведнага драйвера. Але бываюць абставіны, калі няма магчымасці ці жадання перасабраць модуль.  Для такіх выпадкаў існуе магчымасць дадаць VID/PID дынамічна.

Робіцца гэта вельмі проста:

echo <vid> <pid> > /sys/bus/usb-serial/drivers/<module>/new_id

дзе замест <vid> і <pid> трэба запісаць патрэбныя нумары, а замест <module>  -- імя модуля.

Паслядоўнасць дзеяў цалкам:

1. загрузіць патрэбны модуль, напрыклад cp210x

   modprobe cp210x

2. дадаць новыя VID/PID:

   echo 0123 4567 > /sys/bus/usb-serial/drivers/cp210x/new_id

3. далучыць прыладу.

Майце на ўвазе, што ўсе маніпуляцыі з ядром дазволены толькі карыстальніку root. Таму прывожу варыянты з ужываннем sudo:

sudo modprobe cp210x
sudo bash -c "echo 0123 4567 > /sys/bus/usb-serial/drivers/cp210x/new_id"

BLE112 vs. Windows 8

Пры распрацоўцы прылады з Bluetooth сутыкнуўся з праблемай, што тэлефоны з Android 4.4 ды iOS усталёўваюць сувязь і працуюць без ніякіх перашкод, а вось Windows 8 бачыў прыладу, але парынг заўсёды зкончваўся памылкай. Пошук падобных выпадкаў даў такі расклад: у кагосьці не працуе аніяк, у іншых проста працуе. Чаму такое утвараецца мне знайсці не пашчаслівіла, да таго ж не было сапраўднага ПК, а мелася толькі эмуляцыя да знешні "свісток" на чыпе BCM20702.

Праблема была зразумета, толькі пры дапамозе Surface Pro 3. Высветлілася што Windows 8 патрабуе bonding, а иншыя АС -- не. Каб уключыць яго, дастаткова выканаць запыт

sm_set_bondable_mode(1)

пры пачатковай наладке модуля.

Вось і ўсё.

Драйвер для віртуальнага паслядоўнага парта на μPD78F0730

Renesas Electronics вырабляе некаторыя адладачныя платы з убудаваным адладчыкам. Напрыклад, платы YRPBRL78G1x [1] маюць пераўтваральнік USB-UART, пабудаваны на мікрасхеме μPD78F0730 [2]. Такім чынам, атрымліваецца, што стварыць прашыўку для гэтай платы над Linux магчыма, а запраграміраваць -- не, бо не існуе драйвера для пераўтваральніка.

Узброіўшыся апісаннем пратакола [3], я вырашыў напісаць драйвер. Тое, што не было апісана, прыйшлося падслухоўваць у драйвера для Windows.

Драйвер: https://github.com/msalau/upd78f0730-driver

Пераўтваральнік з гэтым драйверам здольны:

• выстаўляць наладкі хуткасці, даўжыні дадзеных, цотнасці, колькасць стоп-бітаў, апаратнае кіраванне патокам;
• кіраваць станам сігналаў RTS ды DTR;
• ствараць сігнал BREAK.

Запраграміраваць плату можна пры дапамозе rl78flash

rl78flash -aim3 /dev/ttyUSB0 ./firmware.mot

[1] YRPBRL78G13, YRPBRL78G14
[2] UPD78F0730 microcontroller
[3] Application Note: μPD78F0730 USB-to-Serial Conversion Software

BGAPI ды BLE112

Калі вы вырашылі карыстацца BGAPI для кіравання модулем BLE112, перад вамі стаіць выбар рэжыму абмена. Трэба выбраць нумар модуля UART а таксама рэжым яго працы: з кіраваннем патокам альбо без. Дакументацыя не дае дакладнага апісання асаблівасцяў розных рэжымаў. Тут паспрабую сабраць тыя асаблівасці, што я знайшоў, калі наладжваў сувязь паміж гэтым модулем і мікракантролерам.

Выкарыстанне #pragma ў макрасах

Бывае, калі праграма на мове Сі пішацца для некалькіх платформаў, карыстаюцца макрасамі, каб адмежавацца ад асаблівасцяў кампілятара. Адным з такіх момантаў - пазначэнне структуры як упакованай. Як гэта робіцца агаворана ў стандарце на мову, таму кожны аўтар кампілятара сам вырашае, як гэта будзе рабіць праграміст.

Напрыклад, GCC мае спецыяльны атрыбут для структур: __attribute__((packed)). У іншых, гэта робіцца праз #pragma pack(push|pop), але іх нельга карыстаць у макрасах.

mspgcc і FRAM мікракантролеры MSP430

Калі вы вырашылі напісаць і адладжваць праграму для FRAM мікракантролераў MSP430, у мяне для вас не вельмі прыемная навіна: у mspgcc ёсць баг #349. Яго апісанне ёсць таксама і ў апісанні пакета gcc-msp430 (тое самае што і mspgcc) для Ubuntu:

BEWARE: due to a bug in the memory layout reference of FRAM-based chips, this package DOES NOT WORK with MSP430FR5xxx chips (eg. FraunchPad devkit). DO NOT use gcc-msp430 on that chip series, as you will lose access to JTAG and BSL, and permanently BRICK your chip!

Карацей: калі будзеце карыстацца гэтым кампілятарам ваш чып пераўтварыцца ў цагліну, з-за памылкі пры размеркаванні памяці.

Але надзея не згублена. Ёсць шляхі выкарыстання кампілятара.

Увага! Далей ідзе тэарэтычнае вырашэнне сапраўднай праблемы.

Выкарыстанне Splint для праверки зыходнага коду ўбудаванага праграмнага забеспячэння

Кошт выпраўлення памылак залежыць ад этапу жыцця праграмы, на якім гэту памылку знайшлі. Чым раней знойдзена памылка - тым танней абыходзіцца яе выпраўленне. Такім чынам усе зацікаўлены не тварыць памылкі, пры тым, чым раней, тым лепш. У нашым неідэальным свеце праграмісты імкнуцца паменшыць верагоднасць памылак у праграмным забеспячэнні. Для гэтага існуе тэсціраванне ўжо канчатковага коду на адпаведнасць спецыфікацыі (так званае распрацоўка праз тэсціраванне, або TDD - Test Driven Development). Але на якасць праверкі уплывае дакладнасць праверак.

Дадаткова да тэстаў існуе статычны аналіз коду. Ён не правярае логіку працы, для гэтай мэты ёсць TDD, а дазваляе знайсці месцы, якія кампілятар і праграміст разумеюць па рознаму.

Існуе не шмат, але нейкая колькасць статычных аналізатараў, як камерцыйных, так і адкрытых. Спіс аналізатараў можна знайсці ў Вікіпедыі.

Зараз гаворка пойдзе пра Splint, а таксама пра яго выкарыстанне для праверкі ўбудаванага праграмнага забеспячэння.

Набыццё электронных кампанентаў у Беларусі з-за мяжы праз Інтэрнэт

Падчас ёсць патрэба ў кампанентах, якія ў нашай краіне складана ці ўвогуле немагчыма набыць фізічнай асобе. На дапамогу прыходзяць інтэрнэт-крамы з-за мяжы. У іх ёсць выбар, прыемны кошт, але праблемы ўзнікаюць пры дастаўцы (час вандравання пасылкі да атрымальніка і родная мытня).

З найбольш вядомых пляцовак можна адзначыць:

• AliExpress
• Alibaba
• Ebay
• RS-Components
• DigiKey

 Спынімся на кожнай падрабязней.