Список разделов Flyback.org.ru » не HV » Микроконтроллеры и всё, что с ними связано
Тему сейчас просматривают - зарегистрированных: 0, скрытых: 0 и гостей: 0
Зарегестрированные - Нет
Ответить с цитатой

Ivani
 


Скоро Ethernet придумаешь.

Добавлено: Fri Dec 21, 2018 10:49 pm
Ответить с цитатой

Николай
 


а фигли его думать. 4транса, сигнал в манчестер и свиста в один транс, принимай с другого. вот только земли, наводки, пробои трансов.

нужен был канал из говна и палок, но дубовый и надежный. чтобы ацп с конденсаторным питанием отдавал значение тока вися на фазе, не пытаясь этой фазой пробитт комунибудь дальше по линии.
итоговая стоимость оконечников 150руб. ретранслятора 250 руб.
ну либо оптоизолированные 485 спецмикры по 1200 за единицу.
а сигнал у самоделки в линии красивей. токовая петля наводок почти не ловит, ибо низкоомна.

поигрался недельку 485 - не то. слишком нежный. или неправдано дорогой

Добавлено: Fri Dec 21, 2018 11:07 pm
Ответить с цитатой

Анна
 


Еще бывают всякие Е1..Е4 и прочее такое Smile Там тоже трансформаторы

Добавлено: Sat Dec 22, 2018 12:16 pm
Ответить с цитатой

Николай
 


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

Добавлено: Sat Dec 22, 2018 1:23 pm
Ответить с цитатой

Ivani
 


Atmega2560 слева али, справа чипдип.

Добавлено: Sat Dec 22, 2018 6:56 pm
256_1.jpg (147.73 Кб)

256_2.jpg (162.85 Кб)

Ответить с цитатой

Behram
 


Чипдип сам не брезгует с помоек типа али возить.

Добавлено: Sat Dec 22, 2018 7:11 pm
Ответить с цитатой

Денис
 


Что, у алишной снизу лазерная маркировка, а сверху краска??

Добавлено: Sat Dec 22, 2018 7:11 pm
Ответить с цитатой

Ivani
 


Перемарк наверно. На следующей неделе соберу попробую.

Добавлено: Sat Dec 22, 2018 7:42 pm
Ответить с цитатой

Анна
 


Говорят, еще ADMega16 встречается иногда Smile

Добавлено: Sat Dec 22, 2018 8:02 pm
Ответить с цитатой

Behram
 


Аналоговой Девицы? смех

Добавлено: Sat Dec 22, 2018 8:15 pm
Ответить с цитатой

Ivani
 


Проверил меги 256 - оба вида работают, под феном на 235° С 1 китайская бодро надулась и упрыгала, больше феном паять их не пытался, паял Т-12.
В среде ардуино программатором штатно скетчи в них не пишутся, багу как минимум 5 лет.

Добавлено: Tue Dec 25, 2018 10:21 am
Ответить с цитатой

Николай
 


не совсем микроконтроллеры, но ARM (малинка)

функция
Код:

char* vread(char* name)
{
char buf[16];
..........................
..........................
return(buf);
}


при компиляции на большой машине (x64)
замечательно возвращает этот самый buf
конструкция value=vread("blablabla"); является строкой.

а при компиляции под arm - там пустота. т.е. переменная buf уничтожается раньше чем возвращается.
надо этот самый buf объявить глобально.


и еще strncpy() под arm тоже вообще не работает. поебень какую-то копирует. приходится memcpy заменять.

вот вам и кроссплатформенность. вроде бы gcc да gcc

отключил все контроллеры от большого компа, перелил софт на малину - а тут подъеб такой. всю голову свернул почему работающий неделю уже код начал в segfault вываливаться в произвольных местах, и творил что хотел


Добавлено: Tue Dec 25, 2018 7:29 pm
Ответить с цитатой

Доктор Зло
 


Николай писал(а):
замечательно возвращает этот самый buf
конструкция value=vread("blablabla"); является строкой.


buf[16] - локальная переменная, уничтожается после завершения функции.
Этот указатель после завершения функции недействителен, хотя и ненулевой по значению.

Чтобы строка осталась существовать, надо ее создать. Например так:
char *buf = new char[16];
return buf;
Но не забыть потом удалить при завершении программы.
delete buf;

Добавлено: Tue Dec 25, 2018 9:05 pm
Ответить с цитатой

Николай
 


переменная то уничтожается. но return через стек ее должен передать по выходу. под x64 он так и делает. ведь при компиляции на бубунте все работает. а в дебиане под arm не передает.

ведь мы return делаем в области видимости переменной. и потом сразу же по выходу забираем это значение.
меня смущает разное поведение на разных платформах

Добавлено: Tue Dec 25, 2018 10:42 pm
Ответить с цитатой

N1X
 


Николай писал(а):
переменная то уничтожается. но return через стек ее должен передать по выходу.
Неа, return у тебя передает УКАЗАТЕЛЬ на переменную. Ты этот указатель и получил, но никто не обещал, что он указывает в адекватное место, т.к. при выходе из функции с областью где была эта переменная может что угодно быть. Она могла быть на стеке, могла быть в регистре. Это дело компилятора.
Хочешь получить переменную - передавай ее по значению (без *), хочешь получить массив - готовь экземпляр до вызова функции, передавай ей указатель и пусть она в него пишет...

Добавлено: Wed Dec 26, 2018 12:57 pm
Ответить с цитатой

Николай
 


а еще глюк словил. конечно из криворукости. был отдельный код в функции. потом функция не стала нужна, так как выполнялась только из одного места. я ее тупо скопировал в основной код.
ну и объявление переменных перекочевало также как и было. т.е. переменные объявлялись каждый раз, когда выполнение проходило через эту часть кода.

main{
while(){
..........
unsigned char count,min,max;
struct tm* t;
time_t st;
.........
}
}


ебаааать. код вел себя просто пиздецово. в зависимости от фазы луны переменные то работали нормально, то накладывались на другие (т.е. по сути становились указателями) и менялись вмести с ними. то накладывались на один байт из long int.


вообщем охуенно наркоманский глюк.

Добавлено: Fri Jan 04, 2019 10:09 pm
Ответить с цитатой

Ivani
 


Я последнее время стараюсь ВСЕ переменные делать глобальными, задавать разумную длину, начальное значение и по возможности беззнаковыми.

Добавлено: Fri Jan 04, 2019 10:47 pm
Ответить с цитатой

Behram
 


Есть такая проблема у меня. Юзаю TMS320F2811, с помощью input capture измеряю ширину импульсов с энкодера на валу двигателя(частота импульсов от 1 до 150к в секунду). Все было бы хорошо, но период импульсов может быть больше периода счета таймера - 0xFFFF (таймер 16-битный). Решил выйти из этой ситуации следующим образом - сделал прерывание по переполнению и в обработчике инкрементирую буфер на число 0xFFFF. В обработчике прерывания по событию input capture я к захваченному значению счетчика добавляю буфер и отнимаю от него предыдущее значение чтобы посчитать разницу. После этого буфер обнуляю, а предыдущее событие приравниваю к захваченному сейчас. Все было бы хорошо, но у меня еще есть прерывание с другого таймера, где обрабатываются данные с АЦП и там же происходит довольно объемная математика с ними. И у этого прерывания приоритет выше, чем у прерывания переполнения таймера, поэтому бывает, что инкремент буфера делается уже после того, как было захвачено событие кепчером. Как с этим можно бороться?

Добавлено: Fri Jan 04, 2019 11:26 pm
Ответить с цитатой

Николай
 


ну если в этот момент идет математика, значит намереное время будет недостоверным, ибо первый таймер не вовремя по прерыванию уйдет. значит надо это измерение проигнорировать. в прерывании с математикой выставляй какойнить флажек. и если флаг установлен то сбросить буфер, обнулить счетчик забыть все и считать заново.

ну либо таймер не по переполнению а по сравнению заводить. и считать не до FFFF, а скажем до FF00 (с запасом времени на математику) тогда даже если пропустим прерывание, то когда оно выполнится то мы узнаем на сколько тиков мы пропустили

Добавлено: Fri Jan 04, 2019 11:40 pm
Ответить с цитатой

Анна
 


Радикальное решение энкодерной беды (если в используемом МК нет встроенной поддержки энкодерного интерфейса)- поставить небольшую плисину, дать такт мегагерц 20..100 и описать хардварный обработчик с бешеным запасом скорости (и на сколько нужно энкодеров, если их несколько).

Добавлено: Sat Jan 05, 2019 10:36 am
Ответить с цитатой

Behram
 


Ну, вообще, поддержка энкодерного интерфейса есть (называется QEP), но сможет ли он корректно посчитать низкую скорость вращения?

Решение Николая тоже попробую.

Добавлено: Sat Jan 05, 2019 11:33 am
Ответить с цитатой

N1X
 


Behram писал(а):
но сможет ли он корректно посчитать низкую скорость вращения?
Ну так QEP считает перемещение, а не скорость жеж... А скорость есть производная от перемещения, которая считается отдельно. При работе с энкодером один фиг скорость будет обновляться только во время очередного изменения состояния энкодера, каким бы методом она не измерялась...
Чем меньше нужна рабочая скорость, тем больше должно быть разрешение энкодера...

Добавлено: Sat Jan 05, 2019 9:00 pm
Ответить с цитатой

Николай
 


ну не получается только проводными каналами обойтись. придется перекинуть 50м по воздуху мост.
вот репу чешу чем бы прокинуть. может hc-12 взять?
нужен прозрачный uart.
помехозащмщенность не очень важна. коетрольная сумма у пакетов есть, пакет если что посылается повторно.
нужна надежность самой железки. пусть проебет пару пакетов, но чтобы хоть какойто линк был всегда

UPD
кстате, а ктонить debugwire пользовал? прикольная жеж штука. вывода reset всеравно не жалко в 99%

Добавлено: Tue Jan 08, 2019 11:28 pm
Ответить с цитатой

Behram
 


Есть ли какая-нибудь простая в использовании либа для расчета sha-1? А то чет треш какой-то гуглится.

Добавлено: Sun Jan 20, 2019 4:43 pm
Ответить с цитатой

Ivani
 


Для ардуино https://github.com/Cathedrow/Cryptosuite

Добавлено: Sun Jan 20, 2019 5:17 pm
Список разделов Flyback.org.ru » не HV » Микроконтроллеры и всё, что с ними связано
На страницу Пред.  1, 2, 3 ... 118, 119, 120 ... 150, 151, 152  След.     Просмотр темы целиком



Лицензионное соглашение

(c)Flyback.org.ru
Российское общество любителей высоких напряжений.
Использование материалов с данного сайта и форума возможно только с разрешения администрации.