esaulenka

Потому что это дискредитация уникального аналоговнета. А там и до дискредитации честнейшего волеизявления недалеко. А он есть, этот разработчик? Бауманка - это не что-то единое целое, это довольно разветвлённая структура (с довольно громким именем, к тому же). Лет н-цать назад, когда я имел какое-то отношение к этому славному заведению, там были десятки всяких учреждений "Рога-Копыта-Инно-Тех при МГТУ им. Н.Э.Баумана". Вряд-ли ситуация сильно поменялась. Я тут погуглил - работа кипит! https://www.rbc.ru/politics/07/04/2022/624445459a79475dcc07347b (и совсем уж оффтоп) Спасибо за проведённый экзитполл среди пользователей электроникса. Не то чтоб неожиданно, но всё равно интересно.

"Заранее знать" - это хорошее умение. Обычно большинство ошибок от невнимательности. Например, при рефакторинге убрали аргумент у функции, а в каких-то вызовах убрать забыли. Компилируется без проблем, работает, скорее всего, тоже. Но ошибка. Но сам по себе этот факт - только докопаться на собеседовании. Или уровень аргументов типа "GCC - инородный" выяснить...

Это часть стандартной библиотеки: https://en.cppreference.com/w/c/types/NULL Сделайте include <stdlib.h> или include <stddef.h>

Это у K&R надо спрашивать, зачем оно такое придумывалось 🙂 Но вот такое должно нормально собираться: // myfile.h int myfunc(); // myfile.c int myfunc(int x) { return x + 3; } // main.c #include "myfile.h" ... myfunc("hello!", 123); Зачем оно сейчас, кроме как побольнее в ногу стрельнуть, я не знаю. Но вывод из этого всего простой - "параметр" void в сишном коде лучше не убирать.

https://en.cppreference.com/w/c/language/nullptr Но да, поддержку этой "новинки" можно ожидать в IAR AVR лет через н-цать.

В сях int my_func() означает "функция, которая принимает любые аргументы". Атавизм, но никуда не денешься... В плюсах, действительно, можно (и нужно) не писать. Уберите всю эту порнографию, пожалуйста. Есть же каноничный NULL (или nullptr). SPACE, если уж "о вкусах" разговор зашёл.

Заглянул в итоге в даташит на этот RTD2662. Там унутре какой-то потомок 51-го ядра. STM8 - собственная разработка ST, с интелом ничего общего не имеющая. Но походу дела это оно, да. И 8051 там - default target.

Общепринятый способ - написать issue. Точнее, поискать по уже созданным, и в случае необходимости - написать ещё. https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues Можно, конечно, в git log посмотреть емейл автора (со мной пару раз так связывались), но лучше писать в общедоступное место. В обсуждаемом мейкфайле два таргета - native (эмулятор (?), работающий на ПК) и firmware (собственно, прошивка для железки). У вас есть только cygwin-gcc, который умеет собирать только под win64. firmware должно собираться неким sdcc (я довольно далёк от контроллеров дисплеев, и без гугла не скажу, что это такое). Можете попробовать 'make firmware' чтобы получить ворох ошибок об отсутствии второго компилятора. UPD: А почему должно было помочь? Вот если бы вы запустили 'make program' или 'make all', можно было б увидеть разницу. А так - вообще ничего не поменялось. Ну и ещё раз. Почитайте описание Makefile. По сути своей, он очень простой (по крайней мере, пока всякие нехорошие товарищи не пытаются делать простым инструментом сложные вещи, превращая скрипт во что-то нечитаемое).

С вероятностью 99% - не это. Тот же автор в соседнем проекте использует https://github.com/KerJoe/RTDMultiProg/tree/master/interfaces/ch341 К слову, цифирки "341" втречаются только в мейкфайле. Т.е. есть некоторая вероятность, что оно там по ошибке (например, планировался функционал для связи ПК - девайс, но не сложилось). Я бы попробовал выкинуть, для начала. Но в любом случае. правильный подход - попросить автора добавить в исходный репозитарий саму библиотеку или хотя бы ссылку на неё вместо гаданий на гуще.

Для целей "научиться общаться с make'ом" рекомендую нагуглить какой-нибудь другой пример. Желательно чтоб там прямо в описании было написано, что это makefile examples, а не вот это вот "an unsuccessful attempt". Для целей "глубоко разобраться в отличиях POSIX и WinAPI" рекомендую гуглить в сторону "cannot find sys/ioctl.h on MinGW compiler". Но это трудный путь, я сам туда далеко не ходил.

Полистал user manual. Какой-то кривой этот BSL. С большой вероятностью, он подразумевает загрузку собственного загрузчика в RAM и работу уже через него. CAN BSL вообще только так и работает. Попробуйте, действительно, ULink. Возможно, стоит искать оригинал - у меня 100% уверенность, что китайцы свои клоны на совместимость с 8051 не проверяли. Мне кажется, с рук приобрести будет несложно - для современных чипов проще JLink (или его клон) использовать. На моей позапрошлой работе он в шкафу валялся, никому не нужный. Ну и сделайте НОРМАЛЬНЫЕ фото платы. По имеющимся, например, отследить подключение ног TMS / MBC - глаза сломаешь. И вообще - что вы там хотите увидеть? Угол / скорость вы уже нашли. Контрольную сумму, наверное, можно и так подобрать. Команду установки нуля можно добыть из программы диагностики (https://gitlab.com/py_ren/pyren). А кофе варить эта штука всё равно не научится...

Можно придумать, как по-феншую сделать трюк типа `upd_bit(MY_REG).set(SET_MSK).clr(CLR.MSK)`. А ваша задача в исходном звучании не решается, имхо. Надо эти set() / clr() в общую область видимости выносить. Можете обернуть всё это в `namespace HwRegsWrapper { ... };` и в своих драйверах дописать `using namespace HwRegWrapper;`, тогда в остальных местах эти имена не будут мешаться.

Оу. А где можно ознакомиться с этими исследованиями? Или они ещё более секретные, чем это дополнительное ядро?

Мне кажется, этот форум - не лучшее место, чтобы публично заявлять "я не читаю документацию". Это стандартное поведение алгоритма запуска, называется "программная нейтраль". В большинстве моделей автовключение программной нейтрали (при поднятии ручника, подозреваю) можно отключить в настройках.

Мы тут с @Toxa555 чуть-чуть продвинулись с этим вопросом. Как минимум, читать он этот процессор умеет. Следующий вопрос - писать. Так вот, коллеги, у кого-нибудь есть опыт добавления нового процессора в J-Flash ? В их вики всё подробно написано - надо написать XML-ку с описанием процессора (это называется Device Support Kit) и скомпилировать ram-loader (это называется Segger Flash Loader). Загвоздка в том, что в стандартном комплекте никаких примеров нет, и для получения этого саппорт кит они предлагают написать в поддержку. Я нашёл, правда, какие-то loader'ы в комплекте segger SDK (когда-то старая версия пробегала здесь на форуме). Но xml-ок всё равно нету...

Вам не нужен "идентичный самсунг". Надо применить голову и из этого списка https://www.segger.com/supported-devices/search/samsung найти процессор с внутренней флешкой (в понимании сеггера. Прочерк в таблице означает внешнюю флешку), ядром ARM7 и одинаковыми адресами регистров контроллера флеш (IFC_xxx в терминах даташита). Э-э... где я это пропустил? Я не очень внимательно читал. В частности, мне лень там регистрироваться, и картинки мне не показывают. Но я не могу сказать, что действия автора правильные. В частности, он зачем-то пытался засунуть штатный бутлоадер как ram-code прошивальщика. Они оба, конечно, программы для процессора, даже называются одинаково "loader", но больше никаких схожих частей не имеют. Ну и привычка излагать непонятные вещи своими словами, в процессе преиначивая половину, тоже не сильно способствует пониманию... Да, у вас есть дамп от максимально похожего блока? Я бы посмотрел...

и что поменялось? 'error determining flash info' явно не будет ввиду отсутсвия такового запроса. Что "то же самое" ? "просто arm7" ничего никуда записать не может. И я не говорил "arm7", я говорил "samsung", это принципиально важно. Попробую чуть-чуть навести порядок в вашей голове. Читать из флеш просто - выставляем нужный адрес, забираем данные. Точно так же работает чтение и запись в ОЗУ. А вот для записи во флеш нужны определённые магические действия: прошивальщик записью в определённые регистры должен запустить стирание, потом подождать (проверяя готовность чтением регистра статуса), потом инициировать запись, скопировать кусок данных, и снова подождать (опять с проверкой готовности). Стандартный подход - создание небольшой программы специально для этого, которую прошивальщик заливает в ОЗУ контроллера, и дальше только "кормит" её данными. Последовательность этих "магических действий" у каждого производителя своя (часто и между моделями есть отличия). Ну попробуйте J-Mem ещё. Простейшая утилита, которая умеет только читать память, зато - любую, какую попросить. Можете ей посмотреть содержимое ОЗУ или периферийных регистров, например. А вообще говоря, правильно начинать с документации. Я вот полистал даташит и убедился, что флеш и ОЗУ включены всегда (эх, здравствуй 2006 год, камень примитивный совсем..). Т.е. оно ДОЛЖНО отдавать какие-то данные.

Ох... Ну зачем же _фото_ ?! Есть прекрасная кнопка PrintScreen (или, на win10, ещё более прекрасная Win-Shift-S). Быстро, удобно, и гораздо более читаемо. Подозрения подтверждаются - в Сеггере считают, что память там внешняя. Походу, они что-то напутали в самсунговской номенклатуре. Варианты действий: - попробовать снять галку "Automatically detect flash memory". Записать ничего не получится, но, возможно, даст прочитать. - попробовать выбрать другие процессоры в настройках. Попутно очень желательно сравнивать даташиты, чтоб там алгоритм записи (и соотв. регистры) соответствовали вашему процессору. Возможно, какой-то другой самсунг подойдёт. - вдумчиво покурить сеггеровские доки и написать загрузчик самостоятельно. Я так не делал, но вроде б это не запредельно сложно. - если вы платили Сеггеру деньги (ну, вдруг?), самое время написать в техподдержку 🙂 PS ссылка на даташит, если кому-то ещё будет интересно: https://www.datasheetarchive.com/datasheet?id=2342587efb1d49c7ec3feaee40e48b07fad5d9&type=P&term=s3f4a0k

Наоборот. Reserved и DataFlash по умолчанию недоступны. Хм. 32k RAM + 1M Flash. Странная пропорция, но автопроизводителям виднее, не зря ж они такой проц выпустили... У меня два предположения: - если у вас по-прежнему вот такая картинка, то, возможно, вам нужно поискать, кто мешает отладчику - кажется, судя по слову CFI, J-Flash пытается искать внешнюю флешку. Либо это следствие "универсальности" джейфлеша, либо Сеггер ошиблись с моделью процессора и по факту он не поддерживается. У меня сейчас под рукой джей-флеша нет, как там настройки для этого проца выглядят?

Уже хорошо. У меня почему-то подозрение, что вы пытаетесь читать внешнюю флешку. Давайте подробности - что у вас на плате (проц + внешняя SDRAM ?), как сконфигурирован J-Flash, какие конкретно ошибки при чтении? Я вижу, что отключена только data flash. Остальное, если верить даташиту, должно быть доступно.

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

А у меня два монитора и несколько проектов, в каждом из которых по полсотни исходных файлов. Вы уж определитесь - у вас всё хорошо, или "куча варнингов, проблемы, я не понимаю". "приравнивается к единице" записывается как "var = 1;", а тут, с высокой вероятностью, написана ерунда. В вашем коде ДВА вызова eeprom_write_block. Найдите оба и сравните адреса, которые вы туда передаёте. Сравнить два массива. Ну ок. Вы даже читать не пытаетесь. Вопросов больше не имею.

Потому что заголовочный файл может include'иться в несколько .c файлов одновременно. Ваш подход приведёт к образованию нескольких копий переменных, и благоприятный исход всего этого - линкер при компиляции выдаст ошибку (неблагоприятный - накомпилирует чёрт знает что). Размер массива в байтах, в документации вполне явно написано. Ну и это не с++, компилятор не сможет узнать размер одного элемента. У вас, кстати, с этими eeprom read/write ещё одна ошибка. Надо указывать адреса так, чтобы они не перекрывались. Сейчас massive_open состоит из одного байта, принятого при открытии и "хвоста" из massive_close. Ещё одно "темное" место: if (button_open) { flag_button_open; } ... if (flag_button_open) { ... Что такое flag_button_open ? если это переменная типа bool, то что происходит в начале? И ещё. Что за магия с memccpy ? Вы точно хотите использовать это вместо обычного memcpy ?

Несколько замечаний. Сам алгоритм не пытался понять, чисто визуально. 1) вы не приложили main.h, в котором, подозреваю, определены переменные. В заголовочных файлах в 99% случаев нужно делать только объявления (declaration) с префиксом extern, а не определения (definition). Ваш подход приведёт к "непонятным" проблемам, если проект разрастётся до нескольких .c файлов. 2) в обработчике прерывания таймера вы записываете значения (не очень понятно, какие, ну да ладно) в массив без проверки значения 'i'. Это может закончится порчей памяти и очень странными ошибками. 3) eeprom_read_block, eeprom_write_block, memcmp в качестве последнего аргумента используют размер в байтах. 'unsigned int massive[10]' в случае AVR имеет размер 20 байт.

либо, как вариант, https://www.segger.com/supported-devices/infineon/fm3