Именно random. (согласно рекомендаций из helpа) В том и отличие СОМ от обычного файла. В МК зашивается то, что туда "зашивальщик" запихнет. А моя КОТУИНКО кушает именно *.hex файлы с последующим перевариванием утилиткой загрузчика (mason2.txt в файликах библиотек проекта) и далее их декодированное содержимое может быть использовано и как текст и непосредственно как программа.. Ответы пересылаются как текстовые строки, однако там и добавить чего пожелается можно - заложена избыточность как у ПК. Под ее (КОТУИНКО) биос и подгонка "хотелок" идет.
BOB51, если у вас при "трансляции" из файла в порт или обратно возникают "добавления-исчезновения" символов конца строки, это говорит только о наличии ошибки в ваших программах.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Ошибка была обусловлена недостатком информации об "тонкостях" обработки данных командами. Ну и настройка порта опционно также имеет значительную роль (вторая группа опционов настройки).
Ну и настройка порта опционно также имеет значительную роль (вторая группа опционов настройки).
Вроде написано по русски, но кто кроме BOB51 понимает о чем речь? Мысли нужно излагать так чтобы было понятно окружающим. У вас в сообщениях "много букв" но мало что понятно.
МУРИК На этапе тест-проверки "хотелок" объяснять как и для чего тесты проводятся, да по какой причине вопросы возникают.... Как бы сказать... не слишком-то и корректно... Но все же... "...OPEN "COMn: параметры1 параметры2" [FOR режим] AS [#]filenum% [LEN=reclen%]..." речь шла о поведении опций "параметры2" и разнице в применении input #, line input # при разных режимах порта и разных значениях "параметры2" в отношении обработки строк ASCII... Другое дело описание уже готового и вылизанного варианта после всех проб и ошибок.
А на НОВОГОД я предпочитаю мозги не перегружать. Лучше уж спиритусректификати с хорошим закусоном!
Немножко "дёгтю"... Относительно КОТУИНКО. (А возможно и иных устройств на mcs51...) Собственно относительно "нюанса" при холодной инициализации самой АТ89S52 касательно UART. При включении питания на консоли терминальной программы выскакивает "лидирующий нулик" (<0>). Для работы с консольной терминалкой я на тот "нулик" (в hex окне терминала значение 0х00) особо внимания не обращал - появляется однократно, при "горячем перезапуске" не наблюдается, на работу программ (в том числе и программатора для АТ89Сх051) не влияет - ну и... Однако при проверке с терминалкой на основе QBasic этот "мусор" проявился как "ошибка ввода/вывода" - т.е. ошибка СОМ порта - приходится делать программный обход этой единичной ошибки. Однако интерес к вопросу "откуда роги?" привел к более детальному тестированию. С тем, что у меня из средств тестов - разве что комп да программные "заплатки" в самой АТ89S52 в наличии... В результате нескольких тестов с печалькой обнаружил, что при подаче питания и последующей инициализации порта UART в линию TxD сбрасывается какой-то пакет информации, воспринимаемый обычным терминалом как 0х00 (<0>)... Что, в свою очередь, требуется учитывать при проектировании устройств, в которых один из блоков (терминал на ПК к примеру) запускается в режиме ожидания приема данных, а устройство с МК подключается к питанию позднее (и сразу высылает контрольное сообщение ведущему). Данный эффект обнаружился у обеих имеющихся в наличии AT89S52.
А Х/З... Это ж не изменение, а задание режима... Впрочем... Таким вариантом пока особо не придавалось внимания за отсутствием необходимости и базы реализации проектов с USART. С другой стороны - USART чаще всего для бутлоадера задействуется. Зависимость от конкретного семейства -это также вопросец для сбора статистики. В любом случае полезно положить в "конспект особых случаев". В ерратах ведь подобное не указано. Да и чего он там "выплевывает" - это надо запоминающим осциллографом смотреть. Насчет смены режима... При подаче питания - проводится установка, а вот при программном перезапуске - по факту сначала SCON сбрасывается в 0х00, а затем снова ставится setb SM1 ; режим 1 для УАПП активирован Также перезапускается и таймер, используемый при тактировании USART... т.е. по факту "горячая" смена режима - но в случае с горячей перезагрузкой НИКАКИХ ложных выбросов НЕТ. Вобщем оставляю данные замечания как "заметки к сведению"...
Мурик Какой-такой АЛИ?... Я ж в ДОНЕЦКЕ (ДНР)! Все что на радиорынке есть - доступно, по почтам с нашими "перекладными" разве что ... мотаться. Да и денежки излишней тратить особо интереса нету. Это не для простожителя-пенсика. Работаю лишь с тем, что сам себе соорудить могу позволить, да со "старыми запасами".
Интересна книжа для поразмышлять над разновидностями прикладного применения самоделок: https://yadi.sk/d/SVK3rYaUKmAujg как "информация к размышлению" вполне сгодится. Держу в открытом доступе с недельку- две...
ГЫММ... union... а под какую сторону смещаются переменные меньшего из имеющихся в объединении размеров...? К примеру есть int, char и штук пяток boolean... Естественно они все в одном слове памяти равном наибольшему - int... а вот куда примкнут остальные? логически вроде так (группировка от младшего бита первой из переменных наибольшего размера):
в Си boolean нет вообще, а bool, хоть и введен в последних версиях стандарта, на сколько я понимаю, в лучшем случае занимает 1 байт, т.е. эквивалентен char-у
поэтому "штук 5 boolean" займут минимум 5 байт, и первые два байта будет "наложены" на int.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Ну допустим байтовые... Вопрос к какому краю выравниваться будут - к нулевой позиции первых данных наибольшего формата или от старшей стороны...
Код:
union bloks { long lgdt_a; long lgdt_b; int itdt_a; int itdt_b; int itdt_c; char cdt_a; char cdt_b; char cdt_c; char cdt_e; char cdt_f; } my_bloks;
логично было бы при "выравнивании к младшим" иметь место следующее наложение lgdt_a = lgdt_b:itdt_a = cdt_e:cdt_c:cdt_b:cdt_a а cdt_f одновременно является младшим байтом для itdt_c и для lgdt_b
номер байта в памяти (для AVR в нулевой позиции всегда младший байт многобайтных чисел) в первой строке, и все ваши char будут одинаковы, и будут совпадать с младшим байтом всех int-ов и longint-ов, все int-ы так же будут одинаковы между собой, как и long int-ы между собой. все это дело у вас займет 4 байта памяти, по размеру наибольшего типа - long int
Добавлено after 2 minutes 29 seconds: нет никакого смысла городить union, в котором несколько идентификаторов одинакового типа, ведь все равно они будут совпадать по значению...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
вы бы как-то пояснили бы, в чем суть ваших вопросов? все хотите вручную наколдовать код на ЯВУ компактнее, чем ассемблер? или какую цель преследуете с union подобного вида?
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Прояснение вопроса совмещения данных разных размерностей/типов/ в общей области памяти для union в процессе изучения. Было предположение о сцеплении нескольких переменных меньшего размера в области переменной большего размера. А при отсутствии такового - когда несколько переменных одного размера занимают одну и ту же область одна из "помечталок" просто отменилась. В принципе вопросы сняты. Осталось еще с перечислением разобраться - чего и куда там можно использовать. Да чуток детальнее структуры с битовыми полями проработать... И то... в ленивой неспешности...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
