Вопросы по С/С++ (СИ)

[Reflector]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3708785#p3708785"]Какой же МК Вы знаете без средств отладки?[/uquote]
Кстати, как с отладкой у PDK14?

[ARV]

Какой же МК Вы знаете без средств отладки?

да практически любой AVR. не рассказывайте мне только про JTAG в старших МК и какой-то однопроводный в остальных - кроме профессионалов, никто не может позволить себе купить отладчики для них. огромное количество 51-ых МК тоже без этого... или тоже с недоступными аппаратными отладчиками.

Так почему средствами МК парсить бинарные данные перед передачей их ПК проще, чем парсить те же самые бинарные данные средствами ПК?

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

переводить в текст, по-моему, неумная затея...

смотря для чего. для связи МК-МК, воможно, и не очень умная. а если в обмен включен человек, то думаю, бинарный формат как раз и есть неумная затея.

Посмотреть структуру с данными в отладчике как внутри МК, так и в ПК элементарно

при наличии текстового обмена нужды в отладчиках нет в принципе.

[Eddy_Em]

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3708785#p3708785"]У меня, в подавляющем большинстве случаев, если связь с ПК и требуется, то она реализуется через концентратор на ESP8266 или одноплатный ARM (малинка, апельсинка и т.п.).[/uquote]
Хватит троллить!
В этом предложении вообще деление на нуль: "если связь с ПК и требуется, то она реализуется ... через ПК"!

[Starichok51]

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

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

Starichok51, видимо, у Вас такая специфика.

ну, можно назвать это и спецификой моих проектов. как я уже сказал, я делаю для себя, для своего домашнего использования. ну, парой полезных для других проектов поделился с людьми на форуме.
и у меня используется простой конвертер USB-to-TTL, чтобы сопрячь USART и комп.
то, что я придумываю для своего хозяйства, может работать и без ПК, на это у меня предусмотрены и кнопки и энкодер. но с ПК работа идет "моментально" - не надо тискать кнопки или крутить энкодер.

[arkhnchul]

[uquote="ARV",url="/forum/viewtopic.php?p=3708791#p3708791"]кроме профессионалов, никто не может позволить себе купить отладчики для них[/uquote]китайский stlinkv2, спокойно перешиваемый в jlink, 150р стОит.

[Мурик]

китайский stlinkv2, спокойно перешиваемый в jlink, 150р стОит.

С каких пор jlink отлаживает авры особенно те что с debugWIRE или вообще не поддерживают аппартаную отладку?

[ПростоНуб]

[uquote="ARV",url="/forum/viewtopic.php?p=3708791#p3708791"]

Какой же МК Вы знаете без средств отладки?

да практически любой AVR[/uquote]
Просветитесь, хотя бы в Вики

никто не может позволить себе купить отладчики для них

Не судите по себе. ATATMEL-ICE-PCBA за $60 может позволить себе почти любой. У меня в месяц на соляру в два раза больше уходит!

когда МК выдает и принимает данные в текстовом виде, на ПК их парсить вообще не надо

Но надо сериализовать в текстовый формат на МК! Вы понимаете или нет, что в любом случае один из двух, МК или ПК, должен тратить время и ресурсы на этот парсинг? Вот я и спрашиваю, почему Вы считаете, что преобразовывать бинарные данные на МК лучше, чем на ПК? Кто Вам мешает тупым скриптом на любом интерпретаторе читать данные с последовательного порта, парсить данные в текстовый вид и выводить их в stdout, а введнное в stdin с эхом парсить в бинарный поток и отсылать в тот же порт обратно?

Eddy_Em, не тупите. Сказано, что если связь с ПК и требуется, в подавляющем большинстве случаев она не требует текстового протокола, так как все равно проходит через концентратор, который, если надо, конвертирует бинарный поток в текстовый и наоборот. Причем на нем это делать намного проще и быстрее, чем на МК.

но с ПК работа идет "моментально" - не надо тискать кнопки или крутить энкодер.

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

Кстати, как с отладкой у PDK14?

Не знаю (
Родной ICE предлагает отладку, но я не понял, это эмуляция или внутрисхемная отладка.
Все не могу решиться заказать пару сотен PDK14. Думаю или дождаться, когда они на Али и Ебай появятся в хотя бы десятками, или же кооперироваться с кем-то закупая сотни. Раз Вы заинтересовались ими, может есть желание и поучаствовать?

[ARV]

зачем в МК тратить попусту процессорное время и на много увеличивать код для такого перевода?

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

переводить в текст "туда" и "обратно" - неумная затея...

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

С каких пор jlink отлаживает авры особенно те что с debugWIRE или вообще не поддерживают аппартаную отладку?

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

Не судите по себе.

предлагаю вам сделать опрос здешних поклонников AVR при одном ограничении: профессиональные разработчики не должны участвовать. и вы сразу увидите, кто по ком судит.

У меня в месяц на соляру в два раза больше уходит!

ой, что-то манерами КРАМ-а повеяло... это не ваш второй ник, часом?

должен тратить время и ресурсы на этот парсинг?

должен. и что?

почему Вы считаете, что преобразовывать бинарные данные на МК лучше, чем на ПК?

потому что роль ПК вторична. проект на МК должен быть самодостаточным, потому первичен. а опция общения с человеком при помощи терминала - вторична. изделие с МК может попасть в руки человека, не имеющего навыков скриптописателя - как ему быть?

Кто Вам мешает тупым скриптом на любом интерпретаторе читать данные с последовательного порта, парсить данные в текстовый вид и выводить их в stdout

вы опять пытаетесь сказать, что изучить perl или питон лучше, чем не изучать их? для работы с консолью не требуется ничего нового, чтобы пообщаться с МК.

[Starichok51]

Просветитесь, хотя бы в Вики

а ты сам просветись по твоей ссылке, какие МК поддерживают debugWIRE. это крохи от всего семейства AVR.

Не судите по себе. ATATMEL-ICE-PCBA за $60 может позволить себе почти любой. У меня в месяц на соляру в два раза больше уходит!

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

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

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

а на что еще его тратить?

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

[Eddy_Em]

Eddy_Em, не тупите.

Это кто еще тупит? Мы с ARV уже неоднократно писали, зачем сериализовать данные на МК и чем это собственно удобно. Кто-то явно либо не читает, либо тупит... Про бритву Оккама вы, пожалуй, не слышали... Зачем мне выдумывать скрипт, если я просто могу запустить сеанс screen и работать с железкой безо всяких посредников?

[Starichok51]

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

[Мурик]

[uquote="ARV",url="/forum/viewtopic.php?p=3708832#p3708832"]

С каких пор jlink отлаживает авры особенно те что с debugWIRE или вообще не поддерживают аппартаную отладку?

а разве нужно следить за темой и отвечать "впопад"? главное ведь ляпнуть погромче хоть что, а то ведь могут счесть некомпетентым...[/uquote]Это вы ляпаете погромче или скажите что J-Link поддерживает 8-ми битные AVR?
И к тому же я спрашивал не вас.

[ПростоНуб]

[uquote="Starichok51",url="/forum/viewtopic.php?p=3708840#p3708840"]какие МК поддерживают debugWIRE. это крохи от всего семейства AVR.[/uquote]
Естественно, только младшие. Остальные поддерживают JTAG, отладчик которого намного дешевле ATATMEL-ICE-PCBA из существенно большей распостраненности. Но ни одного AVR вообще без поддержки внутрисхемной отладки я не встречал. Подскажите, пожалуйста, какой же AVR не поддерживает внутрисхемную отладку?

$60 может позволить себе почти любой.

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

Прошу прощения, если чем-то обидел. Я не зря написал "почти любой". И судил не по себе, а исходил из того, что меньше 10% от средней зарплаты в РФ потраченые на разовую покупку устройства со сроком службы порядка 10 лет - вполне приемлемы.
Тут осциллографами народ хвастается за $300-500 и ничего. Большинство любителей STM32 скорее лишний доллар потратят, чем с трехцентовым МК свяжутся. Так что у меня ощущение, что многие тут зарабатывают существенно больше меня, считающего себестоимость конечного изделия )))

[Мурик]

Но ни одного AVR вообще без поддержки внутрисхемной отладки я не встречал. Подскажите, пожалуйста, какой же AVR не поддерживает внутрисхемную отладку?

Много какие. ATmega8 например.

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

Китайский JTAG отладчик для AVR стоит не много. https://ru.aliexpress.com/item/32787622885.html

[Starichok51]

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

[arkhnchul]

[uquote="Мурик",url="/forum/viewtopic.php?p=3708816#p3708816"]С каких пор jlink отлаживает авры особенно те что с debugWIRE или вообще не поддерживают аппартаную отладку?[/uquote]каюсь, тут ступил. "Старшие МК" atmel-а у меня ассоциируются со всякими ATSAM-ами, которые не avr.

[ARV]

Китайский JTAG отладчик для AVR стоит не много.

стоит не много во всех смыслах: в смысле отладки он вообще ничего не стоит. не работает он. точнее, крайне неустойчиво работает, из 20 попыток соединиться получается 1 раз, но спустя 3-5 секунд/минут (как повезет) отваливается.

[ПростоНуб]

ARV, возвращаясь к началу, по Вашему личному мнению, считаете ли Вы допустимым использование стандартных (ISO) функций setjmp()/longjmp()? И если не сложно, аргументируйте свой ответ, пожалуйста.

[VladislavS]

[uquote="ARV",url="/forum/viewtopic.php?p=3708995#p3708995"]стоит не много во всех смыслах: в смысле отладки он вообще ничего не стоит. не работает он. точнее, крайне неустойчиво работает, из 20 попыток соединиться получается 1 раз, но спустя 3-5 секунд/минут (как повезет) отваливается.[/uquote]Ну так продолжайте жевать кактус. При том что контроллеров с нормальной отладкой хоть опой жуй.

[ARV]

При том что контроллеров с нормальной отладкой хоть опой жуй.

приятного жевания.

по Вашему личному мнению, считаете ли Вы допустимым использование стандартных (ISO) функций setjmp()/longjmp()? И если не сложно, аргументируйте свой ответ, пожалуйста.

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

да, я считаю допустимым примерение и goto, и упомянутые вами функции setjmp и longjmp. не смотря на то, что последними я сам никогда не пользовался, я вполне понимаю, для чего они могут быть полезны и в каких случаях.

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

я достаточно арументированно ответил вам, ПростоНуб?

теперь чуть-чуть философствования. try-except или try-finally (или catch - везде по-разному) обладает дъявольской привлектальностью. каждому в душе хочется сделать какое-нибудь сумасбродство, и только опасение неизбежной расплаты останавливает от этого. а тут такая возможность - делай что угодно внутри этой "обертки" и ничего тебе не будет. вместо проверки диапазонов аргументов функций просто заверни в try-xxxxxx. вместо проверки на существование файла, вместо уточнения рамера массива, вместо проверки указателя на NULL - просто делай try - и ничего не бойся!
и попытка оправдать существование setjmp и ей парной функции тем, что в Си нет этой волшебной обертки, я считаю недостаточным аргументом, чтобы советовать всем начинающим творить этот беспредел.


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