Перейти к содержанию
    

_pv

Свой
  • Постов

    4 410
  • Зарегистрирован

  • Посещение

  • Победитель дней

    18

Весь контент _pv


  1. я не ТС, что именно там предупреждения вызывает и почему он не модель памяти переключил, а стал бороться с ворнингами их отключением, ответить не могу. там ещё ряд инструкций типа CALL и RET отличаются у CPU и CPUX, и если уж он взял порт от CPUX то со small моделью какие-нибудь ассемблерные вставки в коде RTOS которые сделают RETA вместо RET и со стека 4 байта заберут вместо двух, могут заработать ещё хуже. а так хотя бы проблемы начнутся (и придётся делать по нормальному) только при превышении по размеру кода 🙂 у MSP430F5528 да
  2. это для размерности данных, векторное 3хмерное поле вместо скалярного можно как {R,G,B} отобразить, а если величина скалярная, но в 4х мерном пространстве как цвет поможет?
  3. больше двух измерений сложно изображать на плоском 2д экране, в качестве третьего измерения можно время использовать. можно и 3д конечно, но уже непрозрачность изображаемого мешает, тоже надо делать гифку и добавлять вращение вокруг какой-нибудь оси чтобы третье измерение видно было на 2х мерной проекции на экран. либо иметь возможность руками это 3д покрутить, иначе мало что видно. проще 2х мерные графики срезов по остальным двум измерениям:
  4. первые ~16к память и периферия, так что флэша до ffff остаётся ~48k исполнять-то может везде, но после сохранения контекста RTOS и последующем восстановлении из стэка обратно только 16ти бит PC внезапно может ускакать куда-то не туда вниз.
  5. ну пока за 48кб флэша не вылезет - не страшно. но в целом да, бороться с такими ворнингами их отключением - это пять.
  6. там ещё CDS есть, которому большое выходное сопротивление может не понравиться. из-за того что вторая половина входной разделительной ёмкости через "большое" выходное сопротивление делителя "висит в воздухе", он возможно просто свои сэмплирующие несколько пФ не успевает зарядить через килоомы делителя за те ~20-30нс что между SHP/SHD вот и оцифровывает потом меньше чем надо. осциллограммы покажите, с выхода матрицы и с обеих сторон разделительной ёмкости (с буфера и непосредственно на ножке АЦП после ёмкости).
  7. картинки стали симметричными, можно и двумя-тремя радиальными коэффициентами обойтись c 1+Ki*r^2i как обычно делают. ещё для количественной оценки кривизны наверное можно просто преобразование Хафа от картинки делать и смотреть на распределение "углов" линий, после правильной коррекции там должна быть только пара узких вертикальных полос соответсвующих строго вертикальным ( \( \theta = \pi / 2 \) ) и горизонтальным линиям( \( \theta = 0 \) ). их ширина и будет показывать общую "кривость" объектива, которую и надо минимизировать подбирая коэффициенты перед r^2i. но картинку почистить надо, или хотя бы миллимитровые линии убрать, которые только дополнительный шум дают.
  8. то, что я описал и в esp32 упихать можно попробовать. но если всё равно придётся вытаскивать картинку наружу, то проще на телефон "калибровку" переложить, тем более что если это действителньо линзы сильно кривые, возможно сделать полностью автоматическую калибровку, с единственной кнопкой "сделать за@#$%ь", которая работает железно в любых условиях будет сложнее чем "полуавтоматическую", где параметры натягиваемой сетки можно немного на ходу подкрутить руками, глядя на кривой результат, то есть добавляется ещё какой-то пользовательский интерфейс.
  9. качество картинки отвратительное конечно, но если пройтись градиентным фильтром и размазать gr = ImageAdjust[GaussianFilter[GradientFilter[GaussianFilter[ColorConvert[img, "Grayscale"], 2], 2], 4]] что-то разглядеть можно вытащить данные и натянуть 2х мерный фит экспоненты, погнутой вдоль полинома grd = ImageData[gr]; data = Flatten[Table[{x, y, grd[[y, x]]}, {y, Length[grd]}, {x, Length[grd[[1]]]}], 1]; expr = a*Exp[-(y - (y0 + y1*x + y2*x^2 + y3*x^3 + y4*x^4))^2/2/sy] + b; fit = FindFit[data, expr, {{y0, #}, {y1, 0}, {y2, 0}, {y3, 0}, {y4, 0}, {sy, 5}, {a, 0.2}, {b, 0.3}}, {x, y}] & /@ {75, 130, 175, 220, 264, 308, 351, 393, 435, 490} выглядит как-то так вблизи {{y0 -> 87.7292, y1 -> -0.146309, y2 -> 0.000279265, y3 -> 3.62452*10^-7, y4 -> -7.28475*10^-10, sy -> 4.45341, a -> 0.11059, b -> 0.293883}, {y0 -> 134.557, y1 -> -0.287593, y2 -> 0.00148697, y3 -> -2.73506*10^-6, y4 -> 1.73526*10^-9, sy -> 5.88032, a -> 0.186041, b -> 0.292935}, {y0 -> 175.161, y1 -> -0.216324, y2 -> 0.00129499, y3 -> -2.53724*10^-6, y4 -> 1.6346*10^-9, sy -> 6.31835, a -> 0.207331, b -> 0.29263}, {y0 -> 219.418, y1 -> -0.146834, y2 -> 0.000903935, y3 -> -1.76892*10^-6, y4 -> 1.11553*10^-9, sy -> 5.16709, a -> 0.246005, b -> 0.292465}, {y0 -> 263.825, y1 -> -0.0721467, y2 -> 0.000454634, y3 -> -9.13689*10^-7, y4 -> 5.80904*10^-10, sy -> 4.6724, a -> 0.271664, b -> 0.292343}, {y0 -> 307.561, y1 -> 0.0313504, y2 -> -0.000230062, y3 -> 4.92199*10^-7, y4 -> -3.41197*10^-10, sy -> 4.70917, a -> 0.265807, b -> 0.292388}, {y0 -> 351.353, y1 -> 0.111996, y2 -> -0.000739691, y3 -> 1.48542*10^-6, y4 -> -9.68673*10^-10, sy -> 5.46529, a -> 0.236075, b -> 0.292496}, {y0 -> 393.196, y1 -> 0.174529, y2 -> -0.000967397, y3 -> 1.69454*10^-6, y4 -> -9.70441*10^-10, sy -> 6.22441, a -> 0.193682, b -> 0.292795}, {y0 -> 435.257, y1 -> 0.187255, y2 -> -0.000874856, y3 -> 1.35374*10^-6, y4 -> -7.22933*10^-10, sy -> 6.19187, a -> 0.199524, b -> 0.292738}, {y0 -> 475.104, y1 -> 0.158682, y2 -> -0.000352023, y3 -> -2.07054*10^-7, y4 -> 5.87065*10^-10, sy -> 5.55553, a -> 0.140875, b -> 0.293453}} сам по себе, особенно на краях, фит немного не справился, Show[ImageReflect[gr], Plot[((y0 + y1*x + y2*x^2 + y3*x^3 + y4*x^4) /. #) & /@ {fit}, {x, 1, Length[grd[[1]]]}, PlotStyle -> {Red, Thick}]] надо ему аккуратнее подсказывать начальные условия, ну или картинку с нормальной освещённостью снять. останется сделать то же самое по вертикали, получится dx,dy от (x,y) и потом вывернуть полиномы для обратного преобразования. но вот делать это полностью автоматически без подсказок внутри esp32 я бы не стал, на время калибровки wifi/синезуб поднять для получения картинки будет имхо куда проще.
  10. что-то сетка очень уж кривая получилась и совсем не симметрично погнутая. с двумя "максимумами рыбоглазности" слева и справа от центра. выглядит так, будто фотографировался не совсем ровный лист бумаги. вот тут помимо радиальных, в тангенциальных искажениях опять полином от радиуса добавлен, то есть не только "поворот", а ещё и типа твист. но то что на картинке из-за своей несимметричности похоже надо лечить каким-то произвольным полиномом от x,y, а не радиально симетричным по r с чётными степенями.
  11. на умножение со сдвигами можно и не заморачиваться, а вот на деление - совсем другое дело, там пара сотен тактов выйдет вместо взятия старшего байта, поэтому домножить всё и внутри скобок и делитель на 256/100. тогда и получится ((data[4]-'0')*6554+(data[5]-'0')*655 + 128) >> 8 и у ТС вроде как раз третий случай 0..100 -> 0..255
  12. ws2811 - отдельные 3х канальные шим контроллеры в soic8, что в адресных светодиодах типа ws2812 внутри.
  13. шаг там в любом случае будет равномерный, особенно на выходе после округления до 8 бит, или 2 или 3, вопрос лишь в том чему должно соответствовать значение 99: 253 или 255 (полностью '1' на выходе шима). data d*255/99 d*256/100 0 0 0 0 0 1 2.576 3 2.56 3 2 5.152 5 5.12 5 3 7.727 8 7.68 8 4 10.303 10 10.24 10 5 12.879 13 12.8 13 6 15.455 15 15.36 15 7 18.03 18 17.92 18 8 20.606 21 20.48 20 9 23.182 23 23.04 23 10 25.758 26 25.6 26 11 28.333 28 28.16 28 ... 88 226.667 227 225.28 225 89 229.242 229 227.84 228 90 231.818 232 230.4 230 91 234.394 234 232.96 233 92 236.97 237 235.52 236 93 239.545 240 238.08 238 94 242.121 242 240.64 241 95 244.697 245 243.2 243 96 247.273 247 245.76 246 97 249.848 250 248.32 248 98 252.424 252 250.88 251 99 255 255 253.44 253 раз ТС говорит что 99 это 99% то да 256/100, ну или 253/99, что с 8ми битной точностью одно и то же. а вообще пусть lookup таблицу на 100 байт делает и заполняет её как хочет :) O - оптимизация
  14. 0 -> 0 99 -> 255 числа 100 там нету, не влезо, и очень возможно что 99 должно соответствовать полному заполнению шима 255, а не 99*(256/100) == 253. ((data[4]-'0')*6594+(data[5]-'0')*659 + 128) >> 8 ну или ((data[4]-'0')*6554+(data[5]-'0')*655 + 128) >> 8 если всё-таки 99 это именно 99%
  15. 24-bit ADC

    не всегда нужен именно максимальный динамический диапазон, тем более без усиления с полной 5В шкалой. если на абсолютное значение шумов посмотреть на максимальном усилении встроенного PGA, там ровно наоборот 122нВ rms шума против 48нВ, на тех же 50Гц.
  16. там slew rate только для больших сигналов указан, если взять его то всё будет выглядеть печально. на fig. 26 и 27 видно как они отличаются до 5в быстрая ступенька, а потом ограниченный slew rate, да и заявленный GBW >10МГц как бы намекает что с K=1 для небольших сигналов может и справится, но надо проверять.
  17. stm32 Cинусоида.

    на четверть периода, остальное решается примитивной арифметикой с сложением/вычитанием индекса, чтобы он в нужное место внутри этого четверть периода попал.
  18. ppm от шкалы, если шкала 1В то ppm == мкВ. график для 100мВ вниз на порядок сдвинуть, для 10В вверх на порядок, и будут мкВ по вертикали. на предыдущей до него странице в этой теме такой же график в абсолютных "попугаях" можно горизонтальную ось интвертировать и строить привычную спектральную плотность от частоты, а не rms шума от времени, смысл особо не поменяется. конечно анализатор полезная вещь, но что собственные шумы у вольтметра есть и что при добавлении, например, экрана вокруг источника питания они изменились в лучшую сторону можно понять и не измеряя диаграмму направленности в безэховой камере отдельно источника питания по всем частотам до ГГц. ну при большом желании можно сделать идеальный заэкранированный источник питания, но провода от входа внутри так коряво проложить огромными петлями с кучей витков что вольтметр в магнитометр превратится и будет показывать не приложенное напряжение, а возмущения магнитного поля Земли :)
  19. если речь про источники питания для вольтметров, то они и сами себя в какой-то мере измерить могут и без дополнительного оборудования, особенно если про 50Гц. как @iddqd2001 выше показал так что совсем не обязательно начинать трансформаторный источник питания на 50Гц с покупки 1ГГц спектранализатора и построения безэховой камеры.
  20. Нет конечно, ведь тогда придётся признать что обосрались с питанием и сделали не нановольтметр, а показометр сетевого напряжения питания. Поэтому скромно умолчали, приведя вместо нормального графика только циферку шумов при 1 и 10 NPLC. Если считаете это нормальным, то когда в следующий раз любой даташит откроете, дальше первой страницы не листайте, обычно ведь все основные параметры там и так указаны, а все эти скучные графики и условия измерения это знать ни к чему, да и притензий никаких не будет. CMRR не бесконечный, да и дополнительно его можно довольно просто испоганить, например, неаккуратно сделав фильтр на входе и неидеальностью компонентов / паразитами симметрию подпортить.
  21. сравнивать можно на каких-то определённых задачах. мне вот надо измерять небольшие напряжения (интегралы напряжения) с минимальными шумами, с временами от сотни Гц и до нескольких минут. простой тест на шумы на закоротке вполне позволяет сравнить кто при заданном времени интегрирования будет шуметь меньше. 7195 и 1263 ведут себя более менее одинаково (оба с sinc4) у обоих ~5нВ/Гц^0.5 на входе и наличие чоппера который и на минутных временах не позволяет НЧ шумам расти. да не хочется ничего сравнивать, когда надо что-нибудь измерить хочется взять готовый прибор и не выяснять откуда там у него изнутри пролезают собственные шумы, если их дополнительно не давить временем интегрирования в 20мс, что не всегда возможно. на одном из измерительных стендов (длинная натянутая проволока ездит в магнитном поле, измеряются наведённые микровольты) поменяли кисли 2182a на готовую плату ads1263evm, при прочих равных условиях в результате по шумам стало раза в 3 лучше.
×
×
  • Создать...