Праграмаванне 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!

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

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

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