[AHTOXA 15]

Вот, говорите, "сложные программы". А я вчера на баг opencm3 в делении на STM32F0 наткнулся. Полдня пытался понять, почему виснет МК, пока не выловил, где именно он виснет.

Надеюсь, баг-репорт отправили? Ссылочку можно?

Буду теперь свой "фреймворк" собирать, раз уж ничего нормального под STM'овские микроконтроллеры в природе не существует ☹

Да, конечно. Уж свой-то "фреймворк" точно будет без единого бага:)

[Eddy_Em 1]

Надеюсь, баг-репорт отправили?

Нет, конечно. Какой смысл отправлять баг-репорт версии, которая 1.5-2 года назад устарела? По-моему, они там уже все баги с F0 позакрывали, т.к. видел там недавно довольно длинный список баг-репортов и пулл-риквестов, который почти полностью был закрыт.

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

Я выбираю второй вариант.

Да, конечно. Уж свой-то "фреймворк" точно будет без единого бага:)

В своем проще: никому пулл-риквесты слать не надо. Просто закрыл баг, и сделал коммит.

[AlexandrY 3]

Расскажите, пожалуйста, по-подробнее про фреймворки. Ваш код для гирлянды (geektimes) можно считать фреймворком? Потому, что я его на днях скачал, по-маленьку изучаю ваш подход. Ибо стало интересно :rolleyes:

Да, это часть фреймворка.

Не самая большая.

 

Главное в нём RTOS с промежуточным софтом.

Главное в RTOS - это отладочные возможности и диагностика.

Главное в отладке - это разнообразие и быстрота отладочных каналов и инструментов анализа на PC.

Поэтому у меня в обязаловку всегда есть либо UART со скоростью не менее 1,5 Мбита в сек, либо USB FS/HS с не менее чем с 2-я виртуальными COM портами, либо Ethernet, либо канал RTT через SWD.

В директории VT100 у меня расположен монитор VT100 с псевдографическим меню.

Этот монитор работает через драйвера и он многозадачный.

Т.е. в одном терминале через com порт можно открыть один монитор , в другом окне терминала через другой com порт открыть другой монитор, и еще через интернет telnet открыть третиий и т.д.

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

И это только один из путей или одна из технологий отладки имеющаяся в моем фреймворке.

 

В проекте гирлянды все это присутствует, но частично не задействовано.

В следующем проекте унивесального модуля управления мотором с гирляндой будет более расширенный вариант использования отладки и кстати с выводом в Matlab.

 

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

Имея развитую отладку баги не накапливаются, соответственно не надо хранить о них никакой информации.

А контроль версий у меня играет роль исключительно бэкапа да и то не для всего, а только для проектов ПО.

[Eddy_Em 1]

AlexandrY, почем матлаб брали? Академическая версия или полноценная?

Интересно просто, во сколько обойдется удовольствие сменить octave на матлаб (пока, правда, не возникало никаких задач, требующих именно матлаба, но есть кое-какие прелести в wavelet-тулбоксе, аналог которому я полгода писать буду, и симулинке). У нас лет 15 назад пара человек даже нарисовали в матлабе свой фреймворк для обработки спектров, да забили на это дело и перешли в более удобный IDL.

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

[haker_fox 61]

раз уж ничего нормального под STM'овские микроконтроллеры в природе не существует ☹

Ну да. есть там ошибки. Я их правил тоже. Правда не то, чтобы ошибки. Скорее функционал наращивал. А затем оборачивал в классы на Си++) Это же бесплатно, чего требовать?

 

И это только один из путей или одна из технологий отладки имеющаяся в моем фреймворке.

Вас понял! Спасибо! Очень интересно!

[mantech 48]

В этом-то как раз Эдди прав. Только поменьше бы экспрессии :)

Цитата(Укушенный воблой @ Jan 15 2017, 12:31)

Понятно.

"Мышка для лохов, а правильные пацаны юзают командную строку".

Вопросов больше не имею.

В этом-то как раз Эдди прав. Только поменьше бы экспрессии :)

Ну, и какому клиенту вы продадите железку с "чиста-канкретной" командной строкой?? Лет надцать назад может кто-нибудь и купился бы, но сейчас...

l

Производительность труда в CLI намного выше, чем в GUI. Если кто-то думает иначе, он просто никогда не работал в командной строке.

Элементарный конвейер из sed, grep, awk и т.п. заменяет уйму GUIшных тормозных утилит.

Вам не кажется, что еслиб было так, то 90% техники сегодня было б не с гуем, а командной строкой?? Подумайте еще раз, создается впечатление, что вы живете в своем мире конца 80х на XT или AT286. :laughing:

ЗЫ. Кстати, в так вам ненавистной винде командная строка тоже есть и сам иногда пользуюсь ей и bat-файлами...

[Укушенный воблой 0]

:maniac:

Тема свелась в холивару ртос\не ртом гуй/не гуй.

А про, собственно, ГЛАВНУЮ причину сложности (так сказать, "источник сложности") все забыли

Изменено 16 января, 2017 пользователем Укушенный воблой

[backend 0]

В том числе. Такими телефонами и пользуюсь, не понимаю, как народ вместо телефона планшет карманный таскает.

Перепробовал разные варианты. Скольки-то там ядерный смартфон лежит без дела, а компактный джавафон прижился.

 

Производительность труда в CLI намного выше, чем в GUI. Если кто-то думает иначе, он просто никогда не работал в командной строке.

Элементарный конвейер из sed, grep, awk и т.п. заменяет уйму GUIшных тормозных утилит.

Соглашусь. Единожды попробовав и ощутив неограниченные возможности CLI, сложно заставить себя перестроиться на GUI.

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

 

Ну, и какому клиенту вы продадите железку с "чиста-канкретной" командной строкой?? Лет надцать назад может кто-нибудь и купился бы, но сейчас...

Ну я продавал. Человеку было нужно, через конфиг-файлы у меня все было готово, GUI front-end городить долго и дороже. Заказчика устроил мой вариант.

 

Вам не кажется, что еслиб было так, то 90% техники сегодня было б не с гуем, а командной строкой??

Думаю, 90% пользователей GUI в силу разных обстоятельств даже не пытались серьезно работать в командной строке и сравнивать производительности CLI и GUI.

 

ЗЫ. Кстати, в так вам ненавистной винде командная строка тоже есть и сам иногда пользуюсь ей и bat-файлами...

BAT-файлы, конечно, вещь, но с командной строкой NIX-систем это сравнить невозможно.

 

 

[mantech 48]

:maniac:

Тема свелась в холивару ртос\не ртом гуй/не гуй.

А про, собственно, ГЛАВНУЮ причину сложности (так сказать, "источник сложности") все забыли

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

Сам мользуюсь всеми тремя способами, в зависимости от ситуации...

Думаю, 90% пользователей GUI в силу разных обстоятельств даже не пытались серьезно работать в командной строке

И самое главное - даже и не будут пытаться..

ЗЫ. какая командная строка, если сейчас тенденция программы "писать" путем тыканья в кнопки и "галочки", вот уж где я не согласен с гуем, так это в программировании, ибо создать граф. форму и растыкать виджеты мышкой - это удобно, но программу писать - это уж клавиатура и текстовый редактор, конечно, с подсветкой синтаксиса, разумеется.. B)

[Eddy_Em 1]

А про, собственно, ГЛАВНУЮ причину сложности (так сказать, "источник сложности") все забыли

Главная причина сложности любой программы — сам программист, который пытается из нее невесть что универсальное сделать. Вторичной причиной являются пользователи, которых, как мы уже пришли к выводу, априори считают идиотами (и оно недалеко от этого), из-за чего приходится все четырежды перепроверять и делать мегазащиту от дурака. И все равно на каждую хитрую ж...

 

Вот поэтому если делать только для своего потребления, получается довольно просто: ни с GUI не надо заморачиваться, ни документацию бешеную писать. Да даже можно баги не исправлять, зная о них.

 

P.S. Насчет GUI я уже последние лет 5-6 использую веб-морды для всего и вся (в рамках разумного, конечно; если через веб-морду нельзя, делаю какой-нибудь элементарный просмотрщик картинок на openGL или устраиваю конвейер). Повсеместная поддержка браузерами вебсокетов добавила удобства: теперь запросы воистину стали асинхронными и нет нужды чрезмерно нагружать линию поллингами по 10-30 раз в секунду! Остается только проблема с трансляцией видео: НЯЗ, до сих пор ничего, кроме mjpeg'ов (а то и вообще обновления картинки по таймеру), не придумали. Я пробовал через вебсокеты работать — очень медленно получается, т.к. нужно в base64 изображение передавать и жабоскриптом декодировать.

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

[Гость TSerg]

>Главная причина сложности любой программы — сам программист, который пытается из нее невесть что >универсальное сделать.

 

Вы давно из песочницы вылезли? Полагаю, что и не вылезали.

 

Программа - это данные + алгоритмы, как сказал классик.

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

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

 

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

 

Физические параметры какой-либо сущности "живут" без участия какого-либо программиста, математика, физика.

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

 

Оч. простая реализация алгоритма X на java - из нумерологии.

Сообразите, что да как:

 

Arrays.fill(isP, true);

isP[1] = false;

for (int i=2; i*i < N; i++)

if (isP)

for (int j=i*i; j < N; j+=i)

isP[j] = false;

[Des333 0]

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

Вот это пять!

[haker_fox 61]

Ну я продавал. Человеку было нужно, через конфиг-файлы у меня все было готово, GUI front-end городить долго и дороже. Заказчика устроил мой вариант.

Ну это же зависит только от того, какую продукцию вы производите :rolleyes: Сложно представить себе мультиметр, логический анализатор или осциллограф без GUI, а только лишь с командной строкой. С другой стороны конфигурировать линукс через граф интерфейс действительно не очень производительно.

 

ибо создать граф. форму и растыкать виджеты мышкой - это удобно

Нет! :rolleyes: Здесь как раз тоже удобно форму описать, используя API графической библиотеки. Это оперативнее по той же причине, которую вы назвали выше, говоря о командной строке.

[Eddy_Em 1]

Сложно представить себе мультиметр, логический анализатор или осциллограф без GUI

А пайпы на что? Зачем мучиться с gui, если можно через пайп в gnuplot данные передавать? И будет наглядное отображение. Аналогично с логанализатором: сохраняем данные в файл, потом требующийся кусок рисуем гнуплотом, а на выход выдаем анализ по соответствующему протоколу.

 

GUI на все случаи жизни — неправильный подход. Неюниксвейный. UNIX-way — это одна утилита под одну задачу. Объединяем толпу утилит в конвейер, и получаем счастье. Мелкомягкие же придумали плодить сущности. В итоге в каждой программе свой GUI, своя проверка правописания, своя подсветка синтаксиса, свои виджетобиблиотеки и т.д., и т.п.

[syoma 1]

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

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

Физические параметры какой-либо сущности "живут" без участия какого-либо программиста, математика, физика.

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

 

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

 

Оч. простая реализация алгоритма X на java - из нумерологии.

Сообразите, что да как:

 

Arrays.fill(isP, true);

isP[1] = false;

for (int i=2; i*i < N; i++)

if (isP)

for (int j=i*i; j < N; j+=i)

isP[j] = false;

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