Если ваш вопрос не влез ни в одну из вышеперечисленных тем, вам сюда.
Ответить

Re: Котуинко

Пт дек 27, 2019 22:16:47

Именно random.
(согласно рекомендаций из helpа)
В том и отличие СОМ от обычного файла.
:wink:
В МК зашивается то, что туда "зашивальщик" запихнет.
А моя КОТУИНКО кушает именно *.hex файлы с последующим перевариванием
утилиткой загрузчика (mason2.txt в файликах библиотек проекта) и далее их декодированное содержимое может быть использовано и как текст и непосредственно как программа..
Ответы пересылаются как текстовые строки, однако там и добавить чего пожелается можно - заложена избыточность как у ПК.
Под ее (КОТУИНКО) биос и подгонка "хотелок" идет.
8)

Re: Котуинко

Пт дек 27, 2019 23:04:31

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

Re: Котуинко

Сб дек 28, 2019 09:59:02

Ошибка была обусловлена недостатком информации об "тонкостях" обработки данных командами.
Ну и настройка порта опционно также имеет значительную роль (вторая группа опционов настройки).
8)

Re: Котуинко

Сб дек 28, 2019 14:58:46

BOB51 писал(а):Ну и настройка порта опционно также имеет значительную роль (вторая группа опционов настройки).
Вроде написано по русски, но кто кроме BOB51 понимает о чем речь?
Мысли нужно излагать так чтобы было понятно окружающим.
У вас в сообщениях "много букв" но мало что понятно.

Re: Котуинко

Пн дек 30, 2019 10:18:32

МУРИК
На этапе тест-проверки "хотелок" объяснять как и для чего тесты проводятся,
да по какой причине вопросы возникают....
Как бы сказать... не слишком-то и корректно...
:roll:
Но все же...
"...OPEN "COMn: параметры1 параметры2" [FOR режим] AS [#]filenum% [LEN=reclen%]..."
речь шла о поведении опций "параметры2" и разнице в применении
input #, line input # при разных режимах порта и разных значениях "параметры2"
в отношении обработки строк ASCII...
8)
Другое дело описание уже готового и вылизанного варианта после всех проб и ошибок.
:wink:

А на НОВОГОД я предпочитаю мозги не перегружать.
Лучше уж спиритусректификати с хорошим закусоном!
:beer:

Re: Котуинко

Вт дек 31, 2019 13:23:21

Актуальная НОВОГОДНЯЯ Альтернативная Самоделка (от ЖОНЫ):
http://img.radiokot.ru/files/20529/239tcayf8o.jpg
http://img.radiokot.ru/files/20529/239za2lxei.jpg
:hunger: :hunger: :hunger:
:beer:

Re: Котуинко

Сб янв 04, 2020 12:18:55

Немножко "дёгтю"...
Относительно КОТУИНКО.
(А возможно и иных устройств на mcs51...)
Собственно относительно "нюанса" при холодной инициализации самой АТ89S52 касательно UART.
При включении питания на консоли терминальной программы выскакивает "лидирующий нулик" (<0>).
Для работы с консольной терминалкой я на тот "нулик" (в hex окне терминала значение 0х00) особо
внимания не обращал - появляется однократно, при "горячем перезапуске" не наблюдается, на работу программ (в том числе и программатора для АТ89Сх051) не влияет - ну и...
Однако при проверке с терминалкой на основе QBasic этот "мусор" проявился как "ошибка ввода/вывода" - т.е. ошибка СОМ порта - приходится делать программный обход этой единичной ошибки.
Однако интерес к вопросу "откуда роги?" привел к более детальному тестированию.
С тем, что у меня из средств тестов - разве что комп да программные "заплатки" в самой АТ89S52 в наличии...
В результате нескольких тестов с печалькой обнаружил, что при подаче питания и последующей инициализации порта UART
в линию TxD сбрасывается какой-то пакет информации, воспринимаемый обычным терминалом как 0х00 (<0>)...
Что, в свою очередь, требуется учитывать при проектировании устройств, в которых один из блоков (терминал на ПК к примеру)
запускается в режиме ожидания приема данных, а устройство с МК подключается к питанию позднее (и сразу высылает контрольное сообщение ведущему).
Данный эффект обнаружился у обеих имеющихся в наличии AT89S52.
:roll:
:dont_know:

Re: Котуинко

Сб янв 04, 2020 13:35:58

По-моему, это свойственно всем USARTам: при изменении режима порта формируется ложный импульс СТАРТ, который и даёт этот эффект.

Re: Котуинко

Сб янв 04, 2020 15:07:14

А Х/З...
Это ж не изменение, а задание режима...
Впрочем... Таким вариантом пока особо не придавалось внимания за отсутствием необходимости и
базы реализации проектов с USART.
С другой стороны - USART чаще всего для бутлоадера задействуется.
Зависимость от конкретного семейства -это также вопросец для сбора статистики.
В любом случае полезно положить в "конспект особых случаев". В ерратах ведь подобное не указано.
Да и чего он там "выплевывает" - это надо запоминающим осциллографом смотреть.
:roll:
Насчет смены режима...
При подаче питания - проводится установка, а вот при программном перезапуске - по факту сначала
SCON сбрасывается в 0х00, а затем снова ставится
setb SM1 ; режим 1 для УАПП активирован
Также перезапускается и таймер, используемый при тактировании USART...
т.е. по факту "горячая" смена режима - но в случае с горячей перезагрузкой НИКАКИХ ложных выбросов НЕТ.
:dont_know:
Вобщем оставляю данные замечания как "заметки к сведению"...
8)

Re: Котуинко

Сб янв 04, 2020 18:00:01

BOB51 писал(а):С тем, что у меня из средств тестов - разве что комп да программные "заплатки" в самой АТ89S52 в наличии...
https://aliexpress.ru/wholesale?SearchT ... 2Banalyzer

Re: Котуинко

Сб янв 04, 2020 19:48:31

Мурик
Какой-такой АЛИ?...
8)
Я ж в ДОНЕЦКЕ (ДНР)!
:)))
Все что на радиорынке есть - доступно, по почтам с нашими "перекладными" разве что ... мотаться.
Да и денежки излишней тратить особо интереса нету.
Это не для простожителя-пенсика.
Работаю лишь с тем, что сам себе соорудить могу позволить, да со "старыми запасами".
:beer:

Re: Котуинко

Ср янв 08, 2020 11:21:16

Интересна книжа для поразмышлять над разновидностями прикладного применения самоделок:
https://yadi.sk/d/SVK3rYaUKmAujg
как "информация к размышлению" вполне сгодится.
Держу в открытом доступе с недельку- две...
:hunger:

Re: Котуинко

Чт янв 09, 2020 20:20:21

Еще одна "темка-прилипалка" по вопросам использования адуринок:
https://radiokot.ru/forum/viewtopic.php?f=57&t=168016
8)

Re: Котуинко

Вт янв 21, 2020 20:42:16

ГЫММ...
union...
а под какую сторону смещаются переменные меньшего из имеющихся в объединении размеров...?
К примеру есть int, char и штук пяток boolean...
Естественно они все в одном слове памяти равном наибольшему - int...
а вот куда примкнут остальные?
логически вроде так (группировка от младшего бита первой из переменных наибольшего размера):
Код:
int            15xxxxxxxxxxxxxx0
char                    8xxxxxx0
boolean 0                      0
boolean 1                     0
boolean 2                    0
....

или не так?...
:dont_know:

Re: Котуинко

Вт янв 21, 2020 22:10:35

в Си boolean нет вообще, а bool, хоть и введен в последних версиях стандарта, на сколько я понимаю, в лучшем случае занимает 1 байт, т.е. эквивалентен char-у

поэтому "штук 5 boolean" займут минимум 5 байт, и первые два байта будет "наложены" на int.

Re: Котуинко

Ср янв 22, 2020 11:08:57

Ну допустим байтовые...
Вопрос к какому краю выравниваться будут - к нулевой позиции первых данных наибольшего формата или от старшей стороны...
Код:
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
:roll:

Re: Котуинко

Ср янв 22, 2020 13:34:49

вы снова задаете вопрос так, что я не понимаю, как вам отвечать... края какие-то нулевые, первые...
будет так:
Код:
//байт: 0  1  2  3
lgdt_a: 00 00 00 00
lgdt_b: 00 00 00 00
itdt_a: 00 00
itdt_b: 00 00
itdt_c: 00 00
cdt_a:  00
cdt_b:  00
cdt_c:  00
cdt_d:  00
cdt_e:  00
cdt_f:  00
номер байта в памяти (для AVR в нулевой позиции всегда младший байт многобайтных чисел) в первой строке, и все ваши char будут одинаковы, и будут совпадать с младшим байтом всех int-ов и longint-ов, все int-ы так же будут одинаковы между собой, как и long int-ы между собой. все это дело у вас займет 4 байта памяти, по размеру наибольшего типа - long int

Добавлено after 2 minutes 29 seconds:
нет никакого смысла городить union, в котором несколько идентификаторов одинакового типа, ведь все равно они будут совпадать по значению...

Re: Котуинко

Ср янв 22, 2020 13:57:52

Ясненько...
Печалюшка, но и, что получается, то пригодится.
8)

Re: Котуинко

Ср янв 22, 2020 16:30:20

вы бы как-то пояснили бы, в чем суть ваших вопросов? все хотите вручную наколдовать код на ЯВУ компактнее, чем ассемблер? или какую цель преследуете с union подобного вида?

Re: Котуинко

Ср янв 22, 2020 21:07:16

Прояснение вопроса совмещения данных разных размерностей/типов/ в общей области памяти для union в процессе изучения.
Было предположение о сцеплении нескольких переменных меньшего размера в области переменной большего размера.
А при отсутствии такового - когда несколько переменных одного размера занимают одну и ту же область одна из "помечталок" просто отменилась.
В принципе вопросы сняты.
:beer:
Осталось еще с перечислением разобраться - чего и куда там можно использовать.
Да чуток детальнее структуры с битовыми полями проработать...
И то... в ленивой неспешности...
:sleep:
Ответить