Форум РадиоКот

Для повышения достоверности. В поисковом режиме важно очень быстро подать сигнал. А чем меньше зон, тем больше в одну зону попадает значений за единицу времени и тем больше достоверность.

Я говорил про задействование очень грубого спектра в поисковом режиме, чтобы отсеять влияние достаточно сильного мешающего фона. Под грубым спектром я имею ввиду не спектр на все 1024 (4096 и т.п.) значения, а на 4-8 зон. Но это уже чисто детали реализации

Я совсем про другое... Ну да и ладно )

В случае с поисковым режимом я имел ввиду не полноценный спектр, а очень грубый (по всему диапазону, но всего несколько зон)

Ну типа с энергокомпенсацией дозиметр круче. Хотя для самоделок это не принципиально )))

И для поискового режима энергия частиц тоже полезна. Можно быстро строить упрощённую спектрограмму фона, а потом при поиске её вычитать. Говорят, что это довольно полезная функция. Я её у себя реализовал, но ...

Да, всё верно. Разрешение при этом ниже чем при прямом измерении амплитуды. Но при обычном замере дозы для энергокомпенации высокое разрешение и не нужно. Там +-5кэВ погоды не сделают.

Для энергокомпенсации при расчёте дозы не обязательно задействовать АЦП! Достаточно измерять длительность импульса от частицы, т.к. она зависит от амплитуды (а перед этим откалибровать зависимость "амплитуда->длина импульса"). Фактически в этом случае, нам не нужен, ни АЦП, ни усилитель ...

Тогда другой вопрос. А зачем спектр измерять непрерывно? Это же довольно редкая ситуация, когда нужно знать энергетический состав излучения. Обычно такие приборы используются просто как поисковые или как дозиметры, а спектр - это как правило дополнительная функция

С усилителем такая хитрость. Обычно для гамма-спектрометрии предусилитель представляет собой дифференциатор+интегратор+фильтр, чтобы импульсы были стандартной формы, а также чтобы чётко выделять наложившиеся друг на друга импульсы. Такой усилитель состоит из нескольких каскадов и выходной сигнал у ...

Насчёт ОУ понятно. Я тогда использовал STM32L1-серию. Мне хватало и встроенного ОУ (3 МГц) и встроенного компаратора, чтобы успевать запускать АЦП для оцифровки импульса от частицы. Видимо у L4-серии с этим похуже

Делал почти такой-же очень-очень давно. Не понятно почему не используется встроенный в МК операционный усилитель. С ним схема была бы проще
PS: открыл проект на гитхабе. Походил по папкам, ничего не понятно. Куча временных файлов валяется, которых там не должно быть

Добавлено after 1 minute 33 ...

Да вообще вопрос вроде как решённый, в том числе для ТС. Непонятно о чём тут спорить )

[uquote="Reflector",url="/forum/viewtopic.php?p=4097508#p4097508"]Куда в этом корректном примере запишется последний байт?[/uquote]
Последний байт запишется корректно, потому что адрес &aaa+1 выровненный, т.к. у aaa тип uint64_t ))

Добавлено after 7 minutes 45 seconds:
[uquote="jcxz",url="/forum ...

[uquote="jcxz",url="/forum/viewtopic.php?p=4097480#p4097480"]Т.е. - volatile в случае GCC никак не спасает от исключения невыровненного доступа. Не поможет оно.[/uquote]

В моём случае я использовал volatile только для подавления оптимизации, чтобы гарантированно сгенерировался код записи по адресу ...

Ну да, всё правильно. А как это противоречит тому, что я говорил? Я всего-лишь показал, что если компилятор сразу видит, что адрес невыровненный, то он компилирует побайтную запись. Но если как в случае с ТС, компилятор этого не знает, то генерируется оптимальный код, который падает при подаче в ...

jcxz, если не веришь, можешь просто поиграться онлайн:
https://gcc.godbolt.org/z/ex1e5dcah
Там налету и компилируется и дизасемблер отображается. Опции компиляции тоже можно менять

[uquote="jcxz",url="/forum/viewtopic.php?p=4097296#p4097296"]А какое это имеет отношение к теме? Такое сгенерилось видимо для какого-то младшего ядра (M0, etc.)[/uquote]

Забыл указать. Компилировалось это с флагом -mcpu=cortex-m4 для STM32F401

Сейчас проверил. Для cortex-m3 генерируется точно ...

Если заранее неизвестно, то компилятор генерирует максимально быстрый код, не допускающий невыровненные адреса Это достаточно разумный подход, но приводящий к хардфаулту у программистов, которые ещё не знают от такой особенности ))

Если компилятор заранее знает, что будет идти доступ по невыровненному адресу, то он будет это делать побайтно.

char aaa[10] = {};
volatile uint64_t *ptr = (uint64_t*)(aaa+1);
*ptr = 0x1234567887654321;


Последнюю строку gcc-arm-none-eabi-10.3-2021.07 при -O3 компилирует в

ldrb.w r3, [sp, #13 ...

В этом примере программист сам себе злобный буратино, т.к. код изначально допускает обращение по невыровненному адресу.