требуется программист STM32 Опции

[Roman_msk]

Добрый день,
требуется программист на низы, STM32 микроконтроллер ... из перриферии: UART, ADC, COMP, DAC, I2C, Timer.
ТЗ и бюджет обсуждается индивидуально, удаленка допустима!
заинтересованным писать в личку или на почту: furia(dot)fly(гав-гав)gmail.com

[hasl]

требуется программист на низы

Простите, но что в вашем понимании "Низы"

"Чукча не дурак, дурак бы не понял"

Сообщение отредактировал hasl - Feb 20 2018, 14:09

[Ivan_Petrov]

Простите, но что в вашем понимании "Низы"

"Чукча не дурак, дурак бы не понял"

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

[DrGluck]

"Ниже" bare metal только heavy metal !

[jcxz]

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

В одном из проектов у меня было:
1. Самый нижний уровень: элементарные транзакции по SPI с FLASH/FRAM - чтение непрерывного блока байт, запись непрерывного блока байт, стирание страницы FLASH и т.п.
2. Уровень немного выше: арбитраж доступа к шине SPI - планирование транзакций по приоритету от разных служб, использующих структуры хранения во FLASH и FRAM, анализ чей запрос важнее, какие чипы FLASH сейчас находятся в свободном/занятом состоянии (выполняют внутреннюю запись/стирание) и мониторинг их состояния.
3. Уровень ещё выше: обеспечение атомарного доступа к структурным единицам хранения во FLASH/FRAM. Атомарного - в смысле "непрерывного для событий сброса/выключения_питания процессора".
4. Уровень ещё выше: Логические объекты хранения во FLASH/FRAM - журналы событий (со своим набором методов), файловая система и другие объекты.
5. Ещё более высокий уровень (этим занимался уже другой программист) - методы доступа к журналам и файловой системе с прикладного уровня протокола/протоколов обмена прибора и из служб событий прибора.
Каждый уровень работает через API нижележащего уровня. А не смешано всё в одну кучу.

И операционка тут совсем не при чём. Это называется: "грамотное планирование архитектуры исходного ПО". С ОС или без - без разницы.
У дилетантов обычно вообще никакой архитектуры нет как понятия. Просто всё - одна куча. Поэтому могут решать только самые элементарные задачи.

PS: В контексте запроса ТС можно предположить, что нужен человек, умеющий организовать некие сервисы (хранения, передачи данных и т.п.) через указанную периферию, с определёнными свойствами и определённым уровнем абстрагирования от конкретного железа/интерфейсов. Для программистов более высокого прикладного уровня. Т.е. - системный программист.

[DrGluck]

В одном из проектов у меня было:
........
PS: В контексте запроса ТС можно предположить, что нужен человек, умеющий организовать некие сервисы (хранения, передачи данных и т.п.) через указанную периферию, с определёнными свойствами и определённым уровнем абстрагирования от конкретного железа/интерфейсов. Для программистов более высокого прикладного уровня. Т.е. - системный программист.

Такое ощущение, что ТС-ы никогда не научатся четко озвучивать "хотелки" и "пожелалки" ...

[Эдди]

"Ниже" bare metal только heavy metal !

Видимо, нужен программист, который прошивку будет сразу в машкодах писать.

[smk]

"Нижний уровень" это термин из автоматизации. Обозначает программирование ПЛК. А верхний это скада.

[misyachniy]

"Нижний уровень" это термин из автоматизации. Обозначает программирование ПЛК. А верхний это скада.

"Верхи" объявлены здесь:
https://electronix.ru/forum/index.php?showtopic=145882

[jcxz]

"Верхи" объявлены здесь:

Нет. Ибо на Cortex-M ни линух ни тем более винда - невозможны.

[Molotov]

Я так понял это ассемблер. Разве нет? Кстати, на ассемблере не пишут для STM32(насколько я знаю), только C++. Ну может вставки там какие-нибудь на ассемблере если только. Или он имел ввиду регистры? - Это все о "низах".

Сообщение отредактировал Molotov - Feb 21 2018, 06:48

[jcxz]

Я так понял это ассемблер. Разве нет?

Нет. См. сообщение #5.

Кстати, на ассемблере не пишут для STM32(насколько я знаю), только C++.

Пишут.

[Эдди]

на ассемблере не пишут для STM32(насколько я знаю), только C++

На ассемблере пишут. Некоторые даже на С++ пишут. Но подавляющее большинство таки С использует. Потому что ассемблер — слишком долго, а С++ — слишком жирно!

[Mihail Gluhowche...]

На ассемблере пишут. Некоторые даже на С++ пишут. Но подавляющее большинство таки С использует. Потому что ассемблер — слишком долго, а С++ — слишком жирно!

Вот сейчас вы разжигаете просто. C++ нормально и не жирно работает. Все зависит от удобства и задач. Даже есть RTOS на С++ написанные коллегами с форума. Широко известна в узких кругах как говориться.

[Molotov]

1) Нет. См. сообщение #5.

2) Пишут.

1)- что значит см. сообщение №5? Я от автора темы жду ответа, а не от вас.
2) Не надо тут умничать.

[Ivan_Petrov]

В одном из проектов у меня было:
1. Самый нижний уровень: элементарные транзакции по SPI с FLASH/FRAM - чтение непрерывного блока байт, запись непрерывного блока байт, стирание страницы FLASH и т.п.

Диспетчеры, журналы, атомарный доступ, "разные службы" - это как бы уже часть ОС и подобия файловой системы.
Автор то тут четко выразился что ему нужны только работа с каналами передачи.
1-2 имхо разделять на собственное АПИ если это не высокоструктурированный проект или часть ОС смысла нет, все в один файл, 1 объявить статиком, а 2 сделать в виде АПИ.
Если все разносить по файлам, то у компилятора не будет возможность глубоко оптимизировать все это.

[jcxz]

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

ОС - это только управление задачами. Всё остальное - дополнительные модули.

Автор то тут четко выразился что ему нужны только работа с каналами передачи.

Это где Вы такое узрели в его посте??? Из каналов передачи там только UART.

1-2 имхо разделять на собственное АПИ если это не высокоструктурированный проект или часть ОС смысла нет, все в один файл,

Смысл есть ибо это совершенно разные вещи. Находятся они в одном файле или в разных - это никак не относится к разбиению на логические уровни.
Разделение этих двух частей, даёт возможность легко наращивать функциональность при добавлении других устройств на данной SPI-шине: планировщик транзакций (арбитр шины) - отдельно, обработка самих транзакций - отдельно для каждого устройства на шине - своя для каждого устройства.
Своё разбиение я привёл как пример. В другой прикладной задаче/приборе вполне возможно будет другое разбиение.

[Ivan_Petrov]

ОС - это только управление задачами. Всё остальное - дополнительные модули.

ОС это распределение памяти, машинного времени и механизмы доступа и синхронизации.

Это где Вы такое узрели в его посте??? Из каналов передачи там только UART.

I2C, ADC тоже можно считать каналом передачи но в целом да, он хочет иметь доступ к разной периферии, не только передавать данные.

Смысл есть ибо это совершенно разные вещи. Находятся они в одном файле или в разных - это никак не относится к разбиению на логические уровни.
Разделение этих двух частей, даёт возможность легко наращивать функциональность при добавлении других устройств на данной SPI-шине: планировщик транзакций (арбитр шины) - отдельно, обработка самих транзакций - отдельно для каждого устройства на шине - своя для каждого устройства.
Своё разбиение я привёл как пример. В другой прикладной задаче/приборе вполне возможно будет другое разбиение.

Ну я свою классификацию тоже привел как пример, ибо писал LockFree OS и она перенесена в том числе под STM32.

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

[leocat]

Нет. Ибо на Cortex-M ни линух ни тем более винда - невозможны.

Да ладно?!
http://www.nuttx.org

[Эдди]

Линукс не установить на систему без MMU. Так что, не надо фантазировать!

[ichthyandr]

Нет. Ибо на Cortex-M ни линух ни тем более винда - невозможны.

а freertos ?

[jcxz]

а freertos ?

Конечно да.

[one_eight_seven]

Линукс не установить на систему без MMU. Так что, не надо фантазировать!

uCLinux

P.S. можно, конечно, ещё эмуляторы писать (и некоторые это делают), но зачем...

Сообщение отредактировал one_eight_seven - Feb 22 2018, 14:31

[Aldec]

из перриферии: UART, ADC, COMP, DAC, I2C, Timer.

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

[jcxz]

uCLinux

uCLinux != Linux

[=pcb=]

Линукс не установить на систему без MMU. Так что, не надо фантазировать!

Можно.
1) ucLinux на ядре 2.6. версии
2) Linux на ядре от 4.6 версии на жирные камни, а ля 429, с недавних пор.

так что можно уже фантазировать открывшиеся новые возможности...

[jcxz]

2) Linux на ядре от 4.6 версии на жирные камни, а ля 429, с недавних пор.

Ну-ну... с недавних пор в "а ля 429" самопроизвольно возник MMU???

так что можно уже фантазировать открывшиеся новые возможности...

Фантазировать можно сколько угодно, но реальность безжалостна.....

[Эдди]

ucLinux

Это никак к линуксу не относится!
Еще раз: нет MMU == нет линукса!
Хватит меня уже бредом кормить!

[one_eight_seven]

Это никак к линуксу не относится!

Это форк линукса. Более того, много наработок uCLinux'а пошли в основную ветку. Так что относится и ещё как относится

Еще раз: нет MMU == нет линукса!
Хватит меня уже бредом кормить!

Есть только два мнения - моё и неправильное. Очень правильная позиция, да.

uCLinux != Linux

Debian != Linux
Fedora != Linux.
Linux != Linux.

Ваши слепые верования не имеют ничего общего с реальным положением вещей.

[Эдди]

Ну хватит уже чушь нести!!!
Почитайте хотя бы, что такое линукс!
И да, дебилиан уже не линукс, а тем более — федора! Все, что перестало подчиняться требованиям UNIX-way, можно смело называть мастдайкой и топить в унитазе.
Эдак вы, батенька, такое откровенное дерьмище, как ондроед, линуксом обзовете!

Сообщение отредактировал Эдди - Feb 22 2018, 20:03

[one_eight_seven]

Все, что перестало подчиняться требованиям UNIX-way, можно смело называть мастдайкой и топить в унитазе.

В жизни всё произошло наоборот.

[leocat]

Ну хватит уже чушь нести!!!
Почитайте хотя бы, что такое линукс!
И да, дебилиан уже не линукс, а тем более — федора! Все, что перестало подчиняться требованиям UNIX-way, можно смело называть мастдайкой и топить в унитазе.
Эдак вы, батенька, такое откровенное дерьмище, как ондроед, линуксом обзовете!

https://ru.wikipedia.org/wiki/Linux

Linux — семейство Unix-подобных операционных систем на базе ядра Linux, включающих тот или иной набор утилит и программ проекта GNU, и, возможно, другие компоненты.

Т.е. следуя официальному определению - именно так! Ведроид есть Линкус. Кстати, об этом на одной из конференций сам Товальдс сказал. С ним спорить будете?

[jcxz]

операционных систем на базе ядра Linux

А теперь почитайте что входит в это самое ядро.

[Эдди]

Помимо состава ядра пусть товарищ еще расскажет, что за гнутые утилиты есть в ондроеде!
Что-то я там такого не замечал. Где там баш и coreutils? Одна бессмысленная оболочка на жабе, от которой 0 толку!

[leocat]

А теперь почитайте что входит в это самое ядро.

Да собственно ядро оно и есть ядро...
По поводу спора лицензий, так у "верхних" ребят холивар покруче тутошнего. Например: ведроид распространяется под лицензией апачи...
и...

Совместимость с GPL
Фонд Free Software Foundation объявил все версии лицензии Apache несовместимыми со второй версией GPL.

Apache Software Foundation, начиная с 2004 года, настаивает на своём праве решать вопрос совместимости Apache лицензии с GPL.

Согласно Free Software Foundation, GPLv3 совместима с Apache License v2.0. Как следствие, разработчики всегда имеют возможность свои программы под Apache License v2.0 перевести под GPL v3.0, чтобы быть уверенными в том, что производные их разработок (форки) останутся свободными. Однако смена лицензии с GPL на Apache невозможна, поэтому совместимость односторонняя.

И хотел бы уточнить, что вы имеете ввиду под словом ядро? В моем понимании ядро это Linux kernel.

Сообщение отредактировал leocat - Feb 23 2018, 07:27

[Grizzzly]

Linux kernel запросто можно собрать без поддержки MMU: https://unix.stackexchange.com/questions/19...l/190358#190358
Так что это всё по-прежнему Linux

[Эдди]

И что это будет за линукс такой без MMU? Как он будет распределять память среди процессов и потоков?

[one_eight_seven]

И что это будет за линукс такой без MMU? Как он будет распределять память среди процессов и потоков?

С помощью page table, например.
Кроме того, ядро и так этого не делает. Это делают модули ядра.

Сообщение отредактировал one_eight_seven - Feb 23 2018, 18:18

[jcxz]

Кроме того, ядро и так этого не делает. Это делают модули ядра.

Дело не в выделении памяти.
Я не знаю как организовано адресное пространство в linux-приложениях, но думаю, что подобно винде: каждое запускаемое приложение имеет своё виртуальное адресное пространство, в которое, кроме того, отображаются какие-то системные пространства адресов (DLL и т.п.). Уже не говоря про защиту адресных пространств.
Всё это - благодаря MMU.
И как в таком случае запустить приложение, скомпилённое для работы в виртуальном адресном пространстве, без MMU???
Есть одно приложение, скомпилённое для работы по адресу скажем 0x40000, и есть другое приложение, тоже скомпилённое для работы по адресу 0x40000. Как обеспечить их одновременную работу без MMU?
А если приложение использует большой объём памяти, за счёт подкачки с диска? Опять-же - как без MMU?

[gerber]

Есть одно приложение, скомпилённое для работы по адресу скажем 0x40000, и есть другое приложение, тоже скомпилённое для работы по адресу 0x40000. Как обеспечить их одновременную работу без MMU?

Размещение программных сегментов в конкретных адресах (виртуальных или физических) происходит на этапе загрузки приложения, посмотрите формат ELF-файлов и ELF Loader. Поэтому ничто не мешает разместить 2 приложения в едином адресном пространстве. Нужен соответствующий ELF Loader, и хватило бы памяти в принципе по объему.

А если приложение использует большой объём памяти, за счёт подкачки с диска? Опять-же - как без MMU?

Даже на "взрослых" машинах с MMU вполне себе существует Linux без swap-файла и подкачки памяти с диска. MMU тут не при деле, кто будет генерировать исключение при нехватке памяти - MMU или менеджер памяти, не суть важно

[Roman_msk]

Благодарю всех откликнувшихся, исполнитель найден!

[jcxz]

Поэтому ничто не мешает разместить 2 приложения в едином адресном пространстве. Нужен соответствующий ELF Loader, и хватило бы памяти в принципе по объему.

Ну если можно генерить исполняемые файлы и с таблицей перемещения - то пойдёт.
А если я хочу вычислить адрес целевой переменной используя скажем - операции побитового OR или AND или сдвига над адресом? В варианте с линейным виртуальным адресным пространством, перемещаемым при помощи MMU - да никаких проблем! А вот если попробуем слинковать это в перемещаемый загрузочный образ, то я думаю получим ошибку компоновщика, так как не допускается обычно при этом никаких операций кроме сложений и вычитаний.

Даже на "взрослых" машинах с MMU вполне себе существует Linux без swap-файла и подкачки памяти с диска. MMU тут не при деле, кто будет генерировать исключение при нехватке памяти - MMU или менеджер памяти, не суть важно

Менеджер памяти - это кто? Это тот, кто выделяет динамическую память из пула? malloc()/free()?
А при чём тут "исключение при нехватке памяти"? Если сумме работающих в данный момент приложений нужно больше памяти, чем есть физически, то это и решается подкачкой, когда страницы памяти, к которым давно не было обращения, вытесняются из физической памяти в своп, и это место физической памяти используется для хранения других страниц виртуальной памяти. А когда приложению потребуется вытесненная память, оно просто обратиться по данным адресам, MMU сгенерит исключение и страница будет возвращена из свопа в физическую память. И делается это силами MMU. Приложение про всю эту кухню не знает, и не обращается к менеджеру памяти вообще после того как получит весь необходимый объём от malloc().
Без MMU такой механизм организовать невозможно. Соответственно те задачи, которые нормально выполняются в среде с виртуальной памятью, не могут быть выполнены никак без неё - только переписыванием алгоритма работы приложения.
Опять-же - как без MMU отображать в память процесса какие-то общие ресурсы? Например библиотеки? (есть в линухе аналог DLL?) Или файлы (чтобы работать с ними просто как с областями памяти)?
Далее - как полноценно защитить адресное пространство одного приложения от другого без MMU? Да никак.
Если всё это вычесть из полноценного линуха на ядре с MMU, то останется он при этом линухом или это будет уже совсем другая ОС? Да нет конечно - это совсем другая уже ОС будет.

[one_eight_seven]

Без MMU такой механизм организовать невозможно.

Возможно. По сути MMU - это просто аппаратный ускоритель. Эмуляторы MMU существуют и работают. Медленнее, конечно, но работают.

P.S.:
http://www.infradead.org/~mchehab/kernel_d...nommu-mmap.html

Сообщение отредактировал one_eight_seven - Mar 6 2018, 10:31

[Cvetaev]

Добрый день,
требуется программист на низы, STM32 микроконтроллер ... из перриферии: UART, ADC, COMP, DAC, I2C, Timer.
ТЗ и бюджет обсуждается индивидуально, удаленка допустима!
заинтересованным писать в личку или на почту: furia(dot)fly(гав-гав)gmail.com

Еще актуально ?