_pv

https://www.arrow.de/categories/computer-products/applied-computing-and-embedded-systems/system-on-modules---som в основном с разъёмом под "память", но там попадаются и SMD модули с I.MX или Cortex-A5 от микрочипа, которые хоть и не сильно далеко ушли от Omega c медиатеком, но всё-таки. или даже OSD3358 - куда уж меньше.

добавить между ними какой-нибудь одноплатный ПК за 10$ у которого есть и ethernet и человеческий USB.

а езернета у него нету?

как-то для какого-то маложоркого усройства после подсчёта всех джоулей, необходимых для довольно несложного фильтра для сигнала в первые кГц оказалось гораздо выгоднее сгородить его на малопотребляющих ОУ и потом только цифровать, чем делать это в цифре. так что внешнее АЦП, со сдвиговыми регистрами и ФИФО, как предложил HardEgor, может вполне оказаться гораздо выгоднее по потреблению. встроенные в МК опоры АЦП обычно жрут довольно много, выгоднее на IO повесить внешнюю она и "включаться" будет быстрее, но в вашем случае когда цифровать надо непрерывно не вариант, но когда МК выбирать будете на потребление внутренней опоры поглядеть полезно. и запись во flash сама по себе может тоже съесть довольно много джоулей по сравнению с fram например.

у мелких lpc8xx в ацп тоже есть цифровые компараторы. и M0 пожалуй поменьше жрать должен чем двухголовый M33.

дифф нелинейность такая, если встать около кода 2048 и там набрать гистограмму она ещё более кривая будет. ну и хвосты у вашей гистограммы подальше тянутся, видимо действительно что-то совсем низкочастотное всё же есть. на графике спектра, на 10 Гц почему-то меньше чем на 20. да и к 40кГц тоже почему-то расти начинает. сделайте 1М или больше точек, может удастся с лучшим разрешением что-нибудь необычного разглядеть в области < 100Гц. upd: А не, с гистограммой всё нормально один в один с даташитом, это она нарисована просто не от 0.

хотите аккуратное DC - берите медленные сигма-дельта АЦП, у которых чоппер-стабилизация в предусилителях. косвено по гистограмме судить можно, только вот на этой гистограмме из даташита набрано всего ~50k отсчётов, что на 2Мспс всего 25мс или 40Гц. можно пересчитать эти 2 lsb среднеквадратичного шума с гистограммы из даташита при 40Гц в ваши полученные мкВ. а можно тоже понабирать такие же гистограммы шума по 1000, 10000, 100000, 1000000 отсчётов. по распределению возможно лучше будет видно что за шум если действительно что-то не так. а то многовато что-то получилось частота среза 1/f шума под килогерц. хотя если в даташите по НЧ шумы привести постеснялись, возможно так оно и есть :)

ну из 1588 при прямом подключении без гирлянд из свичей, 30нс вроде можно вытащить. хотя возможно под соединением езернет кабелем имеется ввиду именно кабель, то есть 4 витые пары, а не сам езернет как таковой. умножить на 4 и поделить обратно опираясь уже на сигнал с нужной фазой. либо передавать и клоки и клоки/4 с нужной фазой, ну или вообще просто передавать все четыре квадратурных клока от мастера и не генерить их отдельно в слэйве.

передавать поделённый на 4 клок с нужной фазой?

не начнёт, мало того чем выше частота тем больше латентность прерываний в нс все ближе приближается к 8ми битным АВРам и пикам. :) вам об этом с самого начала намекали, заодно пытаясь выяснить что именно вы с этими данными делать собрались. а если всё-таки прочитать всё сообщение целиком, а не только первое предложение?

изначально вопрос был про 32 байта за сотню нс, что скорее равно 2Гбитам. Если у вас по одному биту раз в милисекунду меняется, возьмите 10битную шину, и при изменении какого-либо бита, передавайте его номер (32 байта = 256 бит) - 8 бит, его значение +1 бит и ещё один статусный бит, который будет говорить поменялось ли чего или нет. а потом это можно засунуть в любой serdes, вроде SN65LV1023A, если параллельные шины тащить не хочется, и если один МК выставил на параллельный порт что у него какой-то бит поменялся, то второй через ~20-30нс увидит какой именно. соответственно быстро передаются изменения конкретного бита, а медленно в фоне, когда статусный бит == 0, значения всех остальных битов, просто на всякий случай чтобы не рассинхронизоваться при передаче только изменений.

Вы уже удалили все свои репозитории с гитхаба? А то ведь он тоже принадлежит самой поганой в мире фирме.

на картинке нарисованы шумы усилителей, среднеквадратичные значения. если всё же считаете что данные деятели решили проверить закон Ома и нарисовали ток через ёмкость в зависимости от частоты, ну даже не знаю, найдите что ли описание картинок, они там на отдельной странице. 100пА шума при том, что столько нарисовано на графике когда ёмкость сенсора 100пФ, а полоса 100кГц. для меньшей полосы будет меньший шум, не нравится 100кГц, ну посчитайте шумы DDC316 для 5 кГц будет тоже около пары пА.

у усилителя из статьи 100пА шума при 100кГц полосы на 100пФ датчике. (Fig. 3) у DDC316 при 100пФ на датчике - 10LSB шума от 3 пКл диапазона, то есть 0.45фКл, что при 10 мкс интегрирования или тех же 100кГц даст 45пА шума. что-то как-то незаметно разницы особенно в "низкой чувствительности к ёмкости сенсора". мультиплексируя вход в любом случае где-то после мультиплексора во столько же раз и даже больше вырастет требуемая полоса для усиления/оцифровки N каналов переключающихся последовательно, и соответственно в лучшем случае в корень из N раз вырастут шумы. но от жизни отстали почему-то AD и TI, которые вместо быстрого усилителя/АЦП и доступных мультиплексоров зачем-то лепят параллельно 128-256 небыстрых усилителей/АЦП.

версию альтиума скрывает. раньше альтиум (судя по скриншотам параметров пада) похоже позволял оставить отверстие в паде даже когда пад не multilayer. соответственно с закороткой остальных слоёв. а вот как это в DRC не попало - загадка. у меня 17й, он так делать не разрешает.