Согласен, в примере схемы подключения, с T_IRQ получилось не логично. Скорректирую чуть позже схему, что бы при желании можно было использовать обработчик прерывания.
Однако, для текущей программной реализации это не критично, т.к. uGFX приложения — loop based, и состояние PIN-a опрашивается в основном цикле.
Да и читать из SPI в обработчике прерывания, увы не получится — нет гарантий, что в момент прерывания шина будет свободна...
По производительности конечно потянет. Больше опасаюсь за режим работы I2S. Подключение PDM микрфона к I2S это "фирменный" хак stm32, который возможно на esp32 не прокатит.
А программно собирать по битику синхронный PDM поток мегабит/сек — надругательство над контроллером.
class IButtonClickObserver {
public:
virtual void onButtonToggle () = 0;
};
class PushButton {
public:
PushButton (IButtonClickObserver *observer) : observer_ (observer){}
private:
void onToggle () {observer_->onButtonToggle();}
IButtonClickObserver *observer_;
};
class MyApp : public IButtonClickObserver {
MyApp () : button_ (this){}
void onButtonToggle () override final { /* do smthing useful */}
private:
PushButton button_;
};
Это с использованием виртуальных функций. Можно с шаблонами, код будет посложнее, однако удастся избежать лишнего указателя на vtable и убрать интерфейс observer. Можно так и так, но первый вариант на мой вкус удобочтимее.
Spectre с большой вероятностью работает на всех ipad/iphone. Практически все современные ARM ядра ей подвержены.
Meltdown подвержены только ядра ARM Cortex-A75 (на них еще нет выпущенных процессоров)
Однако, Apple не использует готовые ядра Cortex, а разрабатывает ядра сама. На текущий момент нет информации об атаке Meltdown на ARM ядра Apple. Вот ждемс информацию.
Увы, без серьезных вычислительных мощностей/приличного объема памяти/тренировки hmm и нейронки на большом объеме записей сделать speaker independent распознавание, которое будет работать в любом акустическом окружении практически не реально.
Думаю, что порог входа для качественного распознавания набора команд on-device нужна железка порядка Raspberry PI
Согласен, сейчас пример кода на уровне "proof-of-concept", и читать всю системную память он не сможет by design/
Однако, в голову приходит такое практическое применение дырки — найти в памяти куки (в памяти сандбокса вполне могут остаться куки от ранее посещенных во вкладке страниц), и утащить себе валидные session_id/token-ы от чужих сервисов.
Конечно, задача не тривиальная, но увы, кажется решаемая.
Речь про iPhone/iPad — Apple для них пилит свои ARMv8 -совместимые процессоры. У оригинальных ARM Cortex-Axx самой опасной уязвимости (чтение памяти ядра/других процесов) подвержены только Cortex-A75.
Информации об наличии/отсутствии проблем в процессорах Apple-A пока нет. Ждем!
В обычный тройник-пилот 4-е таких розетки скорее всего не влезут — размеры не позволят, да и управлять ими можно только с родного пульта, без всякого голосового управления, и без интеграции с умным домом…
А те, что влезут, например, Fibaro будут стоить ~22т.р. за комплект.
В плате используется esp8266 c 10-ти битным АЦП, но проблема в том, что если включен wifi модуль, то с АЦП считывается только шум.
esp32 не успел пробовать. Недавно заказал несколько модулей, как приедут — попробую. К встроенному в esp32 АЦП все же отношусь скептически. С большой вероятностью будут такие же грабли — сильная зашумленость от wifi.
А вариант с внешним цифровым PDM микрофоном планирую опробовать и без stm32 — есть вероятность, что потянет.
Давно. В стандарте gnu89 она есть.
gcc заслуженно очень популярный компилятор, бесспорно. но в случая с языками аппелировать надо к стандартам IEEE, как к общепринятым.
gcc считает (и правильно делает) по другому. gcc 4.8.2 arm:
Какие опции командной строки? Какие конфигурации? Ну хоть gcc -v сделайте.
Ваш опыт означает, что именно при ваших опциях он так не работает. Но не означает, что он ВСЕГДА работает не так.
С говнокодом так обычно и бывает. "Код хороший, а опции компилятора плохие!" Удачи
Это называется UB (undefined behavior). Или вы доказываете, что это UB по стандарту gcc, или — это отступление от стандарта. То самое, про которое вы говорили, что его не бывает. Или — вы просто не смогли разобраться. Что вероятнее всего.
А давно это pragma pack появилась в стандарте? Вы уж определитесь вы либо про стандарт либо про pragma pack. Вместе нельзя.
ДА. В машинном коде именно так. Вот только не на каждый. Похоже, что вы действительно не разбираетесь в кодогенерации. Ну вам простительно — вы не компиляторщик.
pragma pack
struct test {
int even;
char a;
int odd;};
Код для обращения к even будет простым, а вот для обращения к odd — сложным. Зато &odd не всегда (не во всех версиях gcc и не во всех режимах оптимизации) можно передать параметром в процедуру. Это при выровненном test. Если у нас массив test — то к обоим поля обращаться будем через сложный код. Ещё один момент — в рассуждениях выше struct test выровнен.
Вы как обычно написали чушь. gcc считает (и правильно делает) по другому.
gcc 4.8.2 arm:
#include <stdio.h>
#include <memory.h>
#pragma pack (1)
struct test {
int even;
char a;
int odd;};
void foo(struct test *t)
{
printf ("%d,%d",t->even,t->odd);
}
foo(test*):
movw r1, #:lower16:.LC0
ldr r3, [r0, #5] @ unaligned
ldr r2, [r0] @ unaligned
movt r1, #:upper16:.LC0
movs r0, #1
b __printf_chk
.LC0:
.ascii "%d,%d\000"
Позвольте вам не поверить. Жду доказательств.
Грубо говоря вы считаете, что использование #pragma pack(push,1) (ну или alignas)в описании структур неверно >реализовано в gcc и это не является багом компилятора???
Вы либо не умеете читать, либо не понимаете разницы между "использование #pragma pack(push,1) (ну или alignas)в описании структур неверно >реализовано в gcc и это не является багом компилятора?" и "Обращения к полям структур с кастомными алигнмент структур это прямой путь получить на железе исключения unaligned access или вообще просто считать корраптед данные"
gcc генерит инструкцию, которая читает/пишет слова по не выровненным адресам. А справится ли с ней процессор, уже зависит от конкретной реализации процессора. Например на ARM,
ldr r2, [r0]
Если в r0 нечетный адрес, то возможны три варианта — считает правильное значение/выкинет аппаратное исключение/считает значение по ближайшему выровненному адресу.
Поведение зависит от возможностей ядра и битов управляющих регистров.
На этапе компиляции компилятор не знает, как будет себя вести инструкция на железе. Вы видимо ожидаете, что компилятор по умолчанию вставляет на каждый дерефернс указателя int * вот такую пачку инструкций вместо одной:
Обращение по не выровненному адресу — популярные грабли при программировании embed. Обычно это вызывает исключение, однако в вашем случае исключения процессора unaligned access были отключены/не предусмотрены процессором. (Кстати правда, а что у вас за чип)?
Таких приведений указателей лучше избегать, однако если очень хочется, то в gcc >= 4.8 есть специальный ключ ''-mno-unaligned-access" — он автоматически генерит код обращения к полям типов с учетом выравнивания:
Обратите внимание на typedef unaligned_int. Он говорит компилятору, что этот тип может размещаться по любому адресу без выравнивания.
Поправил
Примерно от 20Кб до 80Кб, в зависимости от используемого функционала.
Согласен, в примере схемы подключения, с T_IRQ получилось не логично. Скорректирую чуть позже схему, что бы при желании можно было использовать обработчик прерывания.
Однако, для текущей программной реализации это не критично, т.к. uGFX приложения — loop based, и состояние PIN-a опрашивается в основном цикле.
Да и читать из SPI в обработчике прерывания, увы не получится — нет гарантий, что в момент прерывания шина будет свободна...
По производительности конечно потянет. Больше опасаюсь за режим работы I2S. Подключение PDM микрфона к I2S это "фирменный" хак stm32, который возможно на esp32 не прокатит.
А программно собирать по битику синхронный PDM поток мегабит/сек — надругательство над контроллером.
Наверно имеется ввиду примерно такая конструкция:
Это с использованием виртуальных функций. Можно с шаблонами, код будет посложнее, однако удастся избежать лишнего указателя на vtable и убрать интерфейс observer. Можно так и так, но первый вариант на мой вкус удобочтимее.
Spectre с большой вероятностью работает на всех ipad/iphone. Практически все современные ARM ядра ей подвержены.
Meltdown подвержены только ядра ARM Cortex-A75 (на них еще нет выпущенных процессоров)
Однако, Apple не использует готовые ядра Cortex, а разрабатывает ядра сама. На текущий момент нет информации об атаке Meltdown на ARM ядра Apple. Вот ждемс информацию.
вот так:
Увы, без серьезных вычислительных мощностей/приличного объема памяти/тренировки hmm и нейронки на большом объеме записей сделать speaker independent распознавание, которое будет работать в любом акустическом окружении практически не реально.
Думаю, что порог входа для качественного распознавания набора команд on-device нужна железка порядка Raspberry PI
Согласен, сейчас пример кода на уровне "proof-of-concept", и читать всю системную память он не сможет by design/
Однако, в голову приходит такое практическое применение дырки — найти в памяти куки (в памяти сандбокса вполне могут остаться куки от ранее посещенных во вкладке страниц), и утащить себе валидные session_id/token-ы от чужих сервисов.
Конечно, задача не тривиальная, но увы, кажется решаемая.
https://ru.wikipedia.org/wiki/Apple_Ax я про эти.
Речь про iPhone/iPad — Apple для них пилит свои ARMv8 -совместимые процессоры. У оригинальных ARM Cortex-Axx самой опасной уязвимости (чтение памяти ядра/других процесов) подвержены только Cortex-A75.
Информации об наличии/отсутствии проблем в процессорах Apple-A пока нет. Ждем!
В первоисточнике есть JS сниппет, который читает память процесса браузера https://spectreattack.com/spectre.pdf, эта ссылка есть в статье...
Интрига дня/недели: подвержены ли процессоры Apple?
Что бы подтянуть в наследник конструкторы базового класса можно написать так:
В обычный тройник-пилот 4-е таких розетки скорее всего не влезут — размеры не позволят, да и управлять ими можно только с родного пульта, без всякого голосового управления, и без интеграции с умным домом…
А те, что влезут, например, Fibaro будут стоить ~22т.р. за комплект.
В плате используется esp8266 c 10-ти битным АЦП, но проблема в том, что если включен wifi модуль, то с АЦП считывается только шум.
esp32 не успел пробовать. Недавно заказал несколько модулей, как приедут — попробую. К встроенному в esp32 АЦП все же отношусь скептически. С большой вероятностью будут такие же грабли — сильная зашумленость от wifi.
А вариант с внешним цифровым PDM микрофоном планирую опробовать и без stm32 — есть вероятность, что потянет.
С говнокодом так обычно и бывает. "Код хороший, а опции компилятора плохие!" Удачи
А давно это pragma pack появилась в стандарте? Вы уж определитесь вы либо про стандарт либо про pragma pack. Вместе нельзя.
Вы как обычно написали чушь. gcc считает (и правильно делает) по другому.
gcc 4.8.2 arm:
На сим диалог с вами заканчиваю.
Вы либо не умеете читать, либо не понимаете разницы между "использование #pragma pack(push,1) (ну или alignas)в описании структур неверно >реализовано в gcc и это не является багом компилятора?" и "Обращения к полям структур с кастомными алигнмент структур это прямой путь получить на железе исключения unaligned access или вообще просто считать корраптед данные"
gcc генерит инструкцию, которая читает/пишет слова по не выровненным адресам. А справится ли с ней процессор, уже зависит от конкретной реализации процессора. Например на ARM,
Если в r0 нечетный адрес, то возможны три варианта — считает правильное значение/выкинет аппаратное исключение/считает значение по ближайшему выровненному адресу.
Поведение зависит от возможностей ядра и битов управляющих регистров.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Beihgifg.html (например A8)
На этапе компиляции компилятор не знает, как будет себя вести инструкция на железе. Вы видимо ожидаете, что компилятор по умолчанию вставляет на каждый дерефернс указателя int * вот такую пачку инструкций вместо одной:
Нет, к счастью компиляторы разрабатывают здравомыслящие люди, и компилятор так по умолчанию не делает.
А кто вам мешает писать на паскале? Или даже на обероне, вроде его признали самым самым безопасным языком — вам видимо понравится :)
Дальнейшую чушь про ваше видение стандартов комментировать не вижу смысла.
Обращение по не выровненному адресу — популярные грабли при программировании embed. Обычно это вызывает исключение, однако в вашем случае исключения процессора unaligned access были отключены/не предусмотрены процессором. (Кстати правда, а что у вас за чип)?
Таких приведений указателей лучше избегать, однако если очень хочется, то в gcc >= 4.8 есть специальный ключ ''-mno-unaligned-access" — он автоматически генерит код обращения к полям типов с учетом выравнивания:
Обратите внимание на typedef unaligned_int. Он говорит компилятору, что этот тип может размещаться по любому адресу без выравнивания.
Скомпилируем просто
gcc -Wall -O3
А теперь с ключем -mno-unaligned-access
gcc -Wall -O3 -mno-unaligned-access:
Обратите внимание — компилятор сам нагенерил кода, который вытягивает и собирает int побайтно из не выровненого адреса.