Тх вроде и так изначально настроен на выход. Как именно эти режимы переключать? Тоесть, я могу просто через digitalWrite подать ноль, делей 25мс, digitalWrite единица? Он сможет после единицы слать данные?
Чего бы ему не слать, в принципе-то? При передаче нога начнет дергаться точно так же. Ну, максимум - один байт стартовый потеряете.
Уже понял, что с кодировками у меня большая проблема, и решить пока ее не могу(((
Решил прислушаться, и начал разбираться с масивами.
Касательно команд, чуть выше я описал полный процесс.
Немного добавлю
Стартовый пакет байт имеет известное количество байт, все остальные пакеты, которые нужно просто переслать, имеют разную и не известную длину.
Тх вроде и так изначально настроен на выход. Как именно эти режимы переключать? Тоесть, я могу просто через digitalWrite подать ноль, делей 25мс, digitalWrite единица? Он сможет после единицы слать данные?
Чего бы ему не слать, в принципе-то? При передаче нога начнет дергаться точно так же. Ну, максимум - один байт стартовый потеряете.
Ясно, попробую.
Это упростит схему устройства.
Спасибо
Buzoff, у Вас описание задачи в постах №45 и №47 радикальным образом отличаентся:
В №45: устройство №1 шлет пакет байт, конвертер эти байты принимает, добавляет впереди импульс и стартовый пакет байт (что это такое - непонятно), а устройство №2 должно это все принять.
В №47: устройство само шлет и импульс и стартовый пакет байт, но, кроме этого должно еще и принимать ответ от устройства №2, а устройство №2 в свою очередь, должно не только принимать, но еще и что-то передавать.
И это все при том, что каждое из описаний явно не полно. Например в №45 если пакеты передаются на пониженной скорости, то не описано, что делать, если конвертер не будет успевать передавать все то, что он принимает от устройства №1.
А можно вопрос касательно тх рх (чтоб не заводить новую тему)
Можно ли програмно менять местами тх и рх на апаратном uart?
Если можно, я буду искать информацию.
Если нет, то вопрос закрыт и обсуждаем проблему данной темы.
Просто Да или НЕТ.
спасибо
Поменять местами аппаратные rx и tx нельзя, но можно программно перевести rx в режим вывода и сформировать на нем нужный импульс.
Правда, стремная какая-то система получается: в правильно спроектированной системе не должно быть возможностей соединения между собой выходов устройств (кроме выхода с ОК).
В 45м посте был описан процесс.
Устройства #1 и #2 общаются через ардуину (точнее атмегу8)
Общаются на разных скоростях, ардуино конвертирует скоростя в обе стороны. Пакеты устройствами передаются с паузами, поэтому все успевается
Устройство#2, соедено через к-линию, поэтому для соединения и начала общения, нужно послать стартовый пакет байт, перед которым должны идти два импульса по 25см, 0 и 1
В 45м посте был описан процесс. Устройства #1 и #2 общаются через ардуину (точнее атмегу8) Общаются на разных скоростях, ардуино конвертирует скоростя в обе стороны. Пакеты устройствами передаются с паузами, поэтому все успевается Устройство#2, соедено через к-линию, поэтому для соединения и начала общения, нужно послать стартовый пакет байт, перед которым должны идти два импульса по 25см, 0 и 1
Buzoff - надеюсь, вы понимаете, что для такого устройства нужно два сериала? То есть придется задействовать программный. Памяти-то хватит? а то в атмеге8 ее не так много
Ну и напоследок - вы бы задачу подробнее описали... сдается мне, что вы КАН-адаптер собираете. Если да - то их готовых на Али море
В 45м посте был описан процесс. Устройства #1 и #2 общаются через ардуину (точнее атмегу8) Общаются на разных скоростях, ардуино конвертирует скоростя в обе стороны. Пакеты устройствами передаются с паузами, поэтому все успевается Устройство#2, соедено через к-линию, поэтому для соединения и начала общения, нужно послать стартовый пакет байт, перед которым должны идти два импульса по 25см, 0 и 1
Buzoff - надеюсь, вы понимаете, что для такого устройства нужно два сериала? То есть придется задействовать программный. Памяти-то хватит? а то в атмеге8 ее не так много
Ну и напоследок - вы бы задачу подробнее описали... сдается мне, что вы КАН-адаптер собираете. Если да - то их готовых на Али море
Я говорил что устройство#1 подключено через програмный uart, а устройство#2 - через апаратный.
Чтото на подобии КАН, нотне его, на али его нет, а у прозводителя блока (устройство#2) такой адаптер стоит неоправданно дорого, под 100$
Чтото на подобии КАН, нотне его, на али его нет, а у прозводителя блока (устройство#2) такой адаптер стоит неоправданно дорого, под 100$ Памяти хватит атмеги8
А вы искали на Али адаптер под ваше конкретное устройство? может поискать просто переходник UART-CAN ? Потому как полноценного адаптера может и не быть, но есть микросхемы, делающие практически ту же перекодировку, которую вы тут вымучиваете вторую неделю
Так, давайте не будем перекручивать.
Во-первых, я никого не просил ничего сделать за меня, я вроде только озвучил проблему с которой столкнулся и паралельно описал общую задачу, якобы это должно было помочь в ришении той самой проблемы, но только добавило вопросов "зачем?" "Дешевле купить" и тд.
Во-вторых, это хобби, мне это интересно, друг спросил можно ли такое сделать, я ответил "давай попробую".
Чисто спортивный интерес, справлю не справлюсь.
На счёт траты времени и денег, скажите это рыбакам)))
В-третьих, непонятна фраза "мы здесь помагаем тем кто учится". И учится нужно для того чтоб просто знать, применять нельзя? Научился моргать светодиодом - иди купи моргающий светодиод. Еще раз повторюсь, это хобби, было бы мне это не интересно, уже б давно забил на это. Иногда же хочется сделать что-то своими руками.
Хобби всегда было способом потратить деньги, а не заработать (или сэкономить) их.
PS. Если "друг спросил", то, скорее всего, Вы не попытались выяснить у друга, что именно ему нгадо. По крайней мере вразумительного описания того, что надо Вы на данном этапе сформулировать не можете - каждый новый Ваш пост либо добавляет что-то, чего раньше не было, либо вообще противоречит ранее написанному, а чаще - и то и другое.
Попытайтесь собраться с другом и тщательно описать желаемое - по пунктам и желательно с рисованием блок-схемы.
Тх вроде и так изначально настроен на выход. Как именно эти режимы переключать? Тоесть, я могу просто через digitalWrite подать ноль, делей 25мс, digitalWrite единица? Он сможет после единицы слать данные?
Чего бы ему не слать, в принципе-то? При передаче нога начнет дергаться точно так же. Ну, максимум - один байт стартовый потеряете.
при активированом uart не дает управлять Тх как обычным пином, покрайней мере у мени не получилось.
при отключеном uart Тх работает как обычный пин, но сериал не работает. постоянно включать/выключать сериал, тоже скорее всего не правильно
наверно всетаки останутся диоды через дополнительный пин.
вобщем с кодировкой символов разобрался, поэтому все прекрасно работает со строками. считаю, самый простой вариант для новичков типа меня). только единственный недостаток - эталонная строка не может содержать "нули 0х00", ноль в строке обозначает конец мтроки, и все после него в процесе не учавствует (могу и ошибаться)
а вот масивы таких недостатков не имеют, если разобраться в них, но это не сложно когда тебя каждый пинает)))
всем спасибо.
по ходу возник один вопрос. при использовании двух uart (програмного и апаратного) и пересылки данных друг через друга, часто встречается вот такие примеры скетча:
void loop(){
if (mySerial.available() > 0){ иногда и без этой строки
while (mySerial.available()){
char s = mySerial.read();
Serial.write(s);}
}
if (Serial.available()){
char incByte = Serial.read();
mySerial.print(incByte); }
}
для чего нужен цикл при приеме с програмного uart, а для апаратного цикл не применяют?
а в самом простом варианте все выглядит так:
void loop(){
if (mySerial.available())
Serial.write(mySerial.read());
if (Serial.available())
mySerial.write(Serial.read());}
Не совсем понятно, что тут под циклом подразумевается, но разница между технологиями в том, что при дерганьи ноги аппартного UART на любом (почти) этапе выполнения машинного кода вызывается обработчик прерывания и при его помощи байт засовывается в буфер. Программный UART никто не дергает за ноги и он вынужден постоянно проверять состояние входа - не передают ли там чего.
Не совсем понятно, что тут под циклом подразумевается, но разница между технологиями в том, что при дерганьи ноги аппартного UART на любом (почти) этапе выполнения машинного кода вызывается обработчик прерывания и при его помощи байт засовывается в буфер. Программный UART никто не дергает за ноги и он вынужден постоянно проверять состояние входа - не передают ли там чего.
может неправильно выразился по поводу цикла (while), я говорил о этих двух частях кода:
if (mySerial.available() > 0){
while (mySerial.available()){
char s = mySerial.read();
Serial.write(s);}
}
и
if (mySerial.available())
Serial.write(mySerial.read());
Первая часть выводит _всё_ доступное на данный момент из буфера (но там не обязательно будет весь пакет), вторая - по одному символу.
Подходы разные, но самом простом случае однозначного преимущества ни у одного из способов я не вижу. Разве что буфер будет вычищаться быстрее. Теоретически.
случайно не вкурсе, есть ли возможность на програмном uart в библиотеке <SoftwareSerial.h> применять контроль четности/нечетности? таким же способом как на апаратном
Чего бы ему не слать, в принципе-то? При передаче нога начнет дергаться точно так же. Ну, максимум - один байт стартовый потеряете.
Уже понял, что с кодировками у меня большая проблема, и решить пока ее не могу(((
Решил прислушаться, и начал разбираться с масивами.
Касательно команд, чуть выше я описал полный процесс.
Немного добавлю
Стартовый пакет байт имеет известное количество байт, все остальные пакеты, которые нужно просто переслать, имеют разную и не известную длину.
Чего бы ему не слать, в принципе-то? При передаче нога начнет дергаться точно так же. Ну, максимум - один байт стартовый потеряете.
Ясно, попробую.
Это упростит схему устройства.
Спасибо
Buzoff, у Вас описание задачи в постах №45 и №47 радикальным образом отличаентся:
В №45: устройство №1 шлет пакет байт, конвертер эти байты принимает, добавляет впереди импульс и стартовый пакет байт (что это такое - непонятно), а устройство №2 должно это все принять.
В №47: устройство само шлет и импульс и стартовый пакет байт, но, кроме этого должно еще и принимать ответ от устройства №2, а устройство №2 в свою очередь, должно не только принимать, но еще и что-то передавать.
И это все при том, что каждое из описаний явно не полно. Например в №45 если пакеты передаются на пониженной скорости, то не описано, что делать, если конвертер не будет успевать передавать все то, что он принимает от устройства №1.
.
А можно вопрос касательно тх рх (чтоб не заводить новую тему)
Можно ли програмно менять местами тх и рх на апаратном uart?
Если можно, я буду искать информацию.
Если нет, то вопрос закрыт и обсуждаем проблему данной темы.
Просто Да или НЕТ.
спасибо
Поменять местами аппаратные rx и tx нельзя, но можно программно перевести rx в режим вывода и сформировать на нем нужный импульс.
Правда, стремная какая-то система получается: в правильно спроектированной системе не должно быть возможностей соединения между собой выходов устройств (кроме выхода с ОК).
В 45м посте был описан процесс.
Устройства #1 и #2 общаются через ардуину (точнее атмегу8)
Общаются на разных скоростях, ардуино конвертирует скоростя в обе стороны. Пакеты устройствами передаются с паузами, поэтому все успевается
Устройство#2, соедено через к-линию, поэтому для соединения и начала общения, нужно послать стартовый пакет байт, перед которым должны идти два импульса по 25см, 0 и 1
А менять-то зачем rx/tx ? Я наверняка не скажу за любой МК, но про 328-й я не читал о такой возможности.
Buzoff - надеюсь, вы понимаете, что для такого устройства нужно два сериала? То есть придется задействовать программный. Памяти-то хватит? а то в атмеге8 ее не так много
Ну и напоследок - вы бы задачу подробнее описали... сдается мне, что вы КАН-адаптер собираете. Если да - то их готовых на Али море
А менять-то зачем rx/tx ? Я наверняка не скажу за любой МК, но про 328-й я не читал о такой возможности.
Это для другого проекта, просто задал вопрос по ходу, пока речь шла о тх/рх
Проехали)))
Buzoff - надеюсь, вы понимаете, что для такого устройства нужно два сериала? То есть придется задействовать программный. Памяти-то хватит? а то в атмеге8 ее не так много
Ну и напоследок - вы бы задачу подробнее описали... сдается мне, что вы КАН-адаптер собираете. Если да - то их готовых на Али море
Я говорил что устройство#1 подключено через програмный uart, а устройство#2 - через апаратный.
Чтото на подобии КАН, нотне его, на али его нет, а у прозводителя блока (устройство#2) такой адаптер стоит неоправданно дорого, под 100$
Памяти хватит атмеги8
Чтото на подобии КАН, нотне его, на али его нет, а у прозводителя блока (устройство#2) такой адаптер стоит неоправданно дорого, под 100$ Памяти хватит атмеги8
А вы искали на Али адаптер под ваше конкретное устройство? может поискать просто переходник UART-CAN ? Потому как полноценного адаптера может и не быть, но есть микросхемы, делающие практически ту же перекодировку, которую вы тут вымучиваете вторую неделю
... а у прозводителя блока (устройство#2) такой адаптер стоит неоправданно дорого, под 100$
В общем, IMHO сейчас Вы просто теряете время (время=деньги!), а дешевле все равно не получится.
И еще: здесь принято помогать тем, кто хочет научиться, а тем, кто хочет сэкономить, предлагают обращаться в раздел "Ищу исполнителя".
Так, давайте не будем перекручивать.
Во-первых, я никого не просил ничего сделать за меня, я вроде только озвучил проблему с которой столкнулся и паралельно описал общую задачу, якобы это должно было помочь в ришении той самой проблемы, но только добавило вопросов "зачем?" "Дешевле купить" и тд.
Во-вторых, это хобби, мне это интересно, друг спросил можно ли такое сделать, я ответил "давай попробую".
Чисто спортивный интерес, справлю не справлюсь.
На счёт траты времени и денег, скажите это рыбакам)))
В-третьих, непонятна фраза "мы здесь помагаем тем кто учится". И учится нужно для того чтоб просто знать, применять нельзя? Научился моргать светодиодом - иди купи моргающий светодиод. Еще раз повторюсь, это хобби, было бы мне это не интересно, уже б давно забил на это. Иногда же хочется сделать что-то своими руками.
Хобби всегда было способом потратить деньги, а не заработать (или сэкономить) их.
PS. Если "друг спросил", то, скорее всего, Вы не попытались выяснить у друга, что именно ему нгадо. По крайней мере вразумительного описания того, что надо Вы на данном этапе сформулировать не можете - каждый новый Ваш пост либо добавляет что-то, чего раньше не было, либо вообще противоречит ранее написанному, а чаще - и то и другое.
Попытайтесь собраться с другом и тщательно описать желаемое - по пунктам и желательно с рисованием блок-схемы.
Чего бы ему не слать, в принципе-то? При передаче нога начнет дергаться точно так же. Ну, максимум - один байт стартовый потеряете.
при активированом uart не дает управлять Тх как обычным пином, покрайней мере у мени не получилось.
при отключеном uart Тх работает как обычный пин, но сериал не работает. постоянно включать/выключать сериал, тоже скорее всего не правильно
наверно всетаки останутся диоды через дополнительный пин.
вобщем с кодировкой символов разобрался, поэтому все прекрасно работает со строками. считаю, самый простой вариант для новичков типа меня). только единственный недостаток - эталонная строка не может содержать "нули 0х00", ноль в строке обозначает конец мтроки, и все после него в процесе не учавствует (могу и ошибаться)
а вот масивы таких недостатков не имеют, если разобраться в них, но это не сложно когда тебя каждый пинает)))
всем спасибо.
по ходу возник один вопрос. при использовании двух uart (програмного и апаратного) и пересылки данных друг через друга, часто встречается вот такие примеры скетча:
void loop(){ if (mySerial.available() > 0){ иногда и без этой строки while (mySerial.available()){ char s = mySerial.read(); Serial.write(s);} } if (Serial.available()){ char incByte = Serial.read(); mySerial.print(incByte); } }для чего нужен цикл при приеме с програмного uart, а для апаратного цикл не применяют?
а в самом простом варианте все выглядит так:
void loop(){ if (mySerial.available()) Serial.write(mySerial.read()); if (Serial.available()) mySerial.write(Serial.read());}с чем это может быть связано?
Не совсем понятно, что тут под циклом подразумевается, но разница между технологиями в том, что при дерганьи ноги аппартного UART на любом (почти) этапе выполнения машинного кода вызывается обработчик прерывания и при его помощи байт засовывается в буфер. Программный UART никто не дергает за ноги и он вынужден постоянно проверять состояние входа - не передают ли там чего.
Не совсем понятно, что тут под циклом подразумевается, но разница между технологиями в том, что при дерганьи ноги аппартного UART на любом (почти) этапе выполнения машинного кода вызывается обработчик прерывания и при его помощи байт засовывается в буфер. Программный UART никто не дергает за ноги и он вынужден постоянно проверять состояние входа - не передают ли там чего.
может неправильно выразился по поводу цикла (while), я говорил о этих двух частях кода:
if (mySerial.available() > 0){ while (mySerial.available()){ char s = mySerial.read(); Serial.write(s);} }и
Первая часть выводит _всё_ доступное на данный момент из буфера (но там не обязательно будет весь пакет), вторая - по одному символу.
Подходы разные, но самом простом случае однозначного преимущества ни у одного из способов я не вижу. Разве что буфер будет вычищаться быстрее. Теоретически.
случайно не вкурсе, есть ли возможность на програмном uart в библиотеке <SoftwareSerial.h> применять контроль четности/нечетности? таким же способом как на апаратном
Serial.begin(9600,SERIAL_8O1)Я не в курсе. Но тут где-то тема была про счетчики Энергомера - там какраз что-то с нестандартными настройками порта мутили.
Я не в курсе. Но тут где-то тема была про счетчики Энергомера - там какраз что-то с нестандартными настройками порта мутили.
спасибо, поищу.