_pv

то что они формально 16ти битные вовсе не означает что их нельзя отнести к 8ми битным задохликам, периферии там кот наплакал, она у msp430 вообще размазана очень тонким слоем по огромному количеству МК в семействе. для контроллера "кнопки включения и светодиода" отлично подходит.

MSP430FR2110, или MSP430G2230 в soic8

разрядов-то ладно, у AD/linear есть не хуже по дин.диапазону, причём некоторые даже не сигма-дельта, а SAR с оверсэмплингом, с нелинейностью в единицы ppm, что тоже колдунство какое-то, а вот встроенный предусилитель который даёт 2нВ/градус дрейфа и одновременно с этим шумов грубо говоря <5нВ/Гц^0.5 это уже интересно. я им (платой ADS1263EVM за 200$) заменил keithley2182A на стенде где различными проволочками/катушками индукционными методами магнитные поля измеряются, шумов стало меньше раза в 3. но там сигналы микровольтовые так что динамический диапазон "наверх" и линейность не проверял. https://xdevs.com/review/ti_ads1262_p1/

да вот, вроде даже численно проверил, для коллизии надо чтобы два передатчика попали в "окно" 0.5мкс. сверху гистограммы 256 устройств для задержек 100,200,500,1000, и шириной бина 0.5 мкс, снизу график сколько столбцов выше 1 в процентах от 256, в зависимости от задержки. этот кривой костыль должен отработать один раз при включении, а появление/исчезновение слэйвов по ходу работы - это уже некая авария. время переключения 0.5мкс: десяток тактов или сколько там тактов у msp430 на запись в порт, в течении которых он ещё не переключился и начал передавать, а передачу от соседа уже не увидит. получившиеся 500мкс это время на то что вы называете циклом, принять от одного слэйва ID и отправить ему обратно адрес. У меня в текущем проекте как раз так и сделано для одного из интерфейсов. 1Мбод стабильно. тоже думал над применением физики CAN вместо 485, но не до конца понятно как оно будет жить вместе с нормальными rs485 если их в эту же сеть воткнуть понадобится. можно пойти дальше и просто собрать отдельно ID и попробовать подобрать хэш функцию которая ID в однобайтный адрес преобразует более менее без коллизий, ну и потом отдельно проверить/поменять несколько штук у которых адреса всё-таки совпали.

питание ядра ещё бы посмотреть, особенно если оно внутренним регулятором делается.

вероятность коллизии сильно меньше, так как слэйвы старт биты других всё же могут отлавливать и соответственно заведомо не начинать передавать в течении следующих 10бит. чтобы коллизия произошла надо двум точно попасть друг в друга с точностью ~ 0.3-0.5мкс (время переключения приём/передача) тогда, не заметив друг друга, начнут передавать оба. если появляются по одному, то времени надо ровно те же 500мкс, на посылку слэйвом запроса "вот мой ID, кто я?" и получение ответа. на ходу никто подключаться/отключаться скорее всего не будет, но если будет, то слэйв сам сразу же сообщающий при появлении "а вот он я", как только увидел что шина свободна (без активности больше 10мкс), всяко быстрее чем периодический поллинг мастером "а не появился ли кто?", но ценой хоть и мало-, но всё же вероятных коллизий, на время присвоения адресов. а 500мкс получились и так для для максимального возможного количества слэйвов на шине, больше драйвера просто не потянут электрически.

даже с "трёхбитным" байтом вместо 10, (для ответа, для запроса 1 бита всё равно маловато будет) ускорение раза в 2, то есть как пересылка нормальных 64байт ну или 640мкс. а слэйву сказать "вот он мой 8ми байтный ID" и ответить мастеру "вот твой ID + вот твой адресный байт" - всего байт 20 туда+обратно или 200мкс. у слэйва от проверки на занятость шины до её занятия, когда может возникнуть коллизия - ну пусть 0.5мкс (msp430 запись бита в порт которая направление переключит и тем самым прерывания запретит - несколько тактов, пусть будет 8), даже если для 256 слэйвов сделать рандомную задержку от 0 до 0.5*256*4 ~ 512мкс, что даст в среднем 256мкс задержки на слэйв, то коллизия будет (если меня тервер не подводит) меньше чем у 10% которых надо будет переслать повторно. так что похоже что те же 256+200+10% ~ 500..600мкс на слэйва. но не совсем грантированные, это да.

динамический диапазон в 5% от 1мА - 10А это 106дБ в полосе 20кГц не так уж и мало, но и не ужас-ужас. почему не взять какое-нибудь недавнее достижение АЦПстроения, вроде ads1263, и измерить им всё сразу и целиком без каких-либо предусилителей и фильтров. AC/DC потом и в цифре разделить можно если так надо.

ёмкость довольно большая, 40мкФ, будет скорее всего с каким попало диэлектриком у которого может оказаться довольно сильным эффект поляризации диэлектрика (dielectric absorption).

ну да, я это и имел ввиду под "перебирать побитно как в 1wire". по скорости можно и не оптимизировать особо, но если реализовать "мультимастер" на время энумерации, когда все просто начитают спрашивать мастера "вот мой ID, кто я?" с радномными задержками, чтобы минимизировать коллизии. У слэйва есть только пара тактов чтобы послушав линию что никто не передаёт, переключиться на передачу именно одновременно с соседом и устроить коллизию, так что вероятность вроде не сильно большая. так вроде бы будет заметно быстрее, чем по 128байт (запрос+ответ каждого бита) на каждого слэйва, но зато не очень "детерминированно". з.ы. контроллер xmc48 угадали :) слэйвы msp430.

как я узнаю длинные 8ми байтные ID? подключаться сначала по одному и читать? ну так этого и хотелось бы избежать. кановский арбитраж на физическом уровне выполняется, и когда передающий видит, что то, что он передаёт в шину отличается от того что он сразу же обратно принимает - это значит что на шине в данный момент есть кто-то с приоритетом повыше и надо пока отвалить. с 485 так не получится

мультимастера при нормальной работе нет, он возможно нужен для начальной "енумерации" устройств, если только не опрашивать эти id побитно как в 1wire.

эти 8байтные ID сначала надо как-то прочитать, ну и чтобы было веселее RE и DE на драйвере 485 закорочены вместе, так что слушать что сам передаёшь и не испортил ли кто передачу не выйдет. и у rs485 в отличии от CANа не предусмотрены доминантные/рецессивные уровни, и кто там кого перетянет - хз. так что вопрос про "нормальный collision detection" остаётся открытым.

Есть несколько одинаковых устройств на шине rs485. У каждого МК есть свой уникальный ID, но 8ми байтный - устанешь сканировать. (хотя наверное можно как-нибудь побитно как в 1wire) Надо как-то раздать всем логические адреса 1-2 байтные логические адреса. Можно это конечно делать при первичном программировании своего бутлоадера, или даже задавать джамперами, но не хотелось бы. Хочется понять есть ли какие-нибудь нормальные способы опросить/просканировать одинаковые устройства на предмет их уникальных ID чтобы потом раздать им адреса, причем через rs485 , у которого нормального collision detection не очень предусмотрено. хотя у МК даже есть отдельно прерывание на стартовый бит от уарта, так что понять что кто-то начал говорить на шине вроде можно. пока что выходит некий аналог dhcp, устройства просыпаются и начинают спрашивать мастера "кто я?", со случайными задержками чтобы избежать коллизий.

из того чем приходилось пользоваться: американский https://oshpark.com вполне себе аналог jlcpcb, даже по цене, особенно если платы совсем небольшие. а вот европейский https://www.wedirekt.de/en/pcb1 , только вот цены там не совсем китайские, те же 10 штук 2х слойных 100х100мм плат выйдут там в ~200EUR.