Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

Контролер(и) и проблеми
http://mcu-bg.com/mcu_site/viewtopic.php?f=22&t=17710
Страница 3 от 3

Автор:  ig_ivanov [ Пет Мар 19, 2021 10:29 am ]
Заглавие:  Re: Контролер(и) и проблеми

Не е космическо нещо това, за което питам. Става дума за обикновен контролер за малки стъпкови мотори (с 4988) и регулатор на температура. Та в него грешките наистина ще са само три вида:
1. Фатална-примерно ако прекъсне или се измъкне кабела на NTCто)- контролера изключва всичко.
2. Параметрична- примерно платката да получи стойност за поддържане на температура от 1000 градуса или пък стойност за ШИМа от 237%.
3. Моментна- когато е сработил някой датчик за крайно положение на някой мотор и когато се върне назад, грешката се изчиства.
Поне за момента смятам, че няма нужда от повече гирлянди за индикация, йеле пък за първична и вторична (уточняваща) индикация за грешка. Чуденката ми е най-вече как да се индикира фаталната грешка- с постоянно светене или с бързо мигане (3-4-5Хц). Бавното мигане (0,5-1,5Хц) е запазено за третия вариант и може изобщо да не появи, ако се възстановят достатъчно бързо датчиците.
Също така, на платката има и софтуерен RESET бутон, който да възстановява фабричните настройки на платката (само това!), ако управляващият софтуер я "изгуби" по време на настройка (примерно с дублиране на адреса или задаване на неподходяща скорост на връзката). За момента съм го направил да се проверява дали е натиснат само при подаване на захранване. Има ли смисъл да го правя да ги възстановява, примерно при 10 секундно задържане по време на работа? За мен второто ми звучи опасно, особено ако платката е закачена заедно с мотора на подвижна каретка.

Автор:  ToHu [ Пет Мар 19, 2021 2:40 pm ]
Заглавие:  Re: Контролер(и) и проблеми

Според мен е по-добре да е само при старт.
А при условие, че е лед просто за диагностика, повечето съображения свързани с видимост/разчитане отпадат. Кой сигнал да е за грешка е въпрос на вкус, като цяло мигачите сигнали са по-забележими.

Автор:  ig_ivanov [ Нед Окт 10, 2021 11:25 pm ]
Заглавие:  Re: Контролер(и) и проблеми

Малко да повдигна темата с друг казус, който също се вписва в заглавието.
Може ли MSSP частта на PIC процесорите (примерно PIC18FxxK22 или PIC16F18855) в режим на I2C slave да следи за няколко адреса по линията?
По-конкретно: задавам в SSPADD слейв адрес да кажем 0x40. Ясно е как се процедира по този начин. На линията обаче има закачени още 4 устройства (примерно с адреси 0x62,0x64, 0x66 и 0x68). Има ли начин да се разбере от текущото устройство дали има подаден адресен байт към някое от другите 4 (без да се отговаря на запитването), при положение, че не се знае в кой момент от време към кое устройство ще бъде пусната заявка? Реално от обмена по линията ме интересува само дали има запитване за тези адреси, нищо друго след тях.

Автор:  slav4o.com [ Пон Окт 11, 2021 12:38 am ]
Заглавие:  Re: Контролер(и) и проблеми

Ами то адресният байт си е данни по линията. Контролера записва в регистър един или два байта от комуникацията по линията. Само, че когато е слейв, не зная дали трябва първо да съвпадне адресният байт с неговия адрес за да почне да записва в регистъра или записва винаги и просто вдига някакъв флаг за съвпадение.

Автор:  stefan63 [ Пон Окт 11, 2021 1:03 pm ]
Заглавие:  Re: Контролер(и) и проблеми

16f18855
31.5.1 SLAVE MODE ADDRESSES
The SSPxADD register (Register 31-6) contains the
Slave mode address. The first byte received after a
Start or Restart condition is compared against the
value stored in this register. If the byte matches, the
value is loaded into the SSPxBUF register and an
interrupt is generated. If the value does not match, the
module goes idle and no indication is given to the
software that anything happened.
The SSP Mask register (Register 31-5) affects the
address matching process. See Section 31.5.9 “SSP
Mask Register” for more information

Би трябвало да може чрез "SSP Mask register" .

Автор:  ig_ivanov [ Пон Окт 11, 2021 2:07 pm ]
Заглавие:  Re: Контролер(и) и проблеми

Да, видях го това с маската. Притесняваме да не подаде по линията сигнал ACK след разпознаването и да обърка обмена със съществуващото устройство.

Автор:  slav4o.com [ Пон Окт 11, 2021 2:32 pm ]
Заглавие:  Re: Контролер(и) и проблеми

На тези PIC-ове не може ли да се задават на кои пинове да са модлите. Доколкото поня може I2C входа и изхода могат да са на различни пинове. Това е вариант ако не се стане с този ACK бит да изключваш изхода. Мисля, че имаше режим в който софтуерно се управляват някои неща и отделно съвсем автоматичен. В най-краен случай софтуерно следене на комуникацията.

Автор:  stefan63 [ Пон Окт 11, 2021 6:04 pm ]
Заглавие:  Re: Контролер(и) и проблеми

ig_ivanov написа:
Да, видях го това с маската. Притесняваме да не подаде по линията сигнал ACK след разпознаването и да обърка обмена със съществуващото устройство.

Мисля. че ACK се подава по сетнат бит из някой регистър, и нормално няма да се случи . Виж - за да не закъснееш и да се презапише регистъра с приетия адрес от следващ байт - може би ще трябва да удържиш SCL в нула, докато си регистрираш събитието. Според мене ще стане.
ППС. Може би ще се наложи да манипулираш и прекъсвания по Старт и Стоп.

Автор:  ig_ivanov [ Пет Окт 29, 2021 9:55 am ]
Заглавие:  Re: Контролер(и) и проблеми

В крайна сметка ето какво се оказа на практика:
С ето този код:
Код:
if ((SSP2STATbits.S) & (!SSP2STATbits.R_NOT_W) & (!SSP2STATbits.D_NOT_A) & (SSP2STATbits.BF)) //start bit, buffer full, address
       {
           addr = SSP2BUF;
           if (addr==slave_address2) {countP=0;greenledON();newDATA = 1;} // събитие по зададения адрес
            else
           if ((addr & 0xA0) == 0xA0) {redledON();SPDbyte = addr;newSPD = 1;}; // интересуват ме само старшите 4 бита
       }


излиза, че мога да следя какви адреси циркулират по шината. Процесорът. е PIC18F45k22, MSSP2 е настроен като slave (slave_address2 = 0x66). Резултатът е този на снимката. Ограденото е когато няма и когато има обръщение към зададените адреси (в случая А6 е последния адрес към който са се движили данни). Двете нули на последния ред са данните, които са адресирани към самия PIC (в случая не са получавани данни).
Като тествам и с PIC16F18855 ще пусна и резултатите с него.

Прикачени файлове:
i2c_screen1.jpg
i2c_screen1.jpg [ 132.86 KiB | Прегледано 316 пъти ]

Страница 3 от 3 Часовете са според зоната UTC + 1 час [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/