Кто любит RISC в жизни, заходим, не стесняемся.
Пт май 29, 2020 14:37:34
Всем привет! Столкнулся с проблемой, сижу туплю, ничего не понимаю. Делал я как-то давно устройство для считывания температуры с нескольких датчиков 1-Wire DS18B20. Изначально оно было сделано на ATmega8. На одной шине сидело несколько датчиков и я по персональному ID стучался к каждому датчику и читал с него температуру. Сначала ID каждого датчика жестко прописывал в прошивку, потом, когда датчики начали выходить из строя, чтобы каждый раз контроллер не перепрошивать прикрутил считывание из ROM датчика его ID и сохранение в EEPROM контроллера. Все работало как часы (только время не показывало
). Но вот решил я пересесть с AVR-ок на STM-ки. Попробовал сначала с одним датчиком через команду игнора адреса датчика (0xCC). Работает. Потом жестко прописал адреса нескольких датчиков в прошивке и посадил их на одну шину. РАБОТАЕТ. Начал прикручивать считывание ID из ROM датчика и .... уперся. ОНО НЕ СЧИТЫВАЕТСЯ. Вернее считывается правильно только первый байт, потом полная ахинея. Я просто в ногдауне. Если все остально еработает - следовательно с протоколом все в порядке, код портирован правильно. Именно считывание адреса из ROM не работает и именно на STM32 (кстати не толко на F103, но и на F303). Не могу понять в чем прикол.
Я намеренно не выкладываю свой код, т.к. имею достаточно опыта, чтобы понять, что криминала там нет и забивать вам голову не обязательно.
Пт май 29, 2020 14:50:00
Тупо ткнуть осциллограф и логический анализатор в линию религия не позволяет?
Пт май 29, 2020 17:53:05
Вопрос решился, хотя яснее не стало. Читать 64-байтный ROM из датчика нужно не в массив из 8-байт, в 64 байтную переменную. В чем разница - не понятно, по факту абсолютно теже операции.... В AVR работало
Пт май 29, 2020 18:23:23
Непогрешимый код в очередной раз превратился в лягушку
Можете дальше его не показывать, чтобы узнать причину.
Пт май 29, 2020 23:29:00
АВР - 8 битники.
АРМ 32 битный по умолчанию.
Тонкости компилятора для каждого семейства свои.
Пн июн 01, 2020 09:48:00
Непогрешимый код в очередной раз превратился в лягушку
Можете дальше его не показывать, чтобы узнать причину.
Интересно, а если бы я дал вам такой вариант кода:
- Код:
char sens_address[8];
one_wire_reset();
one_wire_send(0x33);
for (int i=0; i<8; i++)
sens_address[i]=one_wire_read_rom();
вы бы прям так сразу мне: Ну ты чё, чувак, ну разве можно так делать? Нельзя побайтно в массив читать, надо переменную завести 64-разрядную.
ОК. Привожу код.
Было:
- Код:
char sens_address[8];
one_wire_reset();
one_wire_send(0x33);
for (int i=0; i<8; i++)
sens_address[i]=one_wire_read_rom();
char one_wire_read_rom(void)
{
int bit, i;
char a=0;
for (i=0; i<8; i++)
{
one_wire_low();
_delay_us(5);
one_wire_hight();
_delay_us(15);
bit=one_wire_level();
a|=bit<<i;
_delay_us(90);
}
return a;
}
Стало:
- Код:
long long sens_address
one_wire_reset();
one_wire_send(0x33);
sens_address=one_wire_read_rom();
long long one_wire_read_rom(void)
{
long long bit=0;
long long a=0;
for (int i=0; i<64; i++)
{
one_wire_low();
delay_us(5);
one_wire_hight();
delay_us(15);
bit = one_wire_level();
a |= bit<<i;
delay_us(90);
}
return a;
}
первый вариант работает на AVR, на STM32 не работает. Второй вариант работает на STM32, на AVR не пробовал.
Пн июн 01, 2020 10:23:03
Расположение индейцев в памяти учтено?
Пн июн 01, 2020 10:23:52
вы бы прям так сразу мне: Ну ты чё, чувак, ну разве можно так делать? Нельзя побайтно в массив читать, надо переменную завести 64-разрядную.
не надо - тут говнокодик, работает на пиках аврах стм8 стм32...
https://radiokot.ru/forum/viewtopic.php ... 1#p2071361
Пн июн 01, 2020 11:32:01
Да чего вы кинулись код то кидать? ТС всего лишь разницу между 8 и 32 битным процом не видит.
Пн июн 01, 2020 11:35:49
VladislavS, так ведь и подход абсолютно разный: на аврке нет DMA, там реализовать 1-wire можно только двумя способами: таймер+прерывание или UART. А на STM32 можно таймер с DMA, можно USART с DMA…
// вообще, мегадебильнейший протокол: аппаратно МК не поддерживает, значит, оно нафиг никому не нужно! Я так считаю. И ту древнюю реализацию, код которой скинул, уже давно не поддерживаю, т.к. выкинул из головы эту блажь — использовать идиотские DS18B20, когда есть нормальные датчики, работающие на I2C или SPI!
Пн июн 01, 2020 13:25:08
Да чего вы кинулись код то кидать? ТС всего лишь разницу между 8 и 32 битным процом не видит.
"Разрядность" - ну ни фига себе. Надо в словарик записать....
Чем отличаются русский, американский и еврейский форумы?
- на американском форуме вы задаете вопрос и вам дают ответ
- на еврейском форуме вы задаете вопрос и вам задают встречный вопрос
- на русском форуме вы задаете вопрос и вам долго объясняют почему вы такой мудак.
Пн июн 01, 2020 16:01:21
ddimochka писал(а):ОК. Привожу код.
Программное чтение из датчиков?
Почему не USART?
https://www.cyberforum.ru/blogs/204791/blog5226.html
Пн июн 01, 2020 16:01:29
ddimochka, я первым же сообщением под вашим кодом дал информацию для размышления. Это куда полезней, чем просто пережёванное в ротик положить. Я на 95% уверен, что дело в "индейцах".
Почему не USART?
Ещё один
Вопрос не в этом был!!!
Пн июн 01, 2020 17:32:51
Eddy_Em, DS18B20 не фига не идиотский, пашет себе и пашет.
Пн июн 01, 2020 18:10:53
240265, очень даже идиотский, т.к. в низшей ценовой категории нет ни одного микроконтроллера, аппаратно поддерживающего 1-wire.
И приходится городить велосипед-квадратные-колеса, абы этот говнопротокол реализовать!
В итоге теряем 1 канал DMA + USART или таймер!
А был бы датчик на I2C или SPI, ничего терять не пришлось бы... Ну или хотя бы взять 5-рублевый терморезистор и повесить его на свободный канал АЦП! Всяко более удачное решение (да и врать будет ничуть не хуже DS18).
Пн июн 01, 2020 23:27:20
Eddy_Em писал(а):в низшей ценовой категории нет ни одного микроконтроллера, аппаратно поддерживающего 1-wire.
Они вообще есть? Пока что не не попадались МК аппаратно поддерживающие 1Wire.
Eddy_Em писал(а):А был бы датчик на I2C или SPI, ничего терять не пришлось бы.
Выводов нужно больше. Допустим нужно подключить 100 датчиков на значительном (десятки метров) расстоянии от МК. У I2C или SPI будет преимущество?
Вт июн 02, 2020 10:28:28
Допустим нужно подключить 100 датчиков на значительном (десятки метров) расстоянии от МК. У I2C или SPI будет преимущество?
Конечно: городим по узлу на гроздь датчиков, узлы соединяем по CAN-шине — вуаля!
Вот — работает, 5 узлов, CAN-шина, 80 термодатчиков (но я тоже через одно место сделал: по-человечески, надо было брать аналоговые платиновые калиброванные термодатчики и городить на каждой "грозди" АЦП с мультиплексорами по трехпроводной схеме, тогда можно было бы действительно достигнуть точности в 0.01°C в заданном диапазоне).
А 1-wire вам в этом случае вообще никак не поможет, потому что 100 датчиков на десятках метров удаления вы на одну шину не посадите! В случае же с CAN-шиной по витухе пускается и 12..36В напруги, в итоге и связь есть, и питание. А датчики подключаем к узлам кабелями не длинней 2..3м.
Вт июн 02, 2020 13:35:21
Eddy_Em писал(а):Конечно: городим по узлу на гроздь датчиков, узлы соединяем по CAN-шине — вуаля!
Что конечно? Вы считаете преимуществом кучу дополнительных электронных компонентов?
Eddy_Em писал(а):А 1-wire вам в этом случае вообще никак не поможет, потому что 100 датчиков на десятках метров удаления вы на одну шину не посадите!
Почему же можно.
Eddy_Em писал(а):А датчики подключаем к узлам кабелями не длинней 2..3м.
Доп. компоненты, доп. расходы. Они должны быть обоснованными. В таком случае на 100 датчиков понадобится 100 преобразователей CAN<->интерфейс датчика. Получится слишком дорого и громоздко.
Вт июн 02, 2020 14:32:51
ddimochka, я первым же сообщением под вашим кодом дал информацию для размышления. Это куда полезней, чем просто пережёванное в ротик положить. Я на 95% уверен, что дело в "индейцах".
Ды я понял. И так уж размышляю в этом направлении. Но пока в принципе все получается, я не буду лезть в дебри - не до того, хотя на досуге нужно бы плотно разобраться.
Мурик писал(а):
Почему не USART?
Ещё один
Вопрос не в этом был!!!
USART занят под другие нужды. Ну и да, вопрос не об этом.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.