_Pasha

#include <stdlib.h> #include <stdio.h> const char frr[]="141.14.14.56.00.82.43"; int main(void) { char *head = frr; char *tail; int what; for(;;) { what = strtol(head, &tail, 10); printf("parsed: %d \n",what,tail); if((tail == NULL)||(*tail == 0)) break; head = ++tail; } } а вообще нафига такие сложности, если можно умножением на 10 обойтись ... #include <stdlib.h> #include <stdio.h> const char frr[]="141.14.14.56.00.82.43"; int main(void) { char *head = frr; int res=0; char c,m=0; do { c = *head++; switch(c) { case ' ': case '\t': break; case '.': case 0: if(m) res = -res; printf("parsed: %d\n",res); res = 0; m=0; break; case '-': m=1; break; default: if((c <= '9') && (c >='0')) { res = res * 10 + c - '0'; } break; } } while(c); }

Не. Ну все таки нужно чтобы fingerprint работал. У кого получается на сабже работать с ssh из скриптов на десктопе?

похоже на результат применения ДКТ

или использовать DMA highest priority

упс. а чего это у меня по той же схеме , авр 20МГц - считает не в 2.5 раза быстрее, а в 4 ? Сейчас еще перепроверю, что за фигня.

Raspberry PI 1. Подключаете в локалку 2. заходите по ssh 3. компилируете в тамошнем линуксе st-flash из texane/stlink 4. пишете скрипт для мигания светодиодами и опроса кнопки. кнопку таки придется повесит все. проблема решена. разумеется, сами Вы будете долго разбираться. А кто уже ходил в малину :) - элементарно.

они еще и читать не умеют

ну Вы же работаете в "своем" архиудобном иаре, шо ж Вы не знаете, не иаровская ли это часом фишка?

Совершенно странное упорство в отказе от виртуалки.

ну, они для этого утечки и делают, чтобы люди учились работать на их инструментах. тоже понять можно.

Ві наверное очень богатій человек...

О. На джаве?

Сервер обновлений с белым ip На нем присутствует демон, udp сокет слушает обращения с любого ip отправителя на фикс. порт, т.е. bind("0.0.0.0",UDP_PORT) Отвечает тоже по фикс. порту и принятому адресу. Клиенты имеют "серый" адрес за NATом. Поскольку NAT искажает номера портов, клиенту приходится слушать все входящие пакеты на любой порт. В пакете первым находится magic number(32 бита) плюс некоторые внутренние зависимости, скажем - поле команды имеет несколько предопределенных значений. Отвечать на входящие не нужно, т.к. это UDP - железный клиент просто игнорирует то, что не является программирующим пакетом. По приему программирующего пакета можно организовать минимальную поддержку сеанса - запомнить порт и по таймауту чтобы он обнулялся, снова открывая для прослушки все пакеты. Дальше пакеты содержат команды - принять буфер данных (512 байт) по такому-то адресу и старт обновления. Клент отвечает что мол принял по такому то адресу с таким-то CRC И что ушел в ребут с обновлением. Нет ответа - идет повтор. Сервер по таймауту иключает адрес из очереди и делает в своей базе пометку, на чем собсна остановились. На клиенте: Код складывается в неиспользованную половину флеша, по старту обновления код работает в ОЗУ и пишет. Далбнейшие варианты обезопасить процесс - делать своп и оставлять какую-то фиксированную часть под бут. Чтобы он не мог самоубиться. ЗЫ. Железо в базе различается по мак-адресу.

Делал по UDP Белый сервак плюс серые клиенты.

В общем, фигня задача. Это делается не копированием сабжа а встраиванием содержимого в хекс-виде, т.е. самый лайт printf следит только за спецификаторами и умеет преобразовывать в хекс область памяти от младшего к старшему.

Как напишете так и будет. Плюс ватчдог.

так то ж ставить. А тут уже есть.

ааа. Понятно. Действительно, аттрибут к typedef неприменим :rolleyes: gcc -Wall -c "tst.c" -I. --std=gnu99 tst.c:18:61: error: section attribute not allowed for ‘bit’ typedef volatile uint32_t __attribute__((section(".bss"))) bit; ^ Compilation failed. Так что только дефайном.

Здравствуйте. Еще не добрался до проекта. Но обязательно проверю и сообщу.

если десяток строчек в скрипте линкера вызывает столько воплей, то я, пожалуй, випью

Товарищ не понимааает (с) Если у Вас есть возможность заводить static bool в разных модулях, то это гораздо интереснее чем вручную и глобально их определять. Насчет BSRR - история давняя, типа масляного масла получается, неудивительно что там конфликты возникают.

правильный ответ уже содержится в сообщ. №2

Привет. Есть два устройства, "тонкий" и "толстый" девайсы. На толстом возможно все. На тонком - почти ничего. Как передать с тонкого девайса результат printf() так, чтобы сам этот printf располагался на "толстом" девайсе? очевидно, что все очень просто - передаем формат а затем список значений. список значений заранее неизвестен на толстом девайсе. После приема этот список должен соответствовать va_list Теперь вопрос: каким образом сделать преобразование между упакованным массивом байт, который мы получим из списка - в va_list? интересуют самые портабельные варианты, если они есть.

законспектирую -- по теме: кривая разводка. (может услышит )

А. Ну у меня первый из дискавери под рукой. И нужно это было сделать сегодня. я хотел вначале повторить то что делает stm8flash на основе pyUSB, потом заскучал от кол-ва писанины теперь получается проще сделать питоновский модуль из того, что уже работает с stlink 1 и 2 - будет простенький класс с open close read write + специфик дебажные методы т.е. это какбы бэкенд. а верхний уровень, собственно дебаг - пишется на питоне легко и быстро. Вот только неохота с мутным cdb разбираться :( это все в предположении, что нормального дебаггера sdcdb под stm8 так и не будет :) и гнаться за прикручиванием бекэнда к нему нет смысла. Еще из замеченных косяков- stm8flash под stlink1 на малине не работает. Еще не понял почему. А вот 2 - работает без проблем. Stm32 отлаживаю через st-util А я уже разбаловался - пошел прилег с вайфаем и кручу отладку :)