Комментарии 60
Проще установить unix подобную систему и писать программы на С под неё. (Моё мнение))
В Linux я не находил нормальной утилиты для сравнения текстовых файлов, которая по удобству хотя бы близко могла приблизится к WinMerge.exe.
meld?
vimdiff?
В Linux у вас уже будет "нативный" gcc.
Вы можете поставить любую IDE - хоть VSCode, хоть CodeBlocks, хоть CodeLite (тут, кстати, вам не придется писать make файлы - оно само это будет за вас делать - просто создаете и конфигурируете проект - достаточно компактная и удобная среда для небольших проектов, под винду, кстати, тоже есть).
И аналог WinMerge тут, как правильно заметили, есть - Meld.
В качестве файлового менеджера - привычный по винде DoubleCommander.
kdiff3?
А почему не использовать CMake?
Make как-то ближе к физике процесса.
После микроконтроллеров осталась привычка к Low Level.
Что вы подразумеваете под low level в системах сборки? Low level код это понятно.
CMake при определенной настройке генерит make скрипты.
CMake это по сути надстройка над make.
Вот и получается что make - low level; CMake - hi level.
Вы фантазируете. Cmake это не надстройка на make. Make это лишь из один возможных форматов выхлопа. Make не используется самим Cmake, это опция. Это как сказать что велосипед это бэкэнд велозавода.
cmake на основе собственных описаний (CmakeList.txt) генерирует целевой проектный файл. Может по заказу сгенерировать GNU Makefile или Microsoft NMake Makefile. Может Visual Studio Solution или Apple Xcode projects... Далее полученый проект обрабатывается соостветствующим билдером. В случае GNU Makefile будет нужен GNU make. Make не используется самим cmake, но для дальнейшей сборки с использованием Makefile он необходим. Получается в пайплайне сборки cmake является конвейерной надстройкой над make.
Это бэкэнд велосипедиста... то есть юзверя
Make дает больший контроль над ситуацией.
Make - это как механическая коробка передач, a CMake - автомат.
А был еще и nmake
del
Не очень понял смысл статьи. Это литературный эксперимент?
Ведь обучение Си обычно и начинается с того, что начинающий программист сначала пишет свои первые программы в простой "песочнице" PC, где ни о каких ограничениях платформы можно не думать. И когда он наберёт опыта работы с МК - он тем более будет знать простые вещи типа "как скомпилировать свой код". В итоге статья читается как высоконаучное описание "как ковырять в носу для чайников, на примере поз из йоги, базовая теория и основные подходы" :)
В статье звучал и другой мотив - перенос кода с МК на ПК. Вот про это я бы почитал с удовольствием. Ведь там так много проблем - имитация неидеальности поступления данных от периферии, ERRATA контроллера, отличающиеся типы данных, точность и скорость операций...
Знаю случай, когда на МК и на ПК на том же коде отличались некоторые результаты операций деления. С имитацией этого народ знатно помучился.
Забавно, я на Си первые программы как раз для микроконтроллеров писал, потому что на работе решили МК заняться. Для програмирования на компе у меня дельфи был.
Счас мне правда статья уже бесполезна, т.к. mingw-w64 уже себе настроил.
Ну это прям максимально странно, если честно. Потому что изучать си на МК, это то ещё занятие...
Ничего странного.
Cи как язык программирования кроме микроконтроллеров больше никому, по большому счету, и не нужен!
Более того всё чаще и чаще для программирования MCUшек применяют уже С++ .
Безотносительно нужности его на ПК (о чем тоже можно поспорить на самом деле) программирование под МК имеет кучу особенностей. И чтобы собрать хоть как-то рабочий код (который не будет черным ящиком как Ардуино, а действительно обучающим примером) надо неплохо так поразбираться во внутрянке (один header файл регистров будет тем ещё приключением). Это банально не самый удобный инструмент просто. Поэтому и учить на МК странно.
МК используют не Си а его подмножество\дилекты. Зачастую с правилами отличными от стандартного Си ради приближения к МК
Надо было запилить проект на МК. Опытный советчик сказал - ну вам год надо архитектуру арм сначала изучать, но мы его не послушали. На чем его можно программировать - на ассемблере и на си. Ассемблер изучать долго, а нам надо проект делать. Значит си. Я про него что-то слышал в детстве, о вот и книжка Кернигана нашлась, почитал и погнали. Больше всего проблем было с тем чтобы Ethernet поднять (на отладочной плате и соответственно работающем примере был один чип phy, а на той что мы запилили - другой), а си - ну язык как язык, что-то похуже чем в дельфи что-то получше.
Для запуска TCP IP на микроконтроллере надо подключить код, который называется LwIP.
это да. Правда в тот раз я uIP использовал (более легковесная версия от того же автора). Проблема была с более низким уровнем - инициализацией PHY. Там надо подключиться к чипу и установить mac адрес для фильтрации пакетов, ну и у этих чипов слегка различался протокол.
Проблема была с более низким уровнем - инициализацией PHY.
Написать драйвер для MDIO чипа это хорошо формализованная задача.
Вот даже методичка есть.
https://habr.com/ru/articles/683762/
я на си то второй раз в жизни писал, какие еще драйвера. Был рабочий пример, причем казалось что он и на этом чипе работал (просто задание мак адреса втихую не работало и он оставался дефолтный). Проблемы начинались когда два девайса в одну сеть подключали. Решилось парой дефайнов (PHY_ADDRESS и что-то там еще, дело было лет 15 назад).
1--Tiny C Compiler не может собрать эту функцию
2--TCC не видит #include <complex.h>
3--TCC ругается на определение типа внутри for
for(uint8_t bit = 0U; bit <= 7U; bit++) {
}4-- TCC не знает макроса
__TIMESTAMP__5-- tcc: undefined symbol 'strlen' 'snprintf' 'fprintf' 'strdup' 'memcpy' 'free' 'calloc' 'write' 'memset' 'malloc' '__imp__iob' 'exit' 'tolower' 'strchr' '__mb_cur_max' '_pctype' '_isctype' 'srand' 'rand' 'qsort' 'strcpy' 'printf' 'strcasecmp' 'fabs' 'strncpy' 'sprintf' 'kbhit' '_getch' 'strcmp' 'fopen' 'fclose' 'abs' 'system' '_GetStdHandle@4' '_GetConsoleMode@8' '_SetConsoleMode@8' 'time' 'pow' 'sin' 'cos' 'sqrt' 'atan2' 'fmodf' 'fmod' 'acos' 'atan' 'strstr' '__fpclassifyf' 'memmove' 'strspn' 'strcspn' 'toupper' 'fgets' 'localtime' 'mktime' 'difftime' 'ftime' 'asctime' 'clock' 'gmtime' 'getc' 'fseek' 'ftell' 'fread' 'strncmp' 'memcmp' 'sscanf' '__imp__HUGE' 'putchar' 'puts' 'fabsf' 'fmaxf' 'fmax' '_controlfp' '__set_app_type' '__getmainargs'
Что-то компилятор TCC не может собрать даже math.h
C:/tcc/include/math.h:217: error: unknown constraint 't'
не используйте static при определение параметров: static void s20_rowround(int y[16]);
да complex.h у него нет. но это не мешает проводить любые вычисления.
у меня не ругается
да такого макроса у него нет. (вам никто не мешает его определить в параметрах при компиляции)
такое тоже не воспоизводится
да там хедеры от gcc. Если вы будете испольтовать fabs то всё работает. Но если всё же хочется fabsf, fabsl и т.п. поменяйте в хедере "=t" на "=r" и оно заработает.
st
По-моему Visual Studio имеет community edition и в ней можно писать в том числе и на C.
А почему нельзя взять Codeblocks, где все это работает из коробки, причем под Linux выглядит точно так же?
Хороший вопрос!
Codeblocks - это IDE.
Отсюда все проблемы связанные с IDE.
Прежде всего это бесконечное дублирование конфигов для разных сборок в IDEшной xml.
Подробнее про это тут
https://habr.com/ru/articles/723054/
Нормальный IDE это возможность нормального дебаггирования. Неужели ради этого не стоит сконфигурировать GUI?
Пошаговую отладку кода можно и из консоли делать.
Вот методичка для микроконтроллерных прошивок https://habr.com/ru/articles/694708/
Для PC консольный GDB еще проще.
Если код покрыть модульными тестами, то в пошаговой отладке нужда как таковая отпадает сама собой.
Да-да, все так и есть, только модульные тесты спасут от необходимости интеграционного тестирования!
А тесты вы как будете отлаживать?
А Вы чем собираете?
Все нормальные люди собирают при помощи Qbs
Я в make'ах так до сих пор и не разобрался толком. Набираю вручную в терминале команды компилятора с нужными флагами. Для личных нужд пойдёт.
Вот хорошая и понятная методичка по Make
http://citforum.ru/operating_systems/gnumake/
Плюс Make в том, что за 60 лет своего существования это теперь самая разобранная и надежная технология из всего Computer Science.
Как собрать Си программу в OS Windows