Не, вин 98 пусть уже отдыхает в мире ином, ибо кроме прямого доступа к железу от нее толку 0, ибо висла она и глючила не по детски...

По поводу писанины под питоном - это еще ерунда, посмотрите все типы извращения, которые предлагают фанатики под вин 10идиотiot В ходу виртуальные светодиоды из облачных пулов устройств...

Уверен, что точно также хихикали программеры в машинных кодах/асм над С-программерами Времена не меняются
Но время расставило все на свои места - кто из них не успел запрыгнуть в "поезд прогресса", тот и остался в забвении в прошлом на своих архаичных железках.
В свое время программеры под голой VS хихикали над сырыми .NET 1.0 и JAVA ... Где теперь те "программеры" ? ...
Кто из них до сих пор хихикает, либо уже спились, либо сидят в гос-конторах, поскольку всем остальным они уже бесполезны

Эти ваши си-диезы, го и прочий шлак до сих пор так шлаком и остался! Ни один вменяемый человек не будет что-нибудь серьезное на этом писать! А уж ядро ОС только на С и пишется: как 30 лет назад, так и сейчас, и в ближайшие 30 лет!
Для С++ место только в узкой нише GUI'шного софта и высокоуровневых библиотек, где его плюшки имеют смысл.
Всякие пхытоны-перлы так и остались фигней для развлечения.
А ассемблер до сих пор используется — но уже как вставки. Писать на чистом ассемблере нецелесообразно из-за его низкоуровневщины, С же — очень высокоуровневый язык, и его за глаза на все случаи жизни хватает.

Почему?
Кто мешает использовать два компа - один для выкачивания документации, связи с другими разработчиками, второй - на нём софт и разработка.


Последнюю даже пробовал устанавливать и работать.
Проникся уважением (к ОС и её разработчикам).
Была даже идея портировать под KOS свои наработки в виде эмуляторов (сейчас там только NES и GB©), но пока в приоритете - создание своей игровой платформы.


Техподдержка - это для дятлов.
Потому что :
- внятного от неё ничего не услышишь
- всегда удается разрулить проблему самостоятельно, не дожидаясь запаздалого ответа от ТП
- те кто обращается в ТП, практически все дятлы
- ну и в ТП как правило сидят одни ТП )))

На счёт сложности тоже спорный вопрос.
Вот что реально сложного на моей практике выпало - это программирование VGA-регистров видеокарты для установки HiRes разрешений с большой цветностью BPP с нестандартными длиной и шириной кадра с логической шириной кадра отличающейся от физической, с изменением частоты обновления экрана от 80 Гц и выше(до 130 Гц).
Гемор ещё тот: программирование более 50 регистров видеокарты.
Вот это я понимаю - сложно.

А дёргнуть флаги разрешения клоков на тот же SPI, установка частоты ядра-памяти , установка кеширования данных через MMU с прямой трансляцией адресов - это пустяк по сравнению с задачей выше.

Ну и разве что в кирпич можно превратить контроллер, если порт настроить на вывод и замкнуть его на питание или землю, думая что порт на вводе (кнопка).
Ну или FUSE сорвать для кварца или SPI-программатора. Но это лечится.


Для конечных пользователей - готовые устройства: просим любить и пользоваться.
Отладочные платы - для разработчиков, господа в белых воротничках, извольте открыть доки и описать в SDK как программируется весь набор периферии.

А то получается: ключевые сотрудники в Китае на гитхабе постят дистры Линукса, описывая в группе Гугл о том что SDK они дать не могут, а дистр Линкса - запросто.
Тоесть всё через задницу: хотите SDK - выколупывайте его в Линуксе! А отдельно мы вам его не дадим!
Ну и делать нечего, стал разбираться и понял, что в Линуксе всё спрятано в папках по функциональному назначению:
- видео
- аудио
- порты
- остальные подистемы....
- и там куча сорцов на железки разных производителей, включая то что нужно.
Но разобраться, пропустить через себя и осознать это - нужно времени намного больше, чем время на освоение и осмысление отдельного SDK.

Ну и в интернете под Линукс много чего интересного есть - вплоть до дисассемблированного загрузчика, по тексту которого можно понять:
- куда указывает стек
- в какой адрес памяти кладётся программа boot0 (spl)
- какая периферия задействуется
- в каком режиме процессор (супервизор или юзер)
- какие байты в хедере загрузчика важны (сигнатура, контрольная сумма, размер)
- и многое другое ЧТО ПРОСТО ОБЯЗАНО БЫТЬ В ДАТАШИТЕ (в Technical Reference)


как мне тут сказал один знакомый по этому поводу: "... гнойник рано или поздно лопнет ..."


Это 95-я глючила, 98-я только вешалась намертво, если что-то забыть важное сделать.

Зато в 98-й винде возможно перейти из DOS-программы в нулевое кольцо по такой схеме: DOS => DOS + DPMI => Ring 0.
Было удивительно написать такую вещь как while(inp(0x60)!=1){}; и созерцать глобальную заморозку всех задач и ядра винды, пока не будет нажата клавиша Esc
Ну или рисовать точки не в окне приложения, а с самого верхнего левого угла экрана монитора
И это всё через Low Level в ДОС-программе, а не через GDI или Direct Draw !

Не переживайте вы так, учиться никогда не поздно
Сложно другое - начать (сужу по себе)


Ну-ну ... видать все только и делают, что пишут ядра ОС. Ведь больше-то заняться нечем

Хихикали или нет - не важно. Есть какой-то уровень, до которого нужно дойти, и быть на нем до тех пор, пока не дойдем до чего-то по-настоящему нового и адекватного, на сегодня - это уровень Си, наиболее универсального средства программирования. "Особо одаренные" могут изобретать что угодно, но большинство адекватных продолжает им пользоваться...
JAVA тоже имеет место быть, но только в случае разноплатформенного использования. Для всяких дотнетов тут места нет от слова вообще...

Так я не являюсь сторонником Си Диеза и прочих вещей в нише микроконтроллеров. Они совершенно для других вещей предназначены.
А их внедрение популяризуется из-за большого процента "админов" в IT-шной массе. А они как правило, больше скриптовыми языками владеют, на то и расчёт чтоб с них срубить бабки.

По части программирования ядер ОС на Си... Много ли Си-компилеров, способные дать чистый бинарник с любого ORG и без затирания регистров?
На счёт GCC не уверен, а вот про Open Watcom C слыхал, что можно сделать бинарник без привязки к ОС и clib.

Ну и планировщик задач (Tasker) пишится всёравно на Ассемблере, так как нужно очень чисто пушить и попить контекст задач.
Ковырял исходники ucos под ARM7 видел как это всё сделано.

Писателям игрушек для веба это сложно понять, но тут вопрос о программировании на МК.

Всему своё время и место.
Можете называть меня ОЛД-фагом, но я не чураюсь машинных кодов, например в ассемблерных вставках: часто бывает что встроенный ассемблер в Си каких-то инструкций не поддерживает, а оформлять дополнительный сорец с ассемблером лень, машинные коды выручают

На счёт JAVA раз заговорили, упомяну как сделаны Ведроиды: на ARM процессор ставится виртуальная машина ARM + JAVA : => получается двойная эмуляция!
Зачем?
Учитывая, что есть специальные ARM-ы, с аппаратной поддержкой JAVA (Jazelle вроде бы?). Налицо - говнокодостроение.

JAVA может быть полезна временно, когда нет порта какого-то приложения на целевой платформе, ну или в случае закрытого кода приложения.
В остальных случаях - JAVA - тормоз.

Для "веба" не пишу, но прекрасно их понимаю, и не имею ничего против развития и прогресса.
Если речь про программирование применительно к "бытовым" МК, т.е. под конкретное узкоспециализированное железо, то пока что дальше C/C++ нет смысла соваться. Где возможно, я предпочитаю С++.
В более серьезных железках как минимум неразумно лишь одним "молотком и ножовкой" делать все, начиная от портирования ОС, заканчивая сложными клиентскими приложениями.
Ведь никому адекватному никогда не придёт в голову идея писать приложения для смартфона целиком на asm/С.

С другой стороны, существует известная поговорка "каждый дро%%т как хочет"

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

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


Угу, и получить эдак 10 томов по 500 страниц каждый. Да они минимум год только писать это будут, а потом каждый месяц выпускать по дополнительному тому "исправлений и дополнений"

Тестовая среда и всяческие эмуляторы куда быстрее, приятнее и нагляднее пишутся на каком-нибудь протопыхе (perl) или гвидопыхе (python). Да и куча полезного софта управляется с помощью Tcl. Модели опять же на гвидопыхе с numpy пишутся куда быстрее, чем на C или крестах. Есть, конечно, MATLAB, но он стоит сотни нефти, но есть и альтернативы - SciLab, Octave, Axiom и Sagemath (которая чуть более, чем полностью - Pyhton).

Ну и во всём этом есть одна загвоздка - как правило, те, кто знают Python, perl, Java, знают так же и C. При этом странно, что те, кто знает только C так кичатся своим неприятием других инструментов.

Ну а ТП, там же не телепаты сидят - ей-то откуда знать что вы натворили с чипом и какие могут быть последствия?
Ну и как можно спалить чип неверной записью в регистры? (про порты ввода/вывода, фьюзы и ПЛИСы - не рассказывать!)


Так из этих 500 страниц каждому понадобятся свои 50 страниц!
Например, для моих применений - видеокодек не нужен, так же как и USB и Эзернет.
Мне надо GPIO, SPI, TF, Video Out, высокая производительность ядра over 1GHz - остальное не важно!
Другим наоборот.
Но никто не заставляет читать все 500 страниц!


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

Нет. Это мнение не моё, а весьма большого количества людей. Которые, кстати, не судят всех программистов на Си по осилившим только хэллоуворлд, ну или мигание светодиодом, в случае микроконтроллеров. Понятно, что порог входа в пыхоплеяду ниже, чем в Java/C, поэтому, в абсолютном значении monkey-coder'ов среди них, конечно, больше. Но не в процентном.

Хе-хе, попробуйте запустить простейший STM32 прочитав 50 страниц. А в больших чипах взаимосвязей и зависимостей на порядки больше.

Легко! Пишете неправильное значение в регистр управления питанием и один из ip блоков в чипе подпаливается.
Похоже вы сложных чипов еще не видели.

Ой, да. Забыл добавить сюда управление напряжением питания ядра через ШИМ. Типа как в Блекфинах.

Ну это ж детский сад, если по этому поводу писать в ТП

Можно мои 5 коп добавить? Спасибо (;
Не буду про фьюзы…
Ошибочно отключенный (неверной записью в регистры) JTAG - это всё равно что спаленный чип (;

Если JTAG отключается лишь через прошивку (софтварно), то дело поправимое - нужно лишь подключить к отладчику цепь сброса МК.
А вот если чип залочен необратимо (у STM32 такое возможно), то чип - на помойку.

ЕМНИП отладку у STM32F4xx можно делать через SWD + STM32 ST-LINK Utility

Дык SWD на выводы JTAGа выведен

Тему в "Средства проектирования" надо по-хорошему

Я и под веб нет-нет, да делю что-то (веб-морды для меня более предпочтительны, нежели содомия со standalone GUI), вот там, к сожалению, одним только С не обойтись, приходится еще жабоскрипт использовать и на html разметку делать, но это фигня — один раз помучился, и готово!
Микроконтроллеры — понятное дело, там только чистый С. Я, помучившись с SPL и opencm3 на STM32, понял, что ну его нафиг — эти чужие кривые библиотеки, надо на сниппеты ориентироваться и не долбить себе мозг всякой чушью.
Приложения для связи между компьютером и МК — на чистом С. На нем же клиент-серверные вещи (демоны, логгеры, интерфейсы и т.д., и т.п.).

В общем, С свою актуальность не потеряет еще долго.


Ни разу не встречал тех, кто прекрасно знает одновременно пхытон, перл, жабку и С! Это ж вообще вещи разных классов! Надо быть одновременно и гуманитарием, и технарем, чтобы умудриться все это выучить, а самое главное — понимать!!!


Для мигания светодиодом без таймера нужно будет даже меньше прочесть ☺
Все равно, даже если пользоваться чужими библиотеками, надо будет читать даташит по используемой периферии. Но в случае библиотек, нужно еще скудную документацию к ним читать + ковыряться постоянно в исходниках этих библиотек (мало ли что там индусы наговнокодили — встречал я такие приколы)! Так какой смысл тащить лишнее? Лучше самому постепенно накапливать базу сниппетов, а затем по мере необходимости брать уже готовые куски кода.

Зачем мне простейший, когда совсем недавно портировал кодек MELP800 на STM32F405 ?
Bare Metal, конечно.

Что за ерунда? Я, например, вообще не использую ни JTAG, ни SWD — все STM32 шью через бутлоадер. Это намного удобней, да и не нужно лишних устройств присобачивать; а висящий на UART1 переходник после прошивки используется для отладки.

Вот такую базу у меня есть желание создать под один из современных ARM-ов, типа базового API для работы с нужными узлами.
Нечто похожее сделал для ADSP BlackFin BF532/533 и для STM32F405 и для AT91RM9200 - с кешами, с MMU, на полной скорости.

Это как? Неужто его можно залочить так, что даже бутлоадер не примет перезапись флеша? А если стереть бутлоадер, остается еще возможность стереть через SWD/JTAG при должной сноровке (жамкаем reset, а отпуская жмем enter в командной строке, где уже вбили команду стирания флеша).


Под STM32F0, кстати, есть уже готовые сниппеты от самих ST. Жаль, что под другие линейки они не потрудились подобное накатать.
С STM8 я сразу начал работать в стиле "пошли все нафиг, я даже заголовочный файл с дефайнами портов сам напишу", накапливая сниппетобазу. А вот с STM32, дурак, сразу не подумал так сделать. В итоге у меня есть одна интересная заготовка под F407 на дурацком SPL + еще куча полезных вещей на opencm3, все руки не дойдут переписать без библиотек. Позже стал осваивать STM32F0, там уже на грабли не натыкался — сразу пошел правильной дорогой.

SWD очень сильно помог мне, когда нужно было сдампить большой буфер данных из памяти контроллера, которые создал кодек речи. По UART будет дольше и это - дополнительная микросхема согласования лог. уровней + терминал. А через SWD - три проводка + встроенный программатор/отладчик на плате STM Discovery на USB + Utilites + окно в котором всё видно!


А вот под V3s нет
Только в составе Линукса
Поэтому лепить своё с оглядкой на Линукс

Для STM32F... вообще проблем быть не должно: Keil ARM генерит достаточно внятный стартап с пресетами + куча статей на русском языке!
Ну разве что когда код в RAM исполнять - не забыть раздефайнить перенос таблицы векторов прерываний (если они используются)

Ну и там же CMSYS со всеми объявленными хедерами - регистры, константы, битовые маски.

А HAL + пресеты STM Cube - зло ))) Разве что для раскидки пинов использовать, куб идёт только в блевистах при установленной JRE, поэтому приходится идти в гости к знакомым.
Тяжела нынче жизнь аппаратчика Приходится искать альтернативные пути, не нарушая свои принципы...

Можно. Да так, что ядро отладки напрочь отключается, если прошивка не финальная, то камень в помойку. RTFM


Штатный бутлодырь у STM32 стереть невозможно. После тотальной залочки им уже нельзя изменить прошивку, хотя связь с ним все еще возможна.
Если же подход более профессиональный - самодельный бутлодырь, то в этом случае даже с тотальной залочкой обновление прошивки возможно средствами этого самописного бутлодыря, но сам бутлодырь уже никак не заменить.
Поэтому тотальную залочку у STM32 следует включать только в самом финале выпуска изделий в серию. Собственно для этого он и был создан.

Вот уж действительно заняться нечем

иногда такой подход оправдан.
как правило дефайны регистров делаю т через указатели и к ним обращаются так: *pGPIO_ISR=0x000, а хочется так: GPIO_ISR=0x0000.
вот и приходится (volatile unsigned long int*) переправлять на *(volatile unsigned long int*) и отсекать *p
Ну это уже мелочи.
И кстати, из опыта, некоторые регистры отсутствуют в стандартных хедерах на STM32, приходилось дописывать самому.

Дык, в штатном дейфайне на STM это уже сделано, через структуры. Все просто и очевидно.
Но если изобретение велосипеда - хобби, то это все меняет

Кстати, вот список процессов в WinXP от компа с которого пишу:

Нажмите для просмотра прикрепленного файла

Обратите внимание - как мало процессов. Говно практически вычищено. Очень сомневаюсь, что под блевистами (windows vista,7,8,9,10,...) такое возможно.

Вот это действительно конфа под которой приятно работать, так как всё чисто.

И вирусы поймать можно только если запустить левый exe-шник скачанный из интернета.
Потому что Java, Silverligtht, Flash, RPC выпилены, порты закрыты (кроме нужных)


Структурное описание регистров порой генерит слишком большой код и снижает понимание процессов, происходящих в аппаратуре.
Но это лишь моё мнение.

Гы Яркий пример хронической паранойи и суперпедантизма.
Либо вам, просто, заняться больше нечем

Это так, если компилятор взят из 90х

Я эту фигню не использую, во-первых, линуксоид, во-вторых, зачем мне под виртуалкой гонять ворованный софт, когда есть родное? IDE — geany (правда, я его тупо как редактор использую), а дальше все при помощи make делается (от компиляции до загрузки).


Для STM8 это был единственный вариант, т.к. готового заголовочного файла в нормальном формате со всеми дефайнами и под лицензией, совместимой с GPLv3, я не нашел!


Что такое "штатный дефайн STM"? Не встречал. Скажем, под F0 я выдрал нужное из сниппетов от ST. А вот когда опять вернусь к F1, придется, видимо, из opencm3 выдирать.


Я тоже так думал, пока не проверил. Код получается абсолютно таким же, как и без структур. Все раскрывается на стадии препроцессора gcc.
Конечно, выглядит по-ублюдски, но сойдет.

P.S. А вот под STM8 так делать нельзя, потому как sdcc не оптимизирует код вообще никак! А кроме sdcc компиляторов под STM8 нет, к сожалению. Благо, этот МК не используется настолько часто, как более приятные STM32.

После установки голого KEIL, все дефайны/датышиты/профили и т.п. идут в виде отдельных PACK-ов. Их можно скачать без самого keil, и переименовать в zip, открыв содержимое.
Там все нужные дефайны.
Поскольку от HAL/SPL/CUBE отказался, сам пользую такое решение.
Аналогично у ARM сделано для других процов.

В шапке каждого дефайна вот такой текст (на примере STM32F0xx_DFP):



зы. Keil платный, отладчики от SEGGER тоже платные.

А торрент зачем?

Уважаемые mantech и другие пользователи!

Мне очень интересно поддерживать общение с вами в данной теме, но мне бы совершенно не хотелось разводить здесь юридические шашни, связанные с программным обеспечением.
В частности: последствия таблеток, какое у вас ПО, наличие-отсутствие лицензий, торренты и всё в таком духе.

Давайте не будем превращать Форум Разработчиков Электроники в ещё один форум юристов!
А то складывается такое впечатление, что некоторых кто-то напугал.
Например, пишете про Keil - какой он у вас или упоминаете его в контексте крякнутого. Не нужно этого. Зачем и перед кем оправдыватесь?

Давайте лучше делиться опытом в разработке программ для ARM !

С поправкой: в среде свободного программного обеспечения!

Не надо ля-ля. Есть IAR.

Я говорю про свободные компиляторы, а не мерзопакостную мастдайную ворованную дрянь!

Точно также так утверждают слесари с ножовкой по металлу, но то тех пор, пока не познали УШМ (болгарку)
Однако, в ряде простых случаев ножовкой пользоваться все же удобнее ...

У вас есть рабочая сборка под кортекс А9 и А7 на каком-нить эклипсе с вашим любимым гнушным компилятором, чтоб я смог установить ее к себе на машину (32х битную, если что) и не плясать неделями с бубном чтоб ее настроить, прописать кучу конфигов, либ и пр...? Может поделитесь?
А если нет - то оставьте это мнение при себе, в моем понимании инструмент должен быть прежде всего удобным, чтоб человек мог заняться собственно программированием своей задачи, а не мучиться в настройках этого инструмента.

Эклипсой не пользуюсь. Что нужно, писал у себя в ЖЖ. В принципе, если не разрабатывать под Cortex-M0, то хватит стандартного тулчейна из реп. Пользуюсь гентой. Вот для STM32F0 пришлось тащить тулчейн с оф. сайта (т.к. в "родном" тулчейне деление не работало).
В моем понимании тоже инструмент прежде всего должен быть удобным. Ну и не смущать совесть того, кто этим инструментом пользуется. Потому-то я уже лет 15 мастдайку не использую — в ней невозможно работать, 90% времени тратишь на лишние телодвижения.

И да, зачем в 2017 году работать на 32-битной машине 20-летней давности?

Потому, что она меня полностью устраивает

Не представляю себе, даже... Меня домашний компьютер 5-летней давности с 4-ядерным процессором и 8ГБ оперативы напрягает иногда: запустишь kicad, а комп задумывается.. Или гентушку поставишь обновлять, и как-то оно долго, да еще и другие задачи подтормаживают. Хотя, интернет меня больше напрягает: дома висит старый зухелевский рутер, который на 3 потребителя никак не может честно разделить входящие почти 100Мбит, если торренты качаю, то больше никому интернета нет ☹

Надоело оффтопить здесь, конечно, но уж скажу, мой знакомый поставил в конторе у себя на 4хядернике с 8гигами, убунту и на ней кикад, при перетаскивании схемы, не маленькой, он "листает" ее, что оч. заметно. Я не знаю, что он не так сделал, установил кривые дрова на видюху или еще что-то, но на моей древней машине с ненавистной масдайкой, тот же кикад не тормозит нисколько. Просто, когда я ставлю масдайку на машину, трачу 30 мин на установку драйверов и не парюсь от слова вааще, в его случае, я даже не знаю что тут делать где-то искать дрова, собирать их самому или что еще... Да нафига мне это нужно, мне проект делать надо, а не в собиралки играть. Именно поэтому считаю, что свободный, читай, любительский софт никогда не будет конкурировать с профессиональным, т.к. делают его итузиасты в свободное время.
И еще на тему торможения - я никогда не использую рабочую машину для инета, да еще с открытием кучи вкладок в браузере, поэтому и не тормозит ничего, для инета есть рядом стоящий ноутбук.

ОК, все равно мне никогда психологию вендузятников не понять…

На всех современных компах узким местом является наличие HDD.
Поэтому достаточно лишь поставить SSD, хотя бы чисто под систему и установленный софт.
После этого даже откровенный хлам легко обгонит нормальный комп с обычным HDD!
Неоднократно подобное наблюдал. Рекомендую
Тогда не потребуется параноидальная чистка запущенных процессов, тонкий тюнинг системы и т. п. фетишизм

Поддерживаю, и добавить оперы по максимуму, после этого мой древний амдшный турион стал работать куда шустрее



Никогда этим не занимался, просто установлено только то, что нужно.

Этот камень был направлен не в ваш огород