Здравствуйте, alex_public, Вы писали:
_>Ничего подобного, как раз с библиотекой языка всё нормально. И даже Boost (особенно шаблонные игрушки, которые не тратят итоговые ресурсы) вполне можно применять. А вот функций ОС нет никаких. Соответственно задача в чём-то похожа на написание своего драйвера сетевой карты в ОС, плюс реализации стека TCP/IP и плюс уже прикладная мелочь в виде собственно некого сервиса на базе всего этого. Ну и всё это должно укладываться в узкие рамки возможностей МК (30КБ памяти и всё такое). Уверен, что справишься? )))
Может я и ошибаюсь, но в 30кб нельзя запихнуть полноценный стек TCP/IP даже на ассемблере. То есть, мы берем хорошую вещь и обрубаем от нее все, что можно, огрызком гордимся. За это и платят, за впихивание невпихуемого, сжатие с потерями.
Как это сделано, по моему мнению, что реализовано на самом деле:
1) ARP и RARP.
2) DHCP, чтобы просто получить адрес и как-то о себе заявить.
3) UDP, чтобы принимать команды "включись-выключись", никакой гарантированной доставки нет.
4) Взаимодействие с WiFi-чипом.
5) Хранение конфигурации.
Все это скорее всего сделано в виде цикла с разлапистым switch внутри и аналогом HLT в начале цикла. Плюс, это же мелкий дешевый чип, который может начать сходить с ума от того, что рядом с ним в розетку включили фен. То есть, какие-то watchdog'и и взаимодействие с ними в коде, вот этого я не трогал вообще, только предполагаю.
_>Что-то я не понял твоей аналогии) Так рутина по твоему в Ворде или в Техе будет? )
Высокий уровень Ворда позволит тупому Васе качественно делать рутинную работу. Ворд, соответственно — хорош, и создан с правильным посылом — облегчать работу, делать ее доступной.
С>>И если везде — в базах, в гуе, в вебе, везде инструменты делают разработку проще, знания накапливаются и выдаются в виде чего-то позволяющего с меньшим трудом достигать результата. Но в embedded обязательно будет Вася-умелец в свитере, с паяльником и горой Си-кода даже не в репозе. Вася — золотые руки. Не происходит передачи знаний в инструменты, а только в чьи-то золотые руки, которыми обладатель умело обтачивает очередную блоху.
_>Это откуда такая информация? )
Из наблюдений за электронщиками. Я не говорю, что они делают ерунду какую-то, я говорю, что сама их отрасль, инструменты, созданы как-то так, чтобы не пустить посторонних. В противоположность Ворду. Отличная job security, и стагнация в общем.
_>Да, область неоднозначная. ) Но как раз на неё сейчас перемещается основной фокус развития в IT. )
Я надеялся, что вы расскажете, каким образом можно пройти путь к хорошо оплачиваемому эмбеду.
Здравствуйте, hi_octane, Вы писали:
_>>Вот если уж кому-то и говорить на эту тему, то уж точно не .Net, у которого GUI фреймворк вообще встроен в саму платформу и соответственно реальной конкуренции нет вообще от рождения. _>Плохо представляешь ситуацию. Из мира .NET поднимаются такие вещи как например Noesis GUI, который XAML, на GPU, кроссплатформенный до потери пульса и C# (и даже C++). В общем не будет MS развивать WPF — это сделают другие, и заменят XAML на что-нить нормальное идея-то хорошая.
О, действительно интересная вещь. Отложил в закладки и буду внимательно изучать детали в ближайшее время. Спасибо за информацию!
Единственное что не понятно, это причём тут Noesis GUI и .Net? ) Возможность использовать из .Net'a есть и у Qt и у wxWidgets и у многих других. Но это не делает их .Net продуктами. )
Здравствуйте, koandrew, Вы писали:
K>И много ты стеков уже написал? Они уже давным-давно есть готовые под все популярные чипы, и поддерживаются часто самими производителями чипов.
Ну естественно, что нормальные специалисты стараются максимально использовать готовые библиотеки. Но тут речь не об этом, а том, что это всё в любом случае будет являться частью твоего приложение (а не частью ОС или чем-то подобным), которое надо будет втискивать в необходимые рамки и т.п.
Здравствуйте, Слава, Вы писали:
С>То, что для веба до сих требуется какой-то "верстальщик", а.к.а. "Дядя Вася с золотыми руками", об аналоге которого я писал уже выше, показывает кривизну технологии. До сих пор для страничек нет нормального WYSIWYG-редактора.
Нуу на самом деле то для отдельных страничек давно есть. А нет для целых сайтов. Точнее и для сайтов есть (в админке какого-нибудь WordPress/Joomla/Drupal), но только для построенных по старому принципу. А вот для современных сайтов (которые статичный html+js с ajax) ничего подобного нет и каждый сайт колбасят каждый раз по новому (и частенько каждый раз с разным фреймворком, т.к. мода там часто меняется ).
Здравствуйте, Слава, Вы писали:
_>>видео-поток по закрытому протоколу (т.е. не http и не h.264) и выводить его на экран без малейших задержек. С>"Очень любит наш народ всякое говно" ((с) Шнуров) С>Есть общепринятые протоколы. Нет же, надо изобрести чего-то своё, байтики погрызть, buffer overrun словить. Арена цирка, на ней выступают два старых клоуна-алгоритмиста, сейчас они вам покажут — крррр-чпокЪ! Вуаля! Закрытый видеопротокол! Свой, собственный, топором и без единого гвоздя! Импортозамещение.
А с чего ты взял, что какой-то из общепринятых протоколов подходит для решения задачи? )
Здравствуйте, TK, Вы писали:
TK>Да не для людей оно. нода это тупо один экзешник который достаточно тупо скачать и можно использовать. Где такое для .net core?
Здравствуйте, Слава, Вы писали:
С>Может я и ошибаюсь, но в 30кб нельзя запихнуть полноценный стек TCP/IP даже на ассемблере. То есть, мы берем хорошую вещь и обрубаем от нее все, что можно, огрызком гордимся. За это и платят, за впихивание невпихуемого, сжатие с потерями. С>Как это сделано, по моему мнению, что реализовано на самом деле: С>1) ARP и RARP. С>2) DHCP, чтобы просто получить адрес и как-то о себе заявить. С>3) UDP, чтобы принимать команды "включись-выключись", никакой гарантированной доставки нет. С>4) Взаимодействие с WiFi-чипом. С>5) Хранение конфигурации. С>Все это скорее всего сделано в виде цикла с разлапистым switch внутри и аналогом HLT в начале цикла. Плюс, это же мелкий дешевый чип, который может начать сходить с ума от того, что рядом с ним в розетку включили фен. То есть, какие-то watchdog'и и взаимодействие с ними в коде, вот этого я не трогал вообще, только предполагаю.
Направление верное, но реализация как раз на уровне "Вася-умелец". ) А по нормальному чаще всего возьмут что-то вроде протокола MQTT. Там и сам протокол помощнее и есть готовые библиотечные реализации под многие чипы. )
_>>Что-то я не понял твоей аналогии) Так рутина по твоему в Ворде или в Техе будет? ) С>Высокий уровень Ворда позволит тупому Васе качественно делать рутинную работу. Ворд, соответственно — хорош, и создан с правильным посылом — облегчать работу, делать ее доступной.
Специализация TeX — это работа с формулами и т.п. И в этой области он удобнее Ворда и для новичка и для профессионала. )
_>>Это откуда такая информация? ) С>Из наблюдений за электронщиками. Я не говорю, что они делают ерунду какую-то, я говорю, что сама их отрасль, инструменты, созданы как-то так, чтобы не пустить посторонних. В противоположность Ворду. Отличная job security, и стагнация в общем.
Ну вот например те же Ардуинки как раз созданы с противоположной целью — позволяют любому веб-дизайнеры писать практически без подготовки создавать умные устройства с прошивками (мигать светодиодами ).
_>>Да, область неоднозначная. ) Но как раз на неё сейчас перемещается основной фокус развития в IT. ) С>Я надеялся, что вы расскажете, каким образом можно пройти путь к хорошо оплачиваемому эмбеду.
Я как бы не совсем с той стороны... ) Я больше охочусь за информацией, как достать настоящих профессионалов, готовых работать за интерес. )))
Здравствуйте, alex_public, Вы писали:
_>Ну естественно, что нормальные специалисты стараются максимально использовать готовые библиотеки. Но тут речь не об этом, а том, что это всё в любом случае будет являться частью твоего приложение (а не частью ОС или чем-то подобным), которое надо будет втискивать в необходимые рамки и т.п.
То, что они будут частью твоего приложения, ничего не меняет с точки зрения программирования — ты точно так же зовёшь уже написанные кем-то функции, исходя из их описания в документации. Какая программисту разница, шиппятся эти функции с ОС, реализованы в железе, или какой-то промежуточный вариант? Ну разве что отъест немного флеша. хотя сейчас появляется всё больше чипов, которые представляют из себя "чёрные ящики" с уже реализованным стеком TCP/IP, некоторыми транспортными протоколами, а также PHY и MAC на одном чипе (пример — WINC1500 от Atmel, CC3XX0 от TI). А данном случае стек реализовывать нет необходимости вообще, и потому "драйвер" для таких девайсов получается очень маленьким — т.к. он по сути только перенаправляет вызовы в этот "чёрный ящик", что позволяет использовать данные чипы совместно с очень простыми и дешёвыми МК (полный драйвер для WINC1500 вроде всего 4к — такой даже в те же AVRки влезет без особых проблем, а его ещё можно и обрезать, убрав ненужные функции).
Короче, мой поинт в том, что писать эти стеки самому нафиг не нужно, за редчайшими исключениями вроде роутеров и прочего высокоскоростного сетевого оборудования. Да и для этих случаев имеются готовые решения
Здравствуйте, koandrew, Вы писали:
_>>Ну естественно, что нормальные специалисты стараются максимально использовать готовые библиотеки. Но тут речь не об этом, а том, что это всё в любом случае будет являться частью твоего приложение (а не частью ОС или чем-то подобным), которое надо будет втискивать в необходимые рамки и т.п. K>То, что они будут частью твоего приложения, ничего не меняет с точки зрения программирования — ты точно так же зовёшь уже написанные кем-то функции, исходя из их описания в документации. Какая программисту разница, шиппятся эти функции с ОС, реализованы в железе, или какой-то промежуточный вариант?
Нуу как тебе сказать... ) Вот Шеридан тут конечно всех убеждает, что инсталляция и работа с Генту ничуть не менее удобна чем с Виндой. Но пока мало кого убедил. )))
K>Ну разве что отъест немного флеша.
Не только. Ещё и оперативки и собственно ресурсов процессора. Там далеко не всё так просто. Организация взрослых протоколов — это уже не просто помигать светодиодами. )
K>хотя сейчас появляется всё больше чипов, которые представляют из себя "чёрные ящики" с уже реализованным стеком TCP/IP, некоторыми транспортными протоколами, а также PHY и MAC на одном чипе (пример — WINC1500 от Atmel, CC3XX0 от TI). А данном случае стек реализовывать нет необходимости вообще, и потому "драйвер" для таких девайсов получается очень маленьким — т.к. он по сути только перенаправляет вызовы в этот "чёрный ящик", что позволяет использовать данные чипы совместно с очень простыми и дешёвыми МК (полный драйвер для WINC1500 вроде всего 4к — такой даже в те же AVRки влезет без особых проблем, а его ещё можно и обрезать, убрав ненужные функции).
Для данного направления IoT сейчас все используют чип ESP8266. ) И там в поставляемом SDK естественно имеется библиотека работы с wifi из их чипа. Но это всё равно не имеет ничего общего с привычной работой с сетью в ОС. Разве что тебе повезёт и ты сможешь использовать в своём проекте какой-то сильно популярный протокол, имеющий готовую реализацию именно под этот процессор. Ну что-нибудь типа такого https://github.com/tuanpmt/esp_mqtt. Тогда да, разработка сетевой части будет не сложной. Но ты же понимаешь, что это я описал самый идеальный случай и так везёт довольно редко? )
K>Короче, мой поинт в том, что писать эти стеки самому нафиг не нужно, за редчайшими исключениями вроде роутеров и прочего высокоскоростного сетевого оборудования. Да и для этих случаев имеются готовые решения
Писать прямо вот весь код руками — не надо. Реализовывать стек (возможно с помощью каких-то готовых исходников) — надо.
Здравствуйте, alex_public, Вы писали:
_>Нуу как тебе сказать... ) Вот Шеридан тут конечно всех убеждает, что инсталляция и работа с Генту ничуть не менее удобна чем с Виндой. Но пока мало кого убедил. )))
Некорректное сравнение. Надеюсь не нужно объяснять почему?
_>Не только. Ещё и оперативки и собственно ресурсов процессора. Там далеко не всё так просто. Организация взрослых протоколов — это уже не просто помигать светодиодами. )
Смотря о каком протоколе речь.
_>Для данного направления IoT сейчас все используют чип ESP8266. ) И там в поставляемом SDK естественно имеется библиотека работы с wifi из их чипа.
Он не очень стабильный — теряет коннект с сетью, да и с шифрованными сетями по слухам там не всё хорошо. Ну правда и стоит он сущие копейки — короче, сколько заплатишь — на столько и получишь
_>Но это всё равно не имеет ничего общего с привычной работой с сетью в ОС.
Что такое "привычная работа с сетью"? BSD Sockets чтоли? Дык тот же WINC имеет их реализацию.
_>Разве что тебе повезёт и ты сможешь использовать в своём проекте какой-то сильно популярный протокол, имеющий готовую реализацию именно под этот процессор. Ну что-нибудь типа такого https://github.com/tuanpmt/esp_mqtt. Тогда да, разработка сетевой части будет не сложной. Но ты же понимаешь, что это я описал самый идеальный случай и так везёт довольно редко? )
TCP/UDP имеются под все чипы, которые только мне попадались на глаза (я как раз недавно выбирал WiFi-чип для своего "умного дома"). Но само собой разумеется, что эти чипы не рассчитаны на высоконугруженные приложения — в WINC1500 десяток чтоли сокетов можно держать открытыми. Для типичных IoT-применений (и даже простых серверных) этого за глаза и за уши, но если нужна высокая нагрузка и высокая скорость, то конечно нужно брать MAC/PHY и руками педалить стек. Но это уже совсем другой уровень задач, и для них ИМХО целесообразнее применять либо FPGA, либо "взрослые" процы типа А-серии АРМов.
_>Писать прямо вот весь код руками — не надо. Реализовывать стек (возможно с помощью каких-то готовых исходников) — надо.
Здравствуйте, Слава, Вы писали:
С>Флэш помер, конечно, а вот инерция разработчиков осталась. Вставляем ролик ютуба в сообщение здесь — видим, мать его, флэш. Вставляем coub в комментарий фейсбука — опять флэш.
Здравствуйте, Слава, Вы писали:
I>>Это с нуля делается за день два одним верстальщиком. Ты ждёшь чудес каких то.
С>То, что для веба до сих требуется какой-то "верстальщик", а.к.а. "Дядя Вася с золотыми руками", об аналоге которого я писал уже выше, показывает кривизну технологии.
Это особенность технологии — стили отдельно от контента. Вот и нужны верстальщики.
>До сих пор для страничек нет нормального WYSIWYG-редактора.
И не нужен этот визивиг. Его даже для мега убер успешных нативных технологий родить не смогли за 20 лет. Почем для веба это должно произойти быстрее ?
Ты что, собираешься визивигом выполнять аджакс запросы, визуализировать сложную логику, обработку данных, аутентификацию ? Цырк на дроце.
Здравствуйте, alex_public, Вы писали:
I>>Враньё. Ты изобрел новый термин для одностраничных приложений. PHP только в твоём мирке работает внутри браузера.
_>Эм, расшифруй этот свой бессвязный поток слов. Непонятно, что хотел сказать. )
Ты выдумал проблему и решение. В мире динамического серверного хтмл ни одна из проблем толком не решена.
Собтсвенно рендеринг хтмл на клиенте именно потому и появился, что серверный тупо слился.
I>>И давно PHP работает на мобиле, дестокпе и внутри браузера ?
_>Второй подход современнее и очевидно выгоднее с точки зрения нагрузки на сервер и на сеть. Однако при этом если работать в рамках первого подхода, то к твоим услугам множество удобных инструментов, позволяющих создать нормальный сайт за час (подразумевается, что контент у нас готов).
Сайт — можно. Веб-приложение — уже нельзя. По факту сейчас все странички становятся потиху приложениями.
Гарантировать время отклика — нет. Пропускную способность — тоже нет.
_>Да, со временем (после доработки оптимизации в браузерах и написание соответствующих удобных js библиотек) html5+js естественно дорастёт (а с webassembly может и перерастёт) до уровня Flash, так что когда-нибудь тот действительно умрёт. Но пока ещё рано говорить об этом. )
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
I>>Итак — где примеры мега-форумов с заявленым функционалом, реализованых на QT ?
_>Причём тут форумы и Qt? ) Qt не является фреймворком по созданию сайтов. Он тут приведён всего лишь как пример того, что в области нативных GUI фреймворков имеется общеизвестный лидер.
То есть,в нише размером с игольное ушко нашелся лидер. И что ?
>В отличие соответствующей области JS фреймворков, у которых не то что лидера, а даже хотя бы одного комплексного решения не видно. )
Так и должно быть. Веб это больше когда,функционала, приложений, чем во всем десктопе во все времена на всех платформах.
I>>Покажи десяток форумов на QT, а потом будем сравнивать сравнимое. Веб UI как раз взлетел, потому что нативный UI слился.
_>До тебя похоже совсем не доходит. Я привёл пример нативной разработки GUI не как конкурента веб-технологиям, а как близкий пример нормальной индустрии со сформировавшимися лидерами и т.п. В отличие от бардака, который творится в мире JS.
Нету там ничего нормально. Три с половиной основных игрока.
_>И ты так и не ответил на вопрос, что мне может предложить мир клиентского JS для помощи в создание сайта.
Я тебе про приложения, а ты мне про сайты. JS позволяет не меньше, чем твой любимый QT.
_>Вот мир PHP может предложить готовые комплексные решения.
Сайтов, убогих и проблемных, и никак не приложений.
Здравствуйте, kr510, Вы писали:
K>В сравнении с MFC у Qt есть несколько преимуществ: большой набор Widgets и ник как из Лего блоков можно собирать; Qt котролы удобно стайлить.
Надо полагать именно по этому около нуля приложений под винду пишется на этом QT ?
Здравствуйте, alex_public, Вы писали:
_>Плюс набор разных контролов (разные отметки, поля вывода, кнопки) поверх этого видео. Плюс несколько диалогов разных опций. Вот такой в общем то простенький GUI. На том же Qt реализуется элементарно.
А GUI еще проще — табличка с текстом да кнопками никак не реализуется. Это я про форум.
_>Так какую конкретно из веб-технологий ты мне предложишь для реализации данного простенького GUI? )
Давай начнем что попроще, с таблички с текстом. Но ты, впрочем, уже слился.
Здравствуйте, koandrew, Вы писали:
_>>Нуу как тебе сказать... ) Вот Шеридан тут конечно всех убеждает, что инсталляция и работа с Генту ничуть не менее удобна чем с Виндой. Но пока мало кого убедил. ))) K>Некорректное сравнение. Надеюсь не нужно объяснять почему?
Конечно некорректное, т.к. с Генту ещё намного проще, т.к. она умеет самоконфигурироваться. А в случае разных библиотек разработчик должен руками конфигурировать их под свой проект, своё железо и т.п.
_>>Для данного направления IoT сейчас все используют чип ESP8266. ) И там в поставляемом SDK естественно имеется библиотека работы с wifi из их чипа. K>Он не очень стабильный — теряет коннект с сетью, да и с шифрованными сетями по слухам там не всё хорошо. Ну правда и стоит он сущие копейки — короче, сколько заплатишь — на столько и получишь
Ну так в цене и дело. Если устройство типа светодиодной лампы будет стоить много тысяч рублей, то его никто не купит. )
K>TCP/UDP имеются под все чипы, которые только мне попадались на глаза (я как раз недавно выбирал WiFi-чип для своего "умного дома"). Но само собой разумеется, что эти чипы не рассчитаны на высоконугруженные приложения — в WINC1500 десяток чтоли сокетов можно держать открытыми. Для типичных IoT-применений (и даже простых серверных) этого за глаза и за уши, но если нужна высокая нагрузка и высокая скорость, то конечно нужно брать MAC/PHY и руками педалить стек. Но это уже совсем другой уровень задач, и для них ИМХО целесообразнее применять либо FPGA, либо "взрослые" процы типа А-серии АРМов.
Кстати, а почему ты решил использовать именно wifi для умного дома? ) Понятно почему его ставят в подобные одиночные продукты (главная проблема всех современных технологий в этой области — отсутствие каких-либо стандартов взаимодействия). Но если ты сам делаешь все компоненты, то ты полностью свободен в выборе.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, kr510, Вы писали:
K>>В сравнении с MFC у Qt есть несколько преимуществ: большой набор Widgets и ник как из Лего блоков можно собирать; Qt котролы удобно стайлить.
I>Надо полагать именно по этому около нуля приложений под винду пишется на этом QT ?
Откуда данные?
Из примеров на Qt — Notepad++ Genymotion VirtualBox
Здравствуйте, Ikemefula, Вы писали:
_>>Эм, расшифруй этот свой бессвязный поток слов. Непонятно, что хотел сказать. ) I>Ты выдумал проблему и решение. В мире динамического серверного хтмл ни одна из проблем толком не решена. I>Собтсвенно рендеринг хтмл на клиенте именно потому и появился, что серверный тупо слился.
https://ru.wikipedia.org/wiki/WordPress#.D0.98.D0.BD.D1.82.D0.B5.D1.80.D0.B5.D1.81.D0.BD.D1.8B.D0.B5_.D1.84.D0.B0.D0.BA.D1.82.D1.8B Ну да, ну да. )))
_>>Второй подход современнее и очевидно выгоднее с точки зрения нагрузки на сервер и на сеть. Однако при этом если работать в рамках первого подхода, то к твоим услугам множество удобных инструментов, позволяющих создать нормальный сайт за час (подразумевается, что контент у нас готов). I>Сайт — можно. Веб-приложение — уже нельзя. По факту сейчас все странички становятся потиху приложениями. I>Гарантировать время отклика — нет. Пропускную способность — тоже нет.
Так о том и речь. Где инструменты позволяющие например одним кликом добавить меню в своё веб-приложение? )
P.S. Кстати, насчёт пропускной способности и т.п. — это актуально только для сайтов с большим количеством динамики. А при малом количестве динамики тоже имеются готовые инструменты: https://habrahabr.ru/company/selectel/blog/236441/. Но JS оказывается и тут не у дел...
Здравствуйте, alex_public, Вы писали:
НС>>Их там даже несколько. _>Ага, вводимые последовательно, один на замену другого.
Не всегда. И концепция периодически меняется.
_>>> и соответственно реальной конкуренции нет вообще от рождения. НС>>GTK# и биндинг к Qt там есть. _>Да, слышал про такое. ) Интересно, хоть кто-то пользуется этим?
GTK# пока единственный кроссплатформенный вариант промышленного качества.
_>Но к конкуренции и выявлению реального лидера на рынке это отношения точно не имеет — тут всё прописано заранее. )))
Как сказать. Особенно с учетом появления .Net Core.
.NET вырос в большую и сложную платформу с кучей всего, так что не упрощай.
Они уже давным-давно есть готовые под все популярные чипы, и поддерживаются часто самими производителями чипов.
).
