Заметил у lwIP такую проблему, что если при пропадании линка закрывать сокет, а при восстановлении линка создавать его заново, валятся ошибки выделения памяти MEMP_TCP_PCB. Проблема, судя по всему, в том, что при пропадании линка сокет остаётся активным и не может корректно закрыться. При последуюшем создании сокета обнаруживается, что больше свободных сокетов нет и после принудительного удаления активного соединения всё создается как надо.

Проблема не очень серьёзная, но хотелось бы выяснить, как её обойти, и у всех ли она проявляется.

Для проверки попробуйте создавать сокет после появления линка, закрывать через close после исчезновения линка. Ограничьте память до одного сокета: MEMP_NUM_TCP_PCB = 1.

Не могу решить задачу, если она решаемая. Chat GPT и Stack Overflow опрошены, но результаты мне не понравились.

// Настроечная структура содержит настройки для вольтметра и амперметра
struct Settings {
        VSettings voltmeter;
        ASettings ampermeter; // Типы VSettings и ASettings разные, не имеют ничего общего, но имеют одинаковые названия полей

        auto & get( int ch ) { // Хочу, чтобы этот метод возвращал разные структуры настройки в зависимости от величины аргумента
            if (ch < 3)
                return voltmeter;
            else
                return ampermeter;
        }
};

                       
// Использовать хочу так
Settings s;
s.get(chvalue).поле_структуры = некое_значение;

Это возможно на Си++ 17?)

Если кто сталкивался, помогите плизз. Долбаюсь уже 2 недели, и ничего не получается. Ситуация следующая: Есть некий контроллер и общается он с компьютером через RS232, в Win98 все работает, а вот Операционка Win2000

блокирует прямое обращение к портам. Мне подсказали прогу WinDriver для обхода этой проблемы... но опять-же, для LPT порта там есть стандартная заготовка, которая прекрасно работает... а о СОМ порте ни слова. Сразу оговорюсь, я не являюсь системным программистом и с железом дел никогда не имел... а тут пришлось ;) Искренне надеюсь на Вашу помощь. Заранее спасибо.

З.Ы.

Я впервые на этом форуме, и вполне возможно что запостил тему не совсем в тот раздел куда следовало бы.

ЗЗ.ЫЫ

Работать с этой штукой через CreateFile/ReadFile/WriteFile тоже не получается,

в ReadFile постоянно нули возвращаются, хотя команда сформирована верно и контроллером принята...

   HANDLE hComm;
   hComm = CreateFileA("\\\\.\\COM2",                 //port name
                        GENERIC_READ | GENERIC_WRITE, //Read/Write
                        0,                            // No Sharing
                        NULL,                         // No Security
                        OPEN_EXISTING,                // Open existing port only
                        0,                            // Non Overlapped I/O
                        NULL);                        // Null for Comm Devices
   if (hComm == INVALID_HANDLE_VALUE)
       printf("Error in opening serial port\n\n");
   else
       printf("Opening serial port successful\n\n");
   CloseHandle(hComm);//Closing the Serial Port

Если нет, пойду курить FT2xx

Подскажите пожалуйста, кто знает, где определен параметр NETCONN_TCP?

Я пытаюсь сделать соединение lwip TCP clien-server  используя netconn

Соответственно с такими дефайнами 

/* Includes ------------------------------------------------------------------*/
#include "main.h"
#include "lwip.h"
#include "lwip/init.h"
#include "lwip/netif.h"
#include "lwip/timeouts.h"
#include "netif/etharp.h"
#include "ethernetif.h"
#include "app_ethernet.h"
#include "tcp_echoclient.h"
#include "lwip/sys.h"
#include "lwip/api.h"

делаю соединение

struct netconn *client_conn;
client_conn = netconn_new(NETCONN_TCP);

и получаю при сборке ошибки

Quote

../Core/Src/main.c:134:20: warning: implicit declaration of function 'netconn_new' [-Wimplicit-function-declaration]
  134 |      client_conn = netconn_new(NETCONN_TCP);
      |                    ^~~~~~~~~~~
../Core/Src/main.c:134:32: error: 'NETCONN_TCP' undeclared (first use in this function)

Поискал в библиотеках STM и примерах, также не нашел определение NETCONN_TCP

И также не понятно почему с такими дефайнами также ругаются на netconn_new

приходят данные одномерный массив на 1600 байт, его надо налету осреднить самым простым способом 

for(z=2;z!=1600-3;z+=1)
  {
    if(Flag_3x3) data_main[z] = (  data_main[z-1]+                              // осреднение по 3
                                   data_main[z+1]+
                                   data_main[z+0])/3;
 }

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

можно как то ускорить осреднение и вообще непонятно откуда такие тормоза, вроде простые операции.

Массив приходит с частотой 70 гц

Через wget проблем со скачиванием нету вовсе, где-то что-то я делаю не так.

Дано: Приложение (WinXP...Win11) открыло COM-порт и держит его открытым. Обмен данными по порту предположим - отсутствует. Или приложение ожидает входящих данных, не начиная передачу в порт по своей инициативе. Порт открыт и используется в overlapped-режиме. Работа с портом производится напрямую - через WinAPI, без каких-либо прослоек/либ.

Вопрос: Как в данном случае приложению быстро и достоверно обнаружить факт пропадания COM-порта из системы? (при отключении USB-устройства например) Каким методом отслеживать факт пропадания порта?Передавать данные в порт по инициативе приложения или менять состояние сигналов (RTS, DTR, etc.) - нельзя (по условию задачи). Периодически закрывать и переоткрывать дескриптор - тоже нельзя.

Если продолжать держать COM-порт открытым, то после пропадания COM-порта, его дескриптор остаётся валидным и активным. С ним продолжают корректно работать операции WinAPI чтения данных (возвращают 0 байт) и операции запроса статуса. По результату их выполнения судить о пропадании порта не получается. Если порт был удалён из системы, а потом заново появился, то пока старый дескриптор остаётся открытым, программа не видит данных, идущих из вновь появившегося порта. И не увидит, пока не закроет/переоткроет порт заново. Но как ей узнать, что необходимо произвести такое действие? Имхо - любому, кто работал с виртуальными COM-портами должна быть известна такая проблема.

Создание дубликата дескриптора открытого порта и операции с ним проходят аналогично успешно - так не получается детектировать факт пропадания. Использовать WM_DEVICECHANGE - тоже не хочется (так как типы виртуальных портов могут быть разными; хочется универсального метода). Также не хочется использовать детектирование через SetupAPI (по пропаданию порта из реестра Windows). Ведь порт может пропасть на короткий интервал времени. И заново появиться. И насколько тогда часто нужно сканировать реестр через SetupAPI чтобы поймать этот момент?

Желателен какой-то метод определения, что текущий открытый дескриптор COM-порта протух более не связан с существующим в данный момент COM-портом. Метод работающий без закрытия дескриптора и без отправки каких-либо данных в порт. Пробовал разные функции WinAPI, но не нашёл такой, по выполнению которой можно было бы обнаружить эту ситуацию.

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

• если порт ещё жив и не пропадал из системы: при попытке параллельного открытия возвращается код ошибки "ERROR_ACCESS_DENIED" (так как порт открывался не в shared-режиме);
• если порт пропал из системы и в данный момент отсутствует: при попытке параллельного открытия возвращается код ошибки "ERROR_FILE_NOT_FOUND" (такого порта нет);
• если порт пропал из системы и появился заново: его параллельное открытие проходит успешно, без ошибки.

Проверил этот метод на Win7 с USB CDC COM-портом - работает стабильно. Но насколько он надёжен? Нет ли каких-то подводных камней? Будет ли он также надёжно работать в других версия Win? И насколько надёжно полагаться на коды ошибок, возвращаемых функциями WinAPI? Не станут ли в других версиях Win возвращаться другие коды ошибок для описанных состояний? Может лучше комбинировать данный метод со сканированием реестра через SetupAPI?

Кто что думает?

Может кто-то решал подобную задачу, успешно её решил и поделится своим методом? 

typedef struct {
  u32 id  : 29,
      ext :  1,
      rtr :  1,
      dlc;
  
  union {
    u8  byte[8];
    u16 half[4];
    u32 word[2];
  };
} sCANFrame;

s32 can_Send(eCANBus canBus, sCANFrame const *frame);

Частенько вместо прямого создания объекта sCANFrame, заполнения его, и вызова can_Send(), я прибегаю к использованию составных литералов

can_Send(CAN_BUS_1, &(sCANFrame){
  .id      = DEV_CAN_TX_ID,
  .ext     = CAN_ID_EXT,
  .rtr     = 0,
  .dlc     = 8,
  .word[0] = 0xA,
  .word[1] = 0xB
});

Т.е. здесь в стеке создается анонимный объект типа sCANFrame и передается функции отправки.

Однако, если я в ряд расположу множество (>1) таких конструкций, листинг показывает, что начальная резервация стека увеличивается как раз на N * sizeof (sCANFrame) + конечное выравнивание. Т.е. ничего не мешает компилятору использовать ту же память стека под составные литералы последующих вызовов, однако компилятор так не делает.

Может, есть какой-то ключик в CLang/GCC?

Казалось бы, простой вопрос, но в реальности не совсем простой.

У меня любой девайс имеет зашитую HW-версию и FW-версию в виде MAJOR.MINOR.PATCH. Например, 1.0.0.

С FW обычно все просто: мажорная версия отражает глобальные изменения прошивки - т.е. функциональное наполнение проекта в целом. Например, прошивка версии 1.x.y не задействовала обмены по какой-то линии связи. В версии 2.x.y она задействуется, и по ней осуществляется обмен с какими-то внешними девайсами. Минорная циферка показывает номер стабильной версии ПО, т.е. она чуть детализирует мажорную цифру. Циферка патча наращивается при любом изменении текущего образа ПО, например, в процессе отлова багов - глобальный функционал не меняется, но для различения версий как раз служит патч-цифра.

То же самое с HW.

И вот тут появляется проблема. Например, разводится плата на другом МК. Версия HW меняется, но версия функционала ПО может не меняться: "извне" для разработчика функционал остается прежним. Т.е. циферки версии FW не должны меняться. Например, такое бывает, когда плата с одной и той же электрической схемой разводится по-разному конструктивно (поэтому версия HW меняется, чтобы удаленно можно было мониторить, что это за девайс). Но бывает и так, что плата меняется незначительно, но требует программных изменений (дергать лишнюю ножку, например). При этом фукцнионал девайса для стороннего наблюдателя не изменяется никак. В общем случае, рано или поздно, появляется зоопарк прошивок, на которых, вроде, и пишется версия ПО, но из них не понятно, с кем и чем она совместима🙂

А еще все сильно усугубляется различной применимостью одних и тех же девайсов: например, какая-нибудь CAN-клавиатура может отличаться только измененным битрейтом и набором рабочих CAN-ID. Т.е. появляется некое техлицо/исполнение.

Может, есть весьма строгий и проверенный временем метод контроля и присвоения версий?

P.S. Мда. Стоило ведь отправить пост, как через пять минут поисков наткнулся на замечательный сайт: https://semver.org/. 100% попадание.

Какова максимальная возможная реалтаймовость не-GUI потока win-приложения на уровне пользователя (без разработки драйвера уровня ядра)?

Допустим: Имеем отдельный поток (для работы с железом). Без GUI-вызовов из него. И без блокировок потока при доступе к разделяемым ресурсам (предположим - вся межпоточная синхронизация выполняется неблокирующими методами: Interlocked...()-функциями, межпоточными асинхронными сообщениями, сигналами и т.п.). Поток работает только со своими данными и своими же (выделенными только ему) ресурсами.

Так вот - как обеспечить максимально возможную реалтаймовость этого потока? Т.е. - чтобы все события в нём происходили максимально точно по заданными времянкам. Если скажем нужно, чтобы поток получал управление каждые 20 мсек, с минимальным отклонением от этого интервала вне зависимости от прочих событий в системе? Какими средствами этого достичь? На обычном ПК, без каких-то аппаратных добавлений к нему и без доп.драйверов на уровне ядра. На виндах от XP до последних.

Рабочему потоку (о котором и идёт речь) выставлен высокий приоритет = THREAD_PRIORITY_TIME_CRITICAL. Временные интервалы пробую создавать двумя методами:

1. Мультимедиа-таймером: timeBeginPeriod(1)/timeEndPeriod(1). Разрешение (запрошенное и выданное) = 1ms. Из callback-функции ММ-таймера пинаю рабочий поток посылкой ему сигналов (SetEvent()).

2. Созданием отдельного высокоприоритетного потока (также THREAD_PRIORITY_TIME_CRITICAL). Который занимается только тем, что ложится спать на 20 ms, просыпаясь посылает сигнал (SetEvent()) рабочему потоку и снова ложится спать. Больше ничего не делает.

Но оба этих метода работают не очень хорошо.  Потестил программу в течение некоторого времени параллельно с обычной работой на двух разных ПК (ничего особенного - обычный набор программ: браузеры, компиляторы и т.п.) с разными win (Win7, Win11). Сделал сбор статистики периодичности вызовов функций пинания рабочего потока. Получаю такую картину:

С префикса "mmTimer" - статистика по вызовам мультимедиа-таймера. "Thread" - по вызовам из спец.потока. Статистика накоплена за время работы - немногим более часа.

3 столбца = минимальное/среднее/максимальное время между вызовами.

Как видно - разброс получился довольно значительный. Хоть ПК, на котором это работало - современный AMD Ryzen (6 ядер / 12 потоков) и не загружен особо. Почему так?  

Причём (как видно) - "Thread"-метод довольно хорошо держит нижнюю границу (отклонение менее 1 ms). Но зато - плохо держит верхнюю границу. Иногда возникают какие-то задержки аж на почти 70ms сверх положенного! Да и в среднем - отклонение больше, чем у ММ-таймера.

А мультимедиа-таймер лучше держит средний интервал, но очень плохо - нижний интервал (а это самый критичный для меня параметр). Причём - это в данном запуске теста нижний интервал упал всего до ~8.2 ms. В другом запуске на другом ПК он падал ещё ниже.

Так вот: Может кто подсказать ещё другие способы получения событий потоку (пинания потока) в Win с более высокой точностью/стабильностью? Пинания с обычного уровня пользовательского приложения. Кроме двух вышеприведённых испытываемых.

PS: Все данные измерений времени получены от службы аппаратного таймера - QueryPerformanceFrequency()/QueryPerformanceCounter(). Поэтому думаю - достоверны.

Вообще, конечно, интересна математика происходящего. Как я понимаю, авторы каким-то образом считают в "14-месяцовых годах". В чем тут "фокус"? Откуда именно такие магические числа в преобразованиях?🙂

Вопросик такой, не встречались-ли никому редакторы форм для графических приложений, виджетов и пр. а-ля винда и подобные, EMWIN- подобные и пр, но в исходниках на Си (С++), язык принципиально, т.е. всякие шарпы, qt и пр. не интересно. Под винду, любую версию)))

Наверняка есть что-то подобное, чтоб с нуля не ваять все это хозяйство)))

Допустим, у меня есть структуры разного формата, имеющие одинаковые начальные последовательности, для их динамической идентификации

typedef struct {
  u32 type;
  
  float f;
  int   i[10];
} S0;

typedef struct {
  u32 type;
  
  char const *name;
} S1;

typedef struct {
  u32 type;
  
  double d;
  char const *name;
  u32    u;
} S2;

...

S0 s0 = {0, ...};
S1 s1 = {1, ...};
S2 s2 = {2, ...};
...

Как видно, у них у всех имеется в начале u32 type. Язык Си пишет вот что (6.7.2.1)

Цитата

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

Соответственно, указатель на объект структуры можно явно преобразовать в указатель на первый член структуры и наоборот.

Теперь, я собираю в кучу-массив указатели на эти структуры: явно это сделать не получится, поэтому можно через тип первых членов

u32 *array[] = {
  &s2.type,
  &s0.type,
  &s1.type,
  ...
};

Теперь мне из внешнего мира, в run-time прилетает "индекс", по которому я лезу в этот массив и должен обратиться к объемлющей структуре, к любым ее полям

u32 num = get_num();
u32 *p = array[num]; // получили указатель на начало какой-то структуры в памяти, а дальше парсим ее

switch(*p) {
    ...
    case 1:
      printf("%s", ((S1 *)p)->name); // вот - преобразую "обратно" - из указателя на u32 в указатель на структуру, чей первый член есть u32, все законно
    ...
}

Однако не совсем законно это с точки зрения правил псевдонимов, вроде как. Как тогда реализовать динамический парсинг структур, когда заранее не известен порядок указателей в массиве? Корректно с точки зрения правил Си.

сделан один поток , в котором постоянно ждем событие прерывания на ноге процессора

после появления события вызываем коллбэк , в котором чтото делаем и отсылаем-принимаем по SPI

кроме того сама главная программа постоянно работает со SPI

Как сделать некий аналог IRQ callback  как в обычном контроллере 

Т.е что бы при вызове коллбэка в потоке основная программа блокировалась , после завершения коллбэка , основная программа разблокировалась?

например где то в потоке бесконечн бежит опрос  паралельно с основной програмой 

wile(){

    if(waiting_rise_gpio  ()){

     my_IRQ_callback();

   }

а в самом коллбэке

void my_IRQ_callback(){

// блокируем выполнение(переключение потока) основного кода в мэйн

//здесь бежит только этот поток , один

// включаем разрешение на возврат к main

//теперь потоки опять чередуются

}

Могли бы пояснить некоторые моменты касательно использования poll для случая GPIO в роли IRQ

Сейчас есть такой прототитп

1.  chip0_poll = open ("/dev/gpiochip0", O_RDONLY);

2.rq_poll.lineoffset = PD14;  //
  rq_poll.eventflags = GPIOEVENT_EVENT_RISING_EDGE;
  rq_poll.handleflags = GPIOHANDLE_REQUEST_INPUT;
  ret = ioctl (chip0_poll, GPIO_GET_LINEEVENT_IOCTL, rq_poll);

3.  pfd.fd =        rq_poll.fd;
     pfd.events = POLLIN | POLLPRI;

 //lseek( chip0_poll, 0, SEEK_SET);    /* consume any prior interrupt */  ??

4.ret = poll(&pfd, 1, time_out_ms);

5. if (pfd.revents & POLLPRI)

          rd = read(req.fd, &event, sizeof(event));  ??

close ( pfd.fd)  ??

close(rq_poll.fd)  ??

close (chip0_poll) ??

-Вопрос по черным строкам, как я понимаю надо прочитать файл после poll что бы исключить ошибочного повтора , какой  размер sizeof(event)  ??      Гдето 1 байт а гдето в примерах 10

-lseek    надо добавлять  , если да  то куда?

-close ( pfd.fd) close(rq_poll.fd)  close (chip0_poll)  это одно и тоже  и можно один оставить или они содержат разные значения?

#define INT_LITERAL_SUFFIX_OCT_0
#define INT_LITERAL_SUFFIX_OCT_1
#define INT_LITERAL_SUFFIX_OCT_2
#define INT_LITERAL_SUFFIX_OCT_3
#define INT_LITERAL_SUFFIX_OCT_4 ll
#define INT_LITERAL_SUFFIX_OCT_5 ll
#define INT_LITERAL_SUFFIX_OCT_6 ll
#define INT_LITERAL_SUFFIX_OCT_7 ll

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

И вот относительно недавно обнаружил, что среди вороха всплывающих идентификаторов в IDE мелкнул __INT8_C_SUFFIX__, а за ним и __UINT8_C_SUFFIX__ и т.д. для всех целых типов.

Подумал, чего мне свои определения писать для каждой платформы, если они уже где-то определены. Очень надеялся, что эти определения будут где-нибудь в стандартном <stdint.h>, ан-нет.

Это чисто компиляторные предопределенные макросы, наряду со всякими __LINE__, __FILE__ и т.д.? На них можно полагаться для разных компиляторов? Или оно не стандартно и где-то может отсутствовать?

Знаю что для linux есть valgrind, тут хоть как-то понятно направление

А вот для винды даже не знаю в какую сторону копать. Есть профилировщик в MSVS, но это вынуждает использовать их компилятор, чего я не хочу. Есть ли для связки Windosw+mingw+cmake решения, работающие из коробки? Или хотя бы с адекватным порогом вхождения.

И если проблему с выбором конкретного файла решить весьма просто - на уровне синтаксиса #include "" или <> (при необходимости еще и с указанием полного пути), то вот из-за одинаковых именований защитных макросов последующие по иерархии подключений файлы не включат свое содержимое. Понятно, что во всем проекте желательно не использовать одинаковые имена заголовков, но это "желательно" иногда не возможно не нарушить.

Подправлять имя файла или его защитные макросы "по случаю" не очень хочется, т.к. иногда у меня структура папок немного разъезжается, да и мало ли что...

Как пример - у FreeRTOS есть queue.h с его QUEUE_H, projdefs.h с его PROJDEFS_H. Я тоже люблю так кратко именовать файлы и их защитников.

Вот только разработчики RTOS пишут не сильно думая об остальном наборе исходников у юзера, а юзеру (мне) уже нужно думать об уникальности защитников.

Есть ли в препроцессоре C/C++ возможность клеить имя защитного макроса на основе текущей директории файла?

Конкатенация ## для #ifndef не работает, поэтому напрямую не получится.

Хотелось бы создавать не сложные приложения под Android исключительно взаимодействующие внешними электронными устройствами (через сеть Wi-Fi или Bluetooth соединение), т.е. создавать некие "тяжелые" приложения с воспроизведением увесистой графики, подключением к сети Интернет и прочими функциями НЕ требуется.

После прочтения некоторого количества информации вариантов для начала работы у меня в голове три:

1. Писать на ARM-ассемблере. Быстрое начало для новичка без опыта и понимания структуры простейшего приложения под Android, как я понял, в этом случае невозможно.

2. Писать на Kotlin в среде разработки типа Android Studio. Вроде как это самый стандартный вариант для начинающих, но последняя версия данной IDE требует как минимум 8Гб оперативки, ну и прочие системные требования для более менее соверенных компьютеров. Это не мой случай, т.к. ноуты у меня слабенькие, самый лучший вариант с 4Гб оперативки, остальные системные возможности даже смотрел. Я так понял бОльшая часть ресурсов будет уходить на отладку в эмуляторе. Ради Hello world покупать свежий современный ноут я точно не буду, ибо на данном этапе да и вообще в будущем - у меня не стоит задачи стать супер-крутым разработчиком мобильных приложений с перерождением в профессию в качестве основного заработка. Пока просто для развития, для себя хочу попробовать, благо время есть.

3. Писать на Kotlin, компилировать через stand alone compiler, отлаживать на реальном устройстве. Вот этот вариант мне больше всего пока что нравится. По нему и буду просить подсказки далее по этой теме.

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

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

Я создал эту тему пока только для того, чтобы СДЕЛАТЬ ПЕРВЫЙ ШАГ к описанной выше цели, а именно:

- установить компилятор языка Kotlin в свою ОС Windows, который по моему текущему представлению будет формировать из текстового файла с кодом исполняемое приложение под ОС Android

- с учетом решения изучать только Kotlin, исключив изучение Java, хотелось бы услышать советы по этому вопросу - реально ли это? (я так понял Java отторгается и становится неактуальным языком в области создания приложений под Android, поэтому я не хочу тратить на его изучения свое время)

Что я сделал:

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

- скачал на гитхабе компилятор котлин kotlin-compiler-1.8.21.zip (я так понял, что это кроссплатформенная версия) и еще скачал компилятор для windows kotlin-native-windows-x86_64-1.8.21.zip (я так понял, что это как раз то, что мне скорее всего нужно, т.к. я планирую начать практическое изучение из под ОС Windows).

Что не получается на текущий момент:

Я пока не понял как мне правильно установить компилятор и какой из них все таки нужен для моего случая. Вроде бы и в сети есть и на англиском и на русском языках разные туториалы на эту тему, но бОльша часть из них мне кажется не актуальной с давностью 3-5 лет, когда Java еще был очень значим. В части этих статей рекомендуется скачать и установить полную IDE или отдельно NDK/SDK, а затем пользоваться компилятором, который также будет установлен в процессе. Более "низкоуровневые" варианты установки stand alone компилятора встречаются значительно реже и не совсем понятны, т.к. они в основном на англиском языке. Как я понял для установки компилятора нужно создать некую переменную в среде Windows, но не совсем понятно как это сделать.

В общем, помогите шагнуть по варианту № 3 (отдельный компилятор под Windows без использования IDE с "крутой" отладкой на виртуальном устройстве)

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

Этот набор правил решили формализовать в виде компилятора языка программирования, который дает совершенно удивительные гарантии: целостность памяти, проверяемая во время компиляции.

Т.е. не memory safety of assembler and speed of ruby, а наоборот.

Вот свежий пример: в зависимости от уровня приоритета прерывания, компилятор может потребовать обернуть обращение к переменной из обработчика в мьютекс.

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

Но всё было бы слишком скучно, если бы Rust так и оставался языком в рамках традиционного юникса.

Всё пошло дальше: из раста получилось выкинуть привычный stdlib и компилировать его под микроконтроллеры.

https://rust-embedded.github.io/book/

а на базе этого родилась целая микро-ос в стиле freertos.

https://rtfm.rs/

Если интересно — могу поделиться опытом нашей разработки под stm32