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

esaulenka

Свой
  • Постов

    1 444
  • Зарегистрирован

  • Посещение

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

    1

esaulenka стал победителем дня 14 февраля

esaulenka имел наиболее популярный контент!

Репутация

5 Обычный

2 Подписчика

Информация о esaulenka

  • Звание
    Профессионал
    Профессионал
  • День рождения 25.01.1983

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

8 531 просмотр профиля
  1. "Заранее знать" - это хорошее умение. Обычно большинство ошибок от невнимательности. Например, при рефакторинге убрали аргумент у функции, а в каких-то вызовах убрать забыли. Компилируется без проблем, работает, скорее всего, тоже. Но ошибка. Но сам по себе этот факт - только докопаться на собеседовании. Или уровень аргументов типа "GCC - инородный" выяснить...
  2. Это часть стандартной библиотеки: https://en.cppreference.com/w/c/types/NULL Сделайте include <stdlib.h> или include <stddef.h>
  3. Это у K&R надо спрашивать, зачем оно такое придумывалось 🙂 Но вот такое должно нормально собираться: // myfile.h int myfunc(); // myfile.c int myfunc(int x) { return x + 3; } // main.c #include "myfile.h" ... myfunc("hello!", 123); Зачем оно сейчас, кроме как побольнее в ногу стрельнуть, я не знаю. Но вывод из этого всего простой - "параметр" void в сишном коде лучше не убирать.
  4. https://en.cppreference.com/w/c/language/nullptr Но да, поддержку этой "новинки" можно ожидать в IAR AVR лет через н-цать.
  5. В сях int my_func() означает "функция, которая принимает любые аргументы". Атавизм, но никуда не денешься... В плюсах, действительно, можно (и нужно) не писать. Уберите всю эту порнографию, пожалуйста. Есть же каноничный NULL (или nullptr). SPACE, если уж "о вкусах" разговор зашёл.
  6. Заглянул в итоге в даташит на этот RTD2662. Там унутре какой-то потомок 51-го ядра. STM8 - собственная разработка ST, с интелом ничего общего не имеющая. Но походу дела это оно, да. И 8051 там - default target.
  7. Общепринятый способ - написать 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. По сути своей, он очень простой (по крайней мере, пока всякие нехорошие товарищи не пытаются делать простым инструментом сложные вещи, превращая скрипт во что-то нечитаемое).
  8. С вероятностью 99% - не это. Тот же автор в соседнем проекте использует https://github.com/KerJoe/RTDMultiProg/tree/master/interfaces/ch341 К слову, цифирки "341" втречаются только в мейкфайле. Т.е. есть некоторая вероятность, что оно там по ошибке (например, планировался функционал для связи ПК - девайс, но не сложилось). Я бы попробовал выкинуть, для начала. Но в любом случае. правильный подход - попросить автора добавить в исходный репозитарий саму библиотеку или хотя бы ссылку на неё вместо гаданий на гуще.
  9. Для целей "научиться общаться с make'ом" рекомендую нагуглить какой-нибудь другой пример. Желательно чтоб там прямо в описании было написано, что это makefile examples, а не вот это вот "an unsuccessful attempt". Для целей "глубоко разобраться в отличиях POSIX и WinAPI" рекомендую гуглить в сторону "cannot find sys/ioctl.h on MinGW compiler". Но это трудный путь, я сам туда далеко не ходил.
  10. Полистал user manual. Какой-то кривой этот BSL. С большой вероятностью, он подразумевает загрузку собственного загрузчика в RAM и работу уже через него. CAN BSL вообще только так и работает. Попробуйте, действительно, ULink. Возможно, стоит искать оригинал - у меня 100% уверенность, что китайцы свои клоны на совместимость с 8051 не проверяли. Мне кажется, с рук приобрести будет несложно - для современных чипов проще JLink (или его клон) использовать. На моей позапрошлой работе он в шкафу валялся, никому не нужный. Ну и сделайте НОРМАЛЬНЫЕ фото платы. По имеющимся, например, отследить подключение ног TMS / MBC - глаза сломаешь. И вообще - что вы там хотите увидеть? Угол / скорость вы уже нашли. Контрольную сумму, наверное, можно и так подобрать. Команду установки нуля можно добыть из программы диагностики (https://gitlab.com/py_ren/pyren). А кофе варить эта штука всё равно не научится...
  11. Можно придумать, как по-феншую сделать трюк типа `upd_bit(MY_REG).set(SET_MSK).clr(CLR.MSK)`. А ваша задача в исходном звучании не решается, имхо. Надо эти set() / clr() в общую область видимости выносить. Можете обернуть всё это в `namespace HwRegsWrapper { ... };` и в своих драйверах дописать `using namespace HwRegWrapper;`, тогда в остальных местах эти имена не будут мешаться.
  12. Оу. А где можно ознакомиться с этими исследованиями? Или они ещё более секретные, чем это дополнительное ядро?
  13. Мне кажется, этот форум - не лучшее место, чтобы публично заявлять "я не читаю документацию". Это стандартное поведение алгоритма запуска, называется "программная нейтраль". В большинстве моделей автовключение программной нейтрали (при поднятии ручника, подозреваю) можно отключить в настройках.
  14. Мы тут с @Toxa555 чуть-чуть продвинулись с этим вопросом. Как минимум, читать он этот процессор умеет. Следующий вопрос - писать. Так вот, коллеги, у кого-нибудь есть опыт добавления нового процессора в J-Flash ? В их вики всё подробно написано - надо написать XML-ку с описанием процессора (это называется Device Support Kit) и скомпилировать ram-loader (это называется Segger Flash Loader). Загвоздка в том, что в стандартном комплекте никаких примеров нет, и для получения этого саппорт кит они предлагают написать в поддержку. Я нашёл, правда, какие-то loader'ы в комплекте segger SDK (когда-то старая версия пробегала здесь на форуме). Но xml-ок всё равно нету...
  15. Вам не нужен "идентичный самсунг". Надо применить голову и из этого списка https://www.segger.com/supported-devices/search/samsung найти процессор с внутренней флешкой (в понимании сеггера. Прочерк в таблице означает внешнюю флешку), ядром ARM7 и одинаковыми адресами регистров контроллера флеш (IFC_xxx в терминах даташита). Э-э... где я это пропустил? Я не очень внимательно читал. В частности, мне лень там регистрироваться, и картинки мне не показывают. Но я не могу сказать, что действия автора правильные. В частности, он зачем-то пытался засунуть штатный бутлоадер как ram-code прошивальщика. Они оба, конечно, программы для процессора, даже называются одинаково "loader", но больше никаких схожих частей не имеют. Ну и привычка излагать непонятные вещи своими словами, в процессе преиначивая половину, тоже не сильно способствует пониманию... Да, у вас есть дамп от максимально похожего блока? Я бы посмотрел...
×
×
  • Создать...