xvr

По мотивам топика - Автор явно не совсем адекватен. В частности ему показалось, что я ему понизил репутацию (хотя это был не я), и он понизил репутацию мне, причём на посте с ответом на его вопрос. На мой несколько эмоциональный вопрос 'какого фига?', он посоветовал мне не истерить и видимо смириться с его действиями (в правильности которых он не секунды не сомневается до сих пор). Вопрос - можно ли как то ограничить манипуляции по понижению кармы для неадекватных пользователей? Например не давать её понижать, пока у тебя самого не появится положительная репутация? В принципе это даст какую-никакую гарантию (не требовать же у всех справку от психиатра при регистрации 🙂 ) Ещё было бы неплохо не давать пользователям действовать сгоряча. Например ограничить количество понижений кармы до 1 штуки в день, и не давать её понижать для конретного поста в течении полу часа после его прочтения (что бы адресат мог несколько остыть). А то я помню Кармные Войны тут уже случались.

В общем случае не должен, но могут быть исключения. Например предкомпилённые хидеры - они собираются в один инклюд, который ДОЛЖЕН включаться первым во все единицы компиляции. Но даже в этом случае ХИДЕРЫ лучше делать полностью независимыми друг от друга. Более того, в некоторых случаях могут быть эксцессы, например в Qt проектах есть тул, который запускается автоматом и создаёт исходники для поддержки RTTI, в них никакие общие хидеры не включаются и порядок включения других хидеров не гаратируется, так что незвисимость всего, что в него попадает - must have. Если же по каким то причинам необходимо выдерживать порядок инклюдов (не спрашивайте по каким именно 🙂 ), то это ОБЯЗАТЕЛЬНО должно быть отражено в проектной документации и очень желательно в самих хидерах (например отслеживать порядок включения внутри хидера и ругаться, что именно и где забыли включить). Програмист должен заниматься программированием, а не сыскной работой 🙂

Я видел тут много хамов, но вы это нечто. За 10 дней на форуме не с того не с его наехать на человека, который вам пытался помочь, в потом учить его жизни. Надеюсь, что мы вас тут больше не увидим.

Его не надо портировать - он вполне кросс платформенный и должен подключитсья к проекту как есть (если повезёт) SqLite хранит свои базы в файле в своём формате. Поменять способ хранения IMHO нельзя

Либо вы троль, либо не понимаете элементарных вещей. На ваш вопрос вам дали весьма подробный ответ. Только цитировать, или понимать их тоже? Я вам пока ничего не понижал, а пытался помочь. Видимо зря. Вот сейчас понижу, за тролинг. Психиатр вам нужен

Я тоже, но в последнее время пересел на KiCAD - прошло довольно быстро и безболезненно 🙂 Рекомендую

ARM тут не при чем. Вам нужен специалист по Linux. Посмотрите сами (это просто). Запустите objdump -p <file.elf> (на ваш elf файл). Будет нечто такое: Program Header: LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12 filesz 0x000000000000f600 memsz 0x000000000000f600 flags r-x LOAD off 0x000000000000f600 vaddr 0x0000000000010600 paddr 0x0000000000010600 align 2**12 filesz 0x0000000000111150 memsz 0x0000000000111150 flags rw- При загрузке вашей программы Linux создаст в виртуальной памяти ТОЛЬКО сегменты, которые помеченны тэгом LOAD. Стартовый адрес (виртуальный) печатается в поле vaddr, размер - в поле memsz. В Linux загрузка начинается не с нуля (на мой пример не смотрите - это не Linux и не ARM, это bare metal RISC-V) Как раз нужно - ибо карта этих самых LOAD сегментов задаётся именно там. Если хотите, что бы gcc позвботился и о вашей памяти не занимайтесь ручным распеделением - сделайте в ассемблере секцию .data и пишите в неё.

Делал в своё время (очень давно) плагин к P-CAD для копирования расстановки одного модуля на все его копии. Разводка копировалась средствами самого P-CAD'а (matrix copy) Кидал сюда. Не уверен, что этот плагин сейчас заработает 😞 PS. Как минимум запустился - hrgr.zip

Запрещено. Вам сюда - https://electronix.ru/forum/index.php?app=forums&module=forums&controller=forums&id=37

Они вводятся разными конструкциями и не совсем одинаковые - в модулях есть net type of declaration, чего нет в блоках.

Потому что там нет памяти. Почитайте на досуге что такое Virtual Memory

А так же то, что не можете дать одинаковые имена сущностям одного типа. И то, что именованные сущности ищутся в иерархии областей видимости. Так что понятие областей видимости и пространств имён в некотором роде пересекаются - области видимости работают внутри пространств имён и то и другое образуют иерархии.

Работа через массив + индекс более безопасна чем работа с указателем на массив - Delphi обеспечивает контроль за выходом за границу массива (если вы его не отключите). Если ошибок нет (и ловить возможные ошибки вы не хотите), то разницы действительно нет 🙂

В модули вложены именованные блоки, а в них вложенны переменные. Так что да, они видны сразу в 2х пространствах. Пространства имён в Verilog не являются независимыми сущностями - они могут быть вложенны друг в друга, так что то, что живёт в них оказываются сразу в нескольких пространствах

inc(pVal, 2) - не оно? А кто вам запрещает передать массив по ссылке? (var в формальном параметре)

Я не в курсе, что такое 'TCP канала на JLINKе', а этот работает так: 1. Там, где подключена желеэка для програмирования (или отладки) запускается специальный сервер, который как раз заведует физическими проводами. 2. Отдельно запускается OpenOCD и ему дают IP адрес (и порт) сервера из п1.

Удалённое махание ногами (BitBang) через внешний сервер (программу) через TCP. Используется с реально удалёнными железками и с симуляторами (Spike в частности использует)

https://vi.aliexpress.com/item/4000152341807.html?spm=a2g0o.order_list.order_list_main.555.52f91802R457eH&gatewayAdapt=glo2vnm

TPIC6(A/B/C)595 - Тот же 74HC595 но с мощными выходами (открытый коллектор)

Пардон, я не имел в виду, что он не нужен. Я имел в виду, что его не надо применять - он опасен. Но если хорошо понимаешь, что делаешь, то можно 🙂 Обычно у людей, которые действительно хорошо понимают, что делают, вопросов такого рода (применять - не применять) не возникает - они и так это всё хорошо знают.

unsigned char buf[4]; unsigned char n_count =0; ISR (TIMER1_COMPA_vect) { PORTB &= ~(1<<PORTB4); //низкий уровень SPDR = buf[n_count]; while(!(SPSR & (1<<SPIF)));//подождем пока данные передадутся SPDR = (1 << n_count) ^ 0xF; while(!(SPSR & (1<<SPIF)));//подождем пока данные передадутся //сгенерируем отрицательный фронт для записи в STORAGE REGISTER PORTB |= (1<<PORTB4); //высокий уровень ++n_count; n_count &= 3; } void putc(int position, char symbol) { char encoded; switch(symbol) { case '0': encoded = 0b00111111; break; case '1': encoded - .... } buf[position] = encoded; } void add_comma(int position) { buf[position] |= 0x80; } предполагаю что точка в старшей позиции (и включается 1) Ну и в putc лучше сделать массив для перекодировки, а не switch

Позволяет. Любые приведения в рамках иерархии классов, за исключением приведения от виртуального базового (в случае множественного наследования) к потомку - тут нужен dynamic_cast<> Но это крайне редкий случай (мягко выражаясь) Все эти задания и условия обладают одной общей чертой - они работают напрямую с сырым представлением данных в памяти, и оперируют на уровне бинарных образов, а не на урвне абстракций С++. Именно для этого reinterpret_cast и оставили. Для работы с стандартными С++ абстракциями иго применять КРАЙНЕ не рекомендуется. И не столько потому, что это запутывает программу (как в случае goto), а потому что вы легко можете разрушить модель данных в которой работает С++ программа, и получить самые неожиданные эффекты. Если же вы применяете reinterpret_cast не для доступа к нижнему уровню, то нужно ОЧЕНЬ ХОРОШО понимать, что именно вы делаете и как это соотносится с тем, что ожидает компилятор. PS. Хороший пример такого применения reinterpret_cast - приведение плавающей точки к целому для работы с битовым представлением плавучки. С++ такого сервиса не представляет, более того, он вообще не специфицирует как представленна плавучка. Т.е. вы можете наделать совершенно любых чисел, которые могут вообще поставить в известное положение всю исполняющую систему С++. Согласен на все 100%. Осталось утрясти границы 'правильно' по отношению к reinterpret_cast<> Я бы сформулировал так - если вы не уверены, какой именно *_cast вам нужен, это точно НЕ reinterpret_cast<>. Применение reinterpret_cast - это всегда последний и единственный вариант.

Можно. Самое простое не декодировать числа (в 7 сегментов) при выводе, а складывать в буфер индикации декодиованное значение. Тогда точка будет зажигаться просто установкой соответствуещего бита в соотвествующем элементе буфера

Для того, что бы програмист при желании мог выстрелить себе в ногу 🙂 Вот для этого reinterpret_cast подходит, но это и есть тот самый хак 🙂 И явный признак того, что что то спроектированно не так - как внутренняя адресная информация оказалась на внешнем носителе? И что будет, если в процессе развития ПО этот адрес изменится, как его синхронизировать с внешней SPI? А если это адрес не внутри ПО, то почему он именно адрес, а не просто число? Ну и т.д.

А что тут показывать? snprintf + вывод из буфера в индикаторы (приблизительно как у вас, но только не по символам R1/R2/R... а из буфера, по индексу) Вот переделанный кусок вашего кода: unsigned char buf[4]; unsigned char n_count =0; ISR (TIMER1_COMPA_vect) { PORTB &= ~(1<<PORTB4); //низкий уровень segchar(buf[n_count]); while(!(SPSR & (1<<SPIF)));//подождем пока данные передадутся SPDR = (1 << n_count) ^ 0xF; while(!(SPSR & (1<<SPIF)));//подождем пока данные передадутся //сгенерируем отрицательный фронт для записи в STORAGE REGISTER PORTB |= (1<<PORTB4); //высокий уровень ++n_count; n_count &= 3; }