Общаемся обо всём!

[Aether]

Все равно ничего не понял

Я тоже не понял. Это значит, что в URL строке передаётся SQL запрос? Может быть поможет пример?

[Алексей++]

RXL, ну дык, вся жизнь состоит из таких открытий. Между открытиями - рутина

[Aether]

Давно уже не слышал новостей от господина Dale. Уже интересно как у него дела, и чем он занимается?

[Dale]

Давно уже не слышал новостей от господина Dale. Уже интересно как у него дела, и чем он занимается?

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

1. Поскольку ликвидация безграмотности - дело всенародное, записался на специализацию Power Electronix в университете Колорадо (если кому интересно - бесплатный курс здесь). Стыдно признаться, но для меня силовая электроника до сих пор была совершеннейшей терра инкогнита. Раньше даже обычный импульсный блок питания не смог бы полноценно спроектировать, не говоря о более серьезных вещах. Прошел ровно половину курса, многое уже прояснилось. Раньше приходилось малодушно отказываться от заказов, в которых присутствовала силовая электроника (хотел найти компаньона, который взял бы на себя силовую часть, но не смог). Теперь могу сам рискнуть.

Лекции очень интересные, но их проработка и решение задач требует времени (фактически трачу на них порядка часа каждый вечер).

2. В одиночку работа идет довольно медленно. Начал сколачивать себе в помощь команду из молодежи с основной работы. Пока разминаемся на проекте open source. Собственно, сам проект довольно примитивен и конечный результат гарантированно не станет сенсацией. Скорее как упражнение для того, чтобы отладить навыки удаленной командной работы и подготовить необходимый инструментарий.

Пока для начала работа идет в знакомой колее - приложения .NET, но ребята хотят приобщиться к микроконтроллерам, и я это стремление поощряю.

3. Есть задумка для одного уже вполне серьезного проекта open source, но тут пока дело идет вяло - лень одолела, никак не закончу свой домашний кабинет, а он реально необходим для этой работы. Наведу последние штрихи и возьмусь за работу капитально, тем более что ребята тоже хотят поучаствовать, а вместе дело пойдет веселее.

4. Что касается FPGA - дня три назад получил посылку, а в посылке три китайца вот такая отладочная плата:

На ней установлена микросхема Altera Cyclone IV EP4CE6E22C8N. Приобрел на AliExpress примерно за 1300р. Продавцы, не имеющие понятия о совести (например, 1 или 2), хотят за нее примерно вдвое больше, но дураков пусть поищут в другом месте. Чтобы не лазить по справочникам: работает она на частоте 50 мГц, внутре у нее неонка 6000 с гаком логических вентилей; не последнее слово техники, но и не совсем уж бесполезная игрушка (к слову, некогда знаменитый Intel 8080 включал всего 4758 транзисторов, а вентилей, само собой, куда меньше, так что его при желании вполне можно было бы реализовать на этом кристалле). Вот хочу теперь поэкспериментировать, как выдастся возможность.

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

[Qulac]

Да, импульсники это отдельная тема. Но щас контролёры для них хорошие есть, т.е. проще стало.

[Dale]

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

[Aether]

1. Стыдно признаться, но для меня силовая электроника до сих пор была совершеннейшей терра инкогнита.

2. Пока для начала работа идет в знакомой колее - приложения .NET, но ребята хотят приобщиться к микроконтроллерам, и я это стремление поощряю.

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

4. ... работает она на частоте 50 МГц, внутре у нее неонка 6000 с гаком логических вентилей; не последнее слово техники, но и не совсем уж бесполезная игрушка (к слову, некогда знаменитый Intel 8080 включал всего 4758 транзисторов, а вентилей, само собой, куда меньше, так что его при желании вполне можно было бы реализовать на этом кристалле). Вот хочу теперь поэкспериментировать, как выдастся возможность.

Силовая электроника - широкая сфера, в плане преобразователей электроэнергии однажды возникал вопрос по поводу бестрансформаторного преобразования переменного трёхфазного 1 кВ (при мощности 100 кВт) в постоянное 24 В. Так называемое резервное питание от соответствующего генератора, однако в итоге всё пошло классическим путём. Синхронное выпрямление малых напряжений (3...5 В) при значительных токах (до 500 А) - тоже тема интересная. Также особняком стоит управление асинхронными сервоприводами - не для проектирования, а для понимания и применения.

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

Проект секретный?

Я посмотрел, довольно не слабая микросхема. Интересна реализация тактового генератора, также в отладочной плате визуально не обнаружил стабилизатора/преобразователя напряжения. Остаётся также непонятным вопрос: FPGA - это же не только логические модули, но ещё и стандартные узлы - стоит ли например, сумматор собирать из логических элементов или же применить его, как штатный блок. Опять таки: связь между verilog и реализацией в данном случае? Похоже, что рисовать средствами Altera будет правильнее.

[Dale]

Силовая электроника - широкая сфера

В самом недавнем времени обращались потенциальные клиенты с предложением разработать и сделать для них, например:

- преобразователь частоты для питания трехфазных электродвигателей от однофазной сети (ребята делают электроинструменты для дома и малого бизнеса, промышленные ПЧ для них чересчур дороги из-за неуемных аппетитов перекупщиков, примеры таких аппетитов я уже приводил по ссылкам выше);

- прецизионный импульсный сварочный аппарат для каких-то ювелирных применений (отказался сразу, даже не дослушав суть предложения);

- управляемый источник тока для гальваники.

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

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

Тут не понял.

Проект секретный?

Проект open source секретить нет смысла. Суть проекта - адаптация системы функционального и приемочного тестирования (предположительно Cucumber, хотя не исключаю, что в ходе проекта будет выбрана другая платформа) для тестирования аппаратуры. Нечто наподобие используют разработчики в Atomic Object (в моих переводах в библиотеке клуба есть упоминание об их методике), но на другой программной (FitNesse) и аппаратной платформе. Лично мне описание тестов на языке Gherkin (Cucumber) представляется мне гораздо выразительнее, чем табличный формат Fit. Аппаратную часть тоже можно существенно улучшить применением современных процессоров ARM (прежняя платформа была 8-битной, кажется, на PIC).

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

Кстати, такая штука очень пригодилась бы и для серийного производства и ремонта сложной электроники. Впрочем, эти случаи лежат явно за рамками open source.

Интересна реализация тактового генератора

PLL с довольно гибкой структурой, которая может не только делить, но и умножать частоту (правда, я пока не нашел, в каких пределах именно для моего кристалла).

также в отладочной плате визуально не обнаружил стабилизатора/преобразователя напряжения

С изнаночной стороны, которую я не показал, их целых 3 штуки на 3.3, 2.5 и 1.2V:

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

IMHO зависит от цели проекта. Если цель - изучить структуру сумматора, определенно имеет смысл синтезировать его из вентилей. Если это не учебный проект, конечно же, нужно использовать готовые блоки, благо там много всякого добра: и аппаратные умножители 18*18 бит имеются (целых 15 штук),  и 270К ячеек памяти, и еще много чего.

Опять таки: связь между verilog и реализацией в данном случае? Похоже, что рисовать средствами Altera будет правильнее.

Altera предлагает инструмент под названием Quartus, для начала попробую его, а там видно будет. Не всегда инструменты от производителя оказываются оптимальными, но начинать с ними наверняка будет проще.

[Aether]

1) - преобразователь частоты для питания трехфазных электродвигателей от однофазной сети

2) Тем более что разработчик силовой электроники почти как сапер: малейшая ошибка или небрежность - и несколько недешевых деталей испарились вместе с куском печатной платы. Любительские методы тут малопригодны.

3) Тут не понял.

4) Аппаратную часть тоже можно существенно улучшить применением современных процессоров ARM (прежняя платформа была 8-битной, кажется, на PIC).

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

6) PLL с довольно гибкой структурой, которая может не только делить, но и умножать частоту (правда, я пока не нашел, в каких пределах именно для моего кристалла).

7) Если цель - изучить структуру сумматора, определенно имеет смысл синтезировать его из вентилей.

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

3) .NET и микроконтроллеры в моём понимании являются далёкими друг от друга вещами. Вполне возможно, что потребуются дополнительные средства, упрощающие разработку, например, FTDI. В глубине я всё таки за упрощение процесса программирования, например, созданием качественной документации, а современные ОС, наоборот, с каждым годом создают новые обёртки. Я понимаю, что этот путь эволюционный, и придётся приспосабливаться.

4) Читал, как-то про "soft" процессоры типа Nios II, которые как раз и являются ARM. Тем не менее, сам ARM, даже в режиме Thumb довольно избыточен, имхо: там где можно обойтись 8-битным, стоит обойтись именно им. Кстати, пропали в выпуске 8-битные PIC с USB модулем, например, PIC 1454. Я полагаю, что не особо это было востребовано, да и программировать сильно сегментированное адресное пространство очень не удобно. Тут спору нет, 16 бит лучше.

5) У нас мало что разрабатывается, военные тестируют всё что только можно, там средства почти не ограничены, а в обычном секторе больше упор на внедрение технологий, а не разработку новых. Тут другого и быть, собственно, не может, так как базы нет. А на западе она есть.

6) Так, изначально, генератор RC или кварцевый? Без кварца жить тяжело, к тому же стоит уточнить: как PLL будет реагировать на изменение температуры - в каких пределах?

7) Я просто вот о чём подумал: предположим есть аппаратный 8 битный сумматор, конечно, если цель сложить два восьмибитных числа, то разговора нет, но предположим нужно сложить два 64-битных числа. В этом случае компилятор должен будет сам составить из вентилей схему, а тут вариантов несколько: либо оптимизировать размер схемы - сумматор с последовательным переносом - и потерять ощутимо в скорости, либо оптимизировать скорость - сумматор с выбором или Когге-Стоуна - при этом потерять в размере схемы.

[Dale]

1) и 2) Посещала такая идея, даже думал сделать испытательный стенд
...
использование малых токов удешевит компоненты, что важно в первичном эксперименте.

Я уже начал строить такой стенд. Во-первых, в конторе, которая мотает трансформаторы на заказ, сделал себе развязывающий киловаттник 220х220V, чтобы не дрожать от ужаса при работе с бестрансформаторными конструкциями. Во-вторых, купил у китайских товарищей регулируемый автотрансформатор Ресанта TDGC2-1K:

Помните популярные некогда в СССР ЛАТРы? Нечто наподобие. Настоящего ЛАТРа сейчас уже не найти, у старьевщиков на рынке в лучшем случае какие-то трухлявые ржавые останки. Думал уже, дохлый номер, но китайцы и тут на высоте.

С такой штуковиной можно сначала прототипировать на меньших напряжениях и нагрузках.

3) .NET и микроконтроллеры в моём понимании являются далёкими друг от друга вещами.

На самом деле они не настолько далеки. При правильной декомпозиции задачи лишь 5-10% кода работают непосредственно с оборудованием. Остальные 90-95% кода работают через драйверы (прослойку HAL), и их вполне можно разрабатывать и даже полноценно тестировать на персональном компьютере (я в одной из статей подробно описывал, как). Знание оборудования желательно (впрочем, как для программиста в любой области), но не обязательно.

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

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

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

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

ARM, даже в режиме Thumb довольно избыточен, имхо: там где можно обойтись 8-битным, стоит обойтись именно им.

В данном случае определенно нет. Во-первых, ARM работает на более высоких частотах. Во-вторых, за счет большей длины слова, а также аппаратного умножителя его производительность на реальных задачах гораздо выше. В данном конкретном случае это плюс, поскольку контроллер не только будет дергать уровнями на лапках, но и выполнять некоторые измерения и даже в перспективе ЦОС. 8-битник неадекватен для такой задачи, поскольку стенд должен быть быстрее испытываемой системы или в крайнем случае равняться ей в скорости. 16-мегагерцовая ATmega просто не сможет в реальном времени контролировать правильность работы системы на базе ARM.

Ну и не последний довод - дешевизна ARM. Не так давно я купил десяток вполне приличных кристаллов около 35 рублей за штуку. У какого-нибудь Atmel'а я за эти деньги получу максимум самую дохленькую 8-битную модель, если еще уложусь. Так что тут нет смысла беречь патроны, они дармовые.

5) У нас мало что разрабатывается, военные тестируют всё что только можно, там средства почти не ограничены

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

Еще одна легенда - что на военных работают особые специалисты, выведенные методами генной инженерии. На самом деле есть всякие: и умницы, и откровенные тупицы, причем последних не меньше, чем в среднем среди населения. И успехи в тестировании тоже соответствующие: что касается методик, приписанных в ГОСТах и техусловиях (вибростенды, климатика, радиационная стойкость...) - тут все путем. Что касается тестирования кода - тут опять же, как и везде, то есть либо совсем никак, либо чуть лучше: они просто не умеют тестировать точно так же, как и большинство гражданских программистов. Знаю это как по своим наблюдениям в качестве консультанта, так и от инсайдеров, поныне там работающих. Может, где-то есть продвинутые коллективы, которые справедливо возмутятся, но в целом ситуация такая же удручающая, как и везде.

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

Тут другого и быть, собственно, не может, так как базы нет. А на западе она есть.

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

6) Так, изначально, генератор RC или кварцевый? Без кварца жить тяжело, к тому же стоит уточнить: как PLL будет реагировать на изменение температуры - в каких пределах?

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

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

7) Я просто вот о чём подумал: предположим есть аппаратный 8 битный сумматор, конечно, если цель сложить два восьмибитных числа, то разговора нет, но предположим нужно сложить два 64-битных числа. В этом случае компилятор должен будет сам составить из вентилей схему, а тут вариантов несколько: либо оптимизировать размер схемы - сумматор с последовательным переносом - и потерять ощутимо в скорости, либо оптимизировать скорость - сумматор с выбором или Когге-Стоуна - при этом потерять в размере схемы.

Если нужен сумматор с большой длиной слова и высокой производительностью, пожалуй, придется проектировать самостоятельно. Либо как вариант посмотреть, нет ли готового сигнального процессора с открытым кодом на Verilog'е. Или, чем черт не шутит, не исключено, что эту задачу вообще целесообразнее решать на готовом DSP, а не FPGA. Синтезированный DSP все равно дороже выйдет.

[Sla]

Помните популярные некогда в СССР ЛАТРы? Нечто наподобие. Настоящего ЛАТРа сейчас уже не найти, у старьевщиков на рынке в лучшем случае какие-то трухлявые ржавые останки. Думал уже, дохлый номер, но китайцы и тут на высоте.

С такой штуковиной можно сначала прототипировать на меньших напряжениях и нагрузках.

А у нас есть
http://prilat.com.ua/avtotransformator_latr.html

[Dale]

А у нас есть

Не, это уже новодел 

Настоящий труъ православный ЛАТР должен быть черным и брутальным, т.е. пыльным и по возможности мятым:

Этот ваш красавец чистюля в белом - брат-близнец моей Ресанты. Тот, что росточком пониже.

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

[Алексей++]

Sla, Dale, у моего отца дома до сир пор вот такой есть )) https://h-a.d-cd.net/134d50cs-960.jpg

На фото - не он конкретно, это я по памяти в гугле картинку нашёл. По виду - он самый

Лично я им не пользовался по прямому назначению, но использовал как груз, когда что-то склеивать надо было, а также нравились тактильные ощущения при повороте ручки

[Dale]

Тоже аутентичненько выглядит.

Главное - стиль выдержан, классический стимпанк. И в меру ржавый, будто только что с планеты Кин-Дза-Дза.

[RXL]

А картинку своего ЛАТРа найти не могу. ЧОрный железный ящик примерно 200х250х350, по бокам щели охлаждения, на крышке располагались такой вольтметр, чОрная пластиковая ручка (как назывался этот термореактивный пластик, не помню) и розетка. Шнур питания выходил изнутри. Неонка не обнаружена.

[Aether]

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

как назывался этот термореактивный пластик, не помню

Вероятно, бакелит.

Помню был случай, когда нашему электрику дали задачу поставить ещё один телефон. Он полазил по закоулкам, и откопал телефон именно из такого пластика, годов 40-х. Так вот поставил его, а когда руководство увидело результат - неописуемая сцена. "Это что?? На нём что ещё дедушка Ленин что ли разговаривал??" А электрик: "Сами сказали - главное, чтобы работало."

[RXL]

Как в тему, на geektimes сегодня статья про силовые платы инвертора.

[Aether]

Вот, кстати, о чём ранее говорил:
Verilog

Код:

module counter(d, clk, clear, load, up_down, qd);

input   [3:0] d;
input   clk;
input   clear;
input   load;
input   up_down;
output  [3:0] qd;

reg     [3:0] cnt;

assign qd = cnt;

always @ (negedge clk)
begin
    if (!clear)
        cnt = 4'b0;
    else if (load)
        cnt = d;
    else if (up_down)
        cnt = cnt + 1;
    else
        cnt = cnt - 1;
end 

endmodule

Собственно, таким образом реализован двоичный четырёхразрядный счётчик. Полагаю, что компилятор в схему вставит таки сумматор, хотя если взять чисто аппаратное решение, например, К155ИЕ5, то в нём используются Т-триггеры и общее число вентилей не в пример меньше, да и работает быстрее.
Пока руки не доходили, но попробую протестировать в Икарусе оба решения - будет ли собираться Т-триггер, а потом, возможно, стоит оценить быстродействие обоих вариантов в физике.

[Dale]

Похоже, в Вашем случае счетчик реверсивный, поэтому T-триггеры вряд ли будут оптимальным решением. По крайней мере, я бы при ручном проектировании предпочел JK-триггеры. К тому же в этом случае счетчик можно заставить работать гораздо быстрее, чем на основе T.

[Aether]

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

К тому же в этом случае счетчик можно заставить работать гораздо быстрее, чем на основе T.

Справедливое замечание, сравнивать правильнее с ИЕ7.
http://www.diagram.com.ua/list/ms_ie7.shtml

Почему?

Но, самое главное: как лучше триггер описать? Дело в том, что verilog имеет всего два типа wire и reg. При первом подходе можно попробовать описать подключение через базовые ЛЭ "И-НЕ", пока есть сомнения, работоспособность предстоит проверить. Второй подход через использование условных конструкций: "always, if..." совместно с reg - тут компилятор может воткнуть демультиплексор туда, где он не нужен. В общем, всё упирается в эксперимент.

[Dale]

Как описать - пока не знаю, нужно почитать побольше литературы и попробовать на реальной плате.

В запасе на этот случай есть задача - сделать цифровой эффект Delay для концертного усилителя. Подожду, пока придет заказанная память. Для управления потребуются счетчики адреса, так что с триггерами познакомиться придется.

[Aether]

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

[Dale]

Большое спасибо, взаимно!

Больше, пожалуй, ничего особо и не нужно...

[Qulac]

Всех с Новым Годом!

[RXL]

Добавлю: пусть у вас приятных проблем будет больше, чем неприятных!

[zubr]

Организовано серийное производство персональных компьютеров Эльбрус-401 РС

http://mcst.ru/organizovano-serijnoe-proizvodstvo-personalnykh-kompyuterov-elbrus401-rs-

Круто, 750 МГЦ за 3 килобакса.

[RXL]

Коммерческого успеха им не видать, это ясно. Надеюсь, в дальнейшем цена снизится.

[Aether]

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

А вообще, больно вот что: мы живём в метрическом мире (Россия и СНГ), однако используем периферию, заточенную под стандарты США. Что не нравится: сложное представление масштабов и неточности при переводе, из-за нюансов:
1) Стандартный монитор имеет плотность 96 dpi = 0,264 мм зерно. Было бы лучше, если бы оно было ровно 0,2 мм, и плотность: 5 dpmm.
2) Стандартный принтер имеет плотность 300/600 dpi = 0,084 мм / 0,042 мм. Было бы лучше, если бы он имел плотность также кратную метрике, то есть 0,05 мм = 20 dpmm.
3) Использование в качестве размера шрифта и типографской разметки в делении американского пункта, то есть 1/72 дюйма. У нас шрифты измеряют в мм.
4) Использование кодировок ASCII+ (в том числе и UTF-8). А нужна нормальная международная.

Вообще, система типографии определяет способ хранения и распространения знаний - это одна из весьма важных вещей в том числе и в электроном обороте, но уже много лет ситуация не движется, и не будет, по видимости. То же касается и языков, типа C# - вместо того, чтобы разработать нормальный API, который позволит без значительных трудностей пользоваться ассемблером и "С", придумана надстройка в надстройке с закоулками. Можно промолчать про компонентную отечественную базу - её уже разрабатывают с начала открытия электромагнетизма, вот только в магазине либо нет вовсе современного, либо допотопное, либо крайне дорогое, и всё равно уступающее китайским промышленникам по совокупности.

Извините, выговорился.

[Dale]

4) Использование кодировок ASCII+ (в том числе и UTF-8). А нужна нормальная международная.

Unicode не годится в качестве нормальной? Там для всех алфавитов равные условия - хоть латиница, хоть кириллица, хоть иероглифы с арабской вязью. С 8-битными кодировками, действительно, были проблемы (хотя и решаемые), но они давно уж канули в Лету - даже атавизмы вроде C/C++ давно поддерживают "широкие" наборы литер.

То же касается и языков, типа C# - вместо того, чтобы разработать нормальный API, который позволит без значительных трудностей пользоваться ассемблером и "С", придумана надстройка в надстройке с закоулками.

Не вижу тут проблем, такие API давно уже есть: для того, чтобы пользоваться без значительных трудностей C, достаточно программировать на C. Насчет ассемблера, конечно, не все так радужно, но ассемблер в принципе категорически противопоказан тем, кто боится трудностей.

Что касается C# - это совершенно другая экосистема, и для своей области применения он действительно чертовски хорош (в сочетании с .NET, разумеется).

[Aether]

Unicode не годится в качестве нормальной? Там для всех алфавитов равные условия - хоть латиница, хоть кириллица, хоть иероглифы с арабской вязью. С 8-битными кодировками, действительно, были проблемы (хотя и решаемые), но они давно уж канули в Лету - даже атавизмы вроде C/C++ давно поддерживают "широкие" наборы литер.

По поводу "равности":https://ru.wikipedia.org/wiki/ISO_8859-1

В Юникоде первые 256 кодовых позиций совпадают с ISO-8859-1.
В Microsoft Windows для западноевропейских языков используется кодировка Windows-1252, которая отличается от ISO-8859-1 тем, что позиции 128—159 здесь заняты разными полезными типографскими символами. Большинство браузеров не различают ISO-8859-1 и Windows-1252 — фактически, и в том, и в другом случае они отображают текст как Windows-1252.
Такая путаница между этими двумя кодировками привела к тому, что многие программы, генерирующие файлы HTML, ошибочно обозначали символы их кодами из Windows−1252 вместо кодов Юникода (исходя из того, что номер символа в ISO-8859-1 равен его номеру в Юникоде): например, тире (—) обозначалось — вместо правильного —, многоточие обозначалось … вместо правильного … и т. д.; из-за распространённости этого явления современные браузеры продолжают показывать, например, — как тире, хотя на самом деле — — это управляющий символ «end of guarded area», применение которого в HTML бессмысленно.
В проекте стандарта HTML 5 предписывается показывать ISO-8859-1 как Windows-1252.[1]

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

Не вижу тут проблем, такие API давно уже есть: для того, чтобы пользоваться без значительных трудностей C, достаточно программировать на C. Насчет ассемблера, конечно, не все так радужно, но ассемблер в принципе категорически противопоказан тем, кто боится трудностей.

Вот годный пример: WinAPI. Так-то он есть, но вот эффективно им пользоваться сложно, моё мнение: ОС должна предоставлять возможность широкого набора системных вызовов, в том числе и для создания пользовательского интерфейса. Но, тут нюансы начинаются с простейших функций, например, открытия и закрытия файла. В некотором смысле Linux ушёл дальше, но X Window System. Нет, понятно, что это разрабатывалось для поддержки многопользовательского доступа через терминал, но только такие решения не представляют практического интереса - теперь уже факт - компьютеры стали дешёвыми.

Что касается C# - это совершенно другая экосистема, и для своей области применения он действительно чертовски хорош (в сочетании с .NET, разумеется).

Как сказать, сама идея управляемого кода, когда за выделением и освобождением памяти следит не программа, а система хороша, также создание виртуальной машины под разные архитектуры тоже как бы интересно. А итог: само по себе медленно, чтобы сделать быстро и не размещать данные в области управляемой памяти придуманы нюансы в языке... В общем-то, если взять инструменты, вроде Qt и перекомпилировать проект под нужную платформу - тоже выходит не плохо. Я считаю, что решения в виде c# - политика более, чем наука. Имхо, естественно, может я и не прав.