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

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