Вопросы по С/С++ (СИ)
- Сообщения: 2567
- Зарегистрирован: Вт май 01, 2018 19:44:47
Неудобно. При системном подходе сначала продумывается функционал устройства, затем пишется протокол, затем его реализация на обоих сторонах. Без всяких CLI и текстовых форматов. Первое не удобно пользователю, второе лишние ресурсы микроконтроллера. С современными средствами разработки накидать GUI дело десятка минут.
- Реклама
Eddy_Em, Во-первых, я просил
Затем по этой ссылке я с удивлением обнаруживаю GUI с кнопками и слайдерами, вместо ожидаемого скриншота Lynx. Вы сделали то, что так ненавидете? Где там CLI? )))
А здесь вообще взрыв мозга. С одной стороны, в проекте вижу CGI, а с другой:
стал приходить поток из бинарных 20-ти байтных блоков на каждое ПУ. А так как его не только передавать, но и парсить на порядок быстрее, то отчет по Тульской области формировался уже через час после начала сбора показаний с концентраторов, а не на следующий день, как до этого.
Не забывайте, что большинство концентраторов сидят на EDGE и отдают данные очень неторопливо.
Ни в одном из примеров по ссылке я этого не увидел. Так где он?ПростоНуб писал(а):Но мне очень интересно увидеть Ваш код на МК, который через UART и терминал умеет реагировать на горячие клавиши, не исключая при этом CLI в этом терминале, для регулировки яркости, скорости или еще чего. Какой именно терминал Ваш МК эмулирует?
Вместо этого, Вы даете ссылку на тупой код, генерирующий страницу раз в 15 минут.ПростоНуб писал(а):Пример страницы где? И что за демон? Самописный веб-сервер? И как Вам удалось прикрутить JS к Lynx? Дайте ссылку на Lynx с JS. Или же Вы используете какой-то другой CLI браузер?
Затем по этой ссылке я с удивлением обнаруживаю GUI с кнопками и слайдерами, вместо ожидаемого скриншота Lynx. Вы сделали то, что так ненавидете? Где там CLI? )))
А здесь вообще взрыв мозга. С одной стороны, в проекте вижу CGI, а с другой:
Потому и троллю Вас, что в каждом последующем Вашем сообщении вижу противоречия как с предыдущим, так и с известными мне истинами.Eddy_Em писал(а):CGI неудобны. Тем более, зачем они, когда есть вебсокеты?
Потому что сериализация удобней развесистой структуры данных. При этом, в подавляющем большинстве случаев, сериализация делается бинарной. Мне эта текстовая сериализация уже поперек горла стоит, когда в числах дробная часть отделяется то точкой, то запятой, а в датах то DD-MM-YY, то MM-DD-YY, то YY-MM-DD, причем часовой пояс для каждого источника приходилось хранить в отдельной таблице БД. И это вместо прозрачного ISO YYYY-MM-DDThh:mm±hh. Год с Россетями бодались, пока они не смирились и не перешли к компактной бинарной сериализации. В результате, вместо такой портянки размером свыше 400 байт на каждый ПУ:Eddy_Em писал(а): все разумные люди отказываются от бинарных форматов для работы с небольшими объемами данных, а сериализуют их?
Код: Выделить всё
<RESULT>
<DEVICE>
<ID>11489094229568</ID>
</DEVICE>
<DATA>
<INTERVALS>
<INTERVAL>
<DATETIME>2016-10-19 21:00:00.000</DATETIME>
<CHANNEL>
<ID>1</ID>
<VALUE>458.53</VALUE>
</CHANNEL>
<CHANNEL>
<ID>2</ID>
<VALUE>232.31</VALUE>
</CHANNEL>
</INTERVAL>
</INTERVALS>
</DATA>
</RESULT>
Не забывайте, что большинство концентраторов сидят на EDGE и отдают данные очень неторопливо.
[uquote="VladislavS",url="/forum/viewtopic.php?p=3708730#p3708730"]При системном подходе сначала продумывается функционал устройства, затем пишется протокол, затем его реализация на обоих сторонах.[/uquote]это все очень бла-ародно, но мы тут вроде все взрослые люди и знаем, как оно на самом деле бывает)
[uquote="VladislavS",url="/forum/viewtopic.php?p=3708730#p3708730"]Без всяких CLI и текстовых форматов.[/uquote]ай зависит от. Если предполагается, что конечный продукт телодвижений - железка или софтина - будут работать в составе некоей системы, а не сами по себе, то консольный интерфейс и текстовый обмен обычно предпочтительнее, чем один только гуй. Юниксвей, чоч. Графическую морду можно прилепить сверху над cli, пусть его пинает.
[uquote="VladislavS",url="/forum/viewtopic.php?p=3708730#p3708730"]Без всяких CLI и текстовых форматов.[/uquote]ай зависит от. Если предполагается, что конечный продукт телодвижений - железка или софтина - будут работать в составе некоей системы, а не сами по себе, то консольный интерфейс и текстовый обмен обычно предпочтительнее, чем один только гуй. Юниксвей, чоч. Графическую морду можно прилепить сверху над cli, пусть его пинает.
[uquote="arkhnchul",url="/forum/viewtopic.php?p=3708718#p3708718"]Надо, скажем, получить серию значений и построить график рядом с теоретическим, чтобы посмотреть, чо это девайс там наделал - что, копипастить из IDE выхлоп сообщений?[/uquote]
Нет, изучать GDB:
Нет, изучать GDB:
Код: Выделить всё
(gdb) watch var
(gdb) cond <watchpoint_number> var>=value
(gdb) set logging file <filename>
(gdb) set logging on
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3708736#p3708736"]Мне эта текстовая сериализация уже поперек горла стоит, когда в числах дробная часть отделяется то точкой, то запятой, а в датах то DD-MM-YY, то MM-DD-YY, то YY-MM-DD, причем часовой пояс для каждого источника приходилось хранить в отдельной таблице БД.[/uquote]это исключительно вопрос единообразия формата, а не его самого как такового. Бинарных представлений даты/времени я тоже каких только не видел. Целочисленный таймстамп в секундах, он же в миллисекундах, упакованная структура с годом/месяцем/днем/часом/минутой/секундой, то же в двоично-десятичном формате, то же с днем года вместо месяца и дня месяца, то же с фактическим часовым поясом, то же в GMT и с целевым часовым поясом, double прямиком из паскаля...
- Реклама
- Сообщения: 2567
- Зарегистрирован: Вт май 01, 2018 19:44:47
[uquote="arkhnchul",url="/forum/viewtopic.php?p=3708737#p3708737"]Если предполагается, что конечный продукт телодвижений - железка или софтина - будут работать в составе некоей системы, а не сами по себе, то консольный интерфейс и текстовый обмен обычно предпочтительнее, чем один только гуй.[/uquote]Гуй для пользователя. За ним может быть любой интерфейс. Но зачем железки будут между собой на птичьем языке разговаривать? Для них бинарный проще и естественней.
далеко не на любом.ПростоНуб писал(а):Понятно, что на любом МК есть JTAG или что-то подобное.
с чего вы начинали, мне неведомо. я же лишь сказал, что для своих поделок использую (если нужно) текстовый формат управления через UART при помощи терминальной программы. это, в частности, избавляет от необходимости одновременно с девайсом разрабатывать и GUI для его управления, поскольку управлять можно уже с первых строк кода прямо в терминале.ПростоНуб писал(а):С чего мы и начали вообще-то
да он-то стандартен, да вот без специальных утилит в него не влезешь... а терминал доступен всем, и не требует обучения.arkhnchul писал(а):Или, к примеру, modbus RTU - порядок бит стандартен.
вот и я об этомEddy_Em писал(а):Ну и, опять же, насчет отладки: пока я отлаживаю алгоритмы работы железяки, мне никакого резона нет клепать утилиту, парсящую бинарный поток данных. Проще открыть терминал и ручками писать туда команды, читая получаемые ответы. Далее железяка устаканивается, пишется утилита для работы с нею, а протокол так и остается текстовым - удобно же!
профессионалы... страшно далеки они от народа...ПростоНуб писал(а):Не забывайте, что большинство концентраторов сидят на EDGE и отдают данные очень неторопливо.
да. только отлаживать его сложнее. а железке пофиг - она не устает, может и вместо 1 байта 33 символа перемолотить, и не вспотеетVladislavS писал(а):Для них бинарный проще и естественней
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
arkhnchul, я в курсе что такое сериализация. Проблема в том, форматы данных в XML и JSON плохо стандартизированы и каждый лепит туда числа и даты по своему разумению. Точнее даже по региональным настройкам локальной системы, какие могут совсем не совпадать с региональными настройками удаленной системы. С бинарными форматами таких проблем не возникает, если оговорен порядок байтов в числах. Ну и два порядка выигрыша скорости передачи по EDGE - тоже не мало. Плавающей запятой там и в помине не было. Сами ПУ по жизни оперируют целыми числами. Просто показания отображаются в киловатт*часах, хотя внутри они в единицах, десятках или сотнях ватт*часов. Поэтому в бинарном формате и передавали целое в ватт*часах
- Сообщения: 2567
- Зарегистрирован: Вт май 01, 2018 19:44:47
[uquote="ARV",url="/forum/viewtopic.php?p=3708749#p3708749"]только отлаживать его сложнее[/uquote]Глупости. Посмотреть структуру с данными в отладчике как внутри МК, так и в ПК элементарно.
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3708754#p3708754"]Проблема в том, форматы данных в XML и JSON плохо стандартизированы и каждый лепит туда числа и даты по своему разумению.[/uquote]бинарные форматы передачи тоже не то чтобы в целом стантартизированы. Только в пределах одного конкретного протокола.
больше двух. и почти все со связью с ПК.ПростоНуб писал(а):То есть у Вас за всю жизнь есть только два проекта на МК? Или все же больше, но только для двух из них связь с ПК требуется?
естественно, у меня в бинарном виде вся информация. еще чего не хватало, переводить в текстовый вид и обратно из текстового вида. переводить в текст, по-моему, неумная затея...ПростоНуб писал(а):Наоборот, там будет удобней с бинарным форматом.
И не потребуется на МК преобразовывать числа в текст, отсылаемый по UART.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
[uquote="ARV",url="/forum/viewtopic.php?p=3708749#p3708749"]
Вы специально не уточнили, какой же МК Вы имеете в виду, чтобы я об этом спросил? Ну так вот, спрашиваю. Какой же МК Вы знаете без средств отладки?
Добавлено after 4 minutes 14 seconds:
Starichok51, видимо, у Вас такая специфика. У меня, в подавляющем большинстве случаев, если связь с ПК и требуется, то она реализуется через концентратор на ESP8266 или одноплатный ARM (малинка, апельсинка и т.п.).
далеко не на любом.[/uquote]ПростоНуб писал(а):на любом МК есть JTAG или что-то подобное.
Вы специально не уточнили, какой же МК Вы имеете в виду, чтобы я об этом спросил? Ну так вот, спрашиваю. Какой же МК Вы знаете без средств отладки?
Не понимаю. Ведь в МК у Вас всегда бинарные данные. Так почему средствами МК парсить бинарные данные перед передачей их ПК проще, чем парсить те же самые бинарные данные средствами ПК? Как я понимаю, любой парсинг на ПК пишется всяко проще и быстрее, чем на МК.ARV писал(а):мне никакого резона нет клепать утилиту, парсящую бинарный поток данных
Добавлено after 4 minutes 14 seconds:
Starichok51, видимо, у Вас такая специфика. У меня, в подавляющем большинстве случаев, если связь с ПК и требуется, то она реализуется через концентратор на ESP8266 или одноплатный ARM (малинка, апельсинка и т.п.).
- Сообщения: 2089
- Зарегистрирован: Вс июн 19, 2016 09:32:03
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3708785#p3708785"]Какой же МК Вы знаете без средств отладки?[/uquote]
Кстати, как с отладкой у PDK14?
Кстати, как с отладкой у PDK14?
да практически любой AVR. не рассказывайте мне только про JTAG в старших МК и какой-то однопроводный в остальных - кроме профессионалов, никто не может позволить себе купить отладчики для них. огромное количество 51-ых МК тоже без этого... или тоже с недоступными аппаратными отладчиками.ПростоНуб писал(а):Какой же МК Вы знаете без средств отладки?
сколько раз надо повторить, чтобы вы осознали: когда МК выдает и принимает данные в текстовом виде, на ПК их парсить вообще не надо, отладчик не нужен вообще. а быстродействие более чем достаточное. а когда захочется облагородить интерфейс со стороны ПК, распарсить текст тоже труда не составит.ПростоНуб писал(а):Так почему средствами МК парсить бинарные данные перед передачей их ПК проще, чем парсить те же самые бинарные данные средствами ПК?
то есть и МК и ПК все равно, что обрабатывать, а человеку удобнее текст.
смотря для чего. для связи МК-МК, воможно, и не очень умная. а если в обмен включен человек, то думаю, бинарный формат как раз и есть неумная затея.Starichok51 писал(а):переводить в текст, по-моему, неумная затея...
при наличии текстового обмена нужды в отладчиках нет в принципе.VladislavS писал(а):Посмотреть структуру с данными в отладчике как внутри МК, так и в ПК элементарно
Последний раз редактировалось ARV Сб сен 28, 2019 14:52:58, всего редактировалось 2 раза.
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
- Сообщения: 2516
- Зарегистрирован: Пт июл 12, 2019 22:52:01
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3708785#p3708785"]У меня, в подавляющем большинстве случаев, если связь с ПК и требуется, то она реализуется через концентратор на ESP8266 или одноплатный ARM (малинка, апельсинка и т.п.).[/uquote]
Хватит троллить!
В этом предложении вообще деление на нуль: "если связь с ПК и требуется, то она реализуется ... через ПК"!
Хватит троллить!
В этом предложении вообще деление на нуль: "если связь с ПК и требуется, то она реализуется ... через ПК"!
Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда.
Я на гитхабе, в ЖЖ
Я на гитхабе, в ЖЖ
"научить" ПК переводить бинарные данные в текст - вообще не составляет никакого труда. и даже во много раз проще, чем делать этот перевод на МК перед передачей данных.ARV писал(а):а если в обмен включен человек, то думаю, бинарный форма как раз и есть неумная затея.
зачем в МК тратить попусту процессорное время и на много увеличивать код для такого перевода?
точно также на ПК нет проблем любую строку перевести в число и отправить в МК. и тут, опять, МК не будет тратить попусту процессорное время и на много увеличивать код для такого обратного перевода.
так что, опять повторю: переводить в текст "туда" и "обратно" - неумная затея...
ну, можно назвать это и спецификой моих проектов. как я уже сказал, я делаю для себя, для своего домашнего использования. ну, парой полезных для других проектов поделился с людьми на форуме.ПростоНуб писал(а):Starichok51, видимо, у Вас такая специфика.
и у меня используется простой конвертер USB-to-TTL, чтобы сопрячь USART и комп.
то, что я придумываю для своего хозяйства, может работать и без ПК, на это у меня предусмотрены и кнопки и энкодер. но с ПК работа идет "моментально" - не надо тискать кнопки или крутить энкодер.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
[uquote="ARV",url="/forum/viewtopic.php?p=3708791#p3708791"]кроме профессионалов, никто не может позволить себе купить отладчики для них[/uquote]китайский stlinkv2, спокойно перешиваемый в jlink, 150р стОит.
- Сообщения: 3386
- Зарегистрирован: Пн окт 11, 2010 19:00:08
С каких пор jlink отлаживает авры особенно те что с debugWIRE или вообще не поддерживают аппартаную отладку?arkhnchul писал(а):китайский stlinkv2, спокойно перешиваемый в jlink, 150р стОит.
[uquote="ARV",url="/forum/viewtopic.php?p=3708791#p3708791"]
Просветитесь, хотя бы в Вики
Eddy_Em, не тупите. Сказано, что если связь с ПК и требуется, в подавляющем большинстве случаев она не требует текстового протокола, так как все равно проходит через концентратор, который, если надо, конвертирует бинарный поток в текстовый и наоборот. Причем на нем это делать намного проще и быстрее, чем на МК.
Конечно, если человек домосед на пенсии и ПК у него включен и так круглосуточно - тогда разницы нет.
Родной ICE предлагает отладку, но я не понял, это эмуляция или внутрисхемная отладка.
Все не могу решиться заказать пару сотен PDK14. Думаю или дождаться, когда они на Али и Ебай появятся в хотя бы десятками, или же кооперироваться с кем-то закупая сотни. Раз Вы заинтересовались ими, может есть желание и поучаствовать?
да практически любой AVR[/uquote]ПростоНуб писал(а):Какой же МК Вы знаете без средств отладки?
Просветитесь, хотя бы в Вики
Не судите по себе. ATATMEL-ICE-PCBA за $60 может позволить себе почти любой. У меня в месяц на соляру в два раза больше уходит!ARV писал(а):никто не может позволить себе купить отладчики для них
Но надо сериализовать в текстовый формат на МК! Вы понимаете или нет, что в любом случае один из двух, МК или ПК, должен тратить время и ресурсы на этот парсинг? Вот я и спрашиваю, почему Вы считаете, что преобразовывать бинарные данные на МК лучше, чем на ПК? Кто Вам мешает тупым скриптом на любом интерпретаторе читать данные с последовательного порта, парсить данные в текстовый вид и выводить их в stdout, а введнное в stdin с эхом парсить в бинарный поток и отсылать в тот же порт обратно?ARV писал(а):когда МК выдает и принимает данные в текстовом виде, на ПК их парсить вообще не надо
Eddy_Em, не тупите. Сказано, что если связь с ПК и требуется, в подавляющем большинстве случаев она не требует текстового протокола, так как все равно проходит через концентратор, который, если надо, конвертирует бинарный поток в текстовый и наоборот. Причем на нем это делать намного проще и быстрее, чем на МК.
Никто это не запрещает. Но, как я уже писал выше, та же малинка для такой цели окупается за год только за счет стоимости электроэнергии, потребляемой ПК )Starichok51 писал(а):но с ПК работа идет "моментально" - не надо тискать кнопки или крутить энкодер.
Конечно, если человек домосед на пенсии и ПК у него включен и так круглосуточно - тогда разницы нет.
Не знаю (Reflector писал(а):Кстати, как с отладкой у PDK14?
Родной ICE предлагает отладку, но я не понял, это эмуляция или внутрисхемная отладка.
Все не могу решиться заказать пару сотен PDK14. Думаю или дождаться, когда они на Али и Ебай появятся в хотя бы десятками, или же кооперироваться с кем-то закупая сотни. Раз Вы заинтересовались ими, может есть желание и поучаствовать?
а на что еще его тратить? попусту - это понятие только для человека. микроконтроллер не делает ничего попусту, он делает то, что ему программой указал человек.Starichok51 писал(а):зачем в МК тратить попусту процессорное время и на много увеличивать код для такого перевода?
то есть чтобы увидеть параметры вам надо преобразовать числа в текст - это умно или не умно? может, вы поклонник бинарных часов?Starichok51 писал(а):переводить в текст "туда" и "обратно" - неумная затея...
не говорите чушь: МК и ПК - не люди, они не устают и моральных мук от "бесполезной работы" не испытывают.
а разве нужно следить за темой и отвечать "впопад"?Мурик писал(а):С каких пор jlink отлаживает авры особенно те что с debugWIRE или вообще не поддерживают аппартаную отладку?
предлагаю вам сделать опрос здешних поклонников AVR при одном ограничении: профессиональные разработчики не должны участвовать. и вы сразу увидите, кто по ком судит.ПростоНуб писал(а):Не судите по себе.
ой, что-то манерами КРАМ-а повеяло... это не ваш второй ник, часом?ПростоНуб писал(а):У меня в месяц на соляру в два раза больше уходит!
должен. и что?ПростоНуб писал(а):должен тратить время и ресурсы на этот парсинг?
потому что роль ПК вторична. проект на МК должен быть самодостаточным, потому первичен. а опция общения с человеком при помощи терминала - вторична. изделие с МК может попасть в руки человека, не имеющего навыков скриптописателя - как ему быть?ПростоНуб писал(а):почему Вы считаете, что преобразовывать бинарные данные на МК лучше, чем на ПК?
вы опять пытаетесь сказать, что изучить perl или питон лучше, чем не изучать их? для работы с консолью не требуется ничего нового, чтобы пообщаться с МК.ПростоНуб писал(а):Кто Вам мешает тупым скриптом на любом интерпретаторе читать данные с последовательного порта, парсить данные в текстовый вид и выводить их в stdout
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!
при взгляде на многих сверху ничего не меняется...
Мой уютный бложик... заходите!


