TViT

Задумка сделать более менее умное устройство которое будет подстраиваться динамические под поступающий сигнал и давать разные режимы работы компрессора. Агрессивная компрессия легкая компрессия. Плюс просто вкл\откл одной кнопкой компрессора. И в режиме без компресссии возможности выбирать разные пороги усиления помимо потенциометра - GAIN. Плюс индикация светодиодом разных режимов работы. Задержку тинька почти не дает. Тем более там задержку искусственно нужно добавлять при оцифровке и слежении за сигналом, потому что по мгновенному значению амплитуды сигнала ничего не поймешь. Только если следишь за сигналом 10-20мс тогда становится понятно что это уже периодически повторяющаяся амплитуда и уже точно ясна огибающая.

Всем привет. Нужно сделать аналогово-цифровой гитарный предусилитель\компрессор. Усилением управляю ШИМ сигналом с контроллера tiny25 через JFET в цепи обратной связи ОУ TL072. С выхода ОУ смотрю за амплитудой и подстраиваю усиление. Но вот не могу придумать алгоритм как быть когда струна затухает и усиление автоматически поднимается чтобы на выходе держать нужную амплитуду сигнала. И например при макс усилении происходит удар по струне что приводит на выходе к всплеску сигнала выше максимума и обрезанию, ограничению, клиппированию сигнала с последующим постепенным снижением усиления до нужного среднего уровня. Но все равно эффект крайне негативно слушается при игре. Что можно сделать. Как выйти из положения?

У меня Eclipse + OpenOCD либо +SEGGER

Ну постараюсь, что-то отладка на китайце не заводилась.

Как же одновременно если построчно стирается? (" на строку подают напряжение стирания, весь заряд сбрасывается на всей строке" ) Иначе почему процесс стирания такой долгий. Тогда бы вся страница параллельно стерлась бы? А если построчно, то что сделает контроллер когда определенная строка не стерлась? Идет дальше стирает остальные строки и уже потом на верхнем уровне функция стирания проверяет регистр состояния и выкидывает ошибку? Типа там где-то при стирании не дотерлось... И тогда при таком раскладе действительно можно предположить что FF везде кроме сбойных мест.

В STM32F103RET6 - 16, 32, 64 бита #define FLASH_TYPEPROGRAM_HALFWORD 0x01U /*!<Program a half-word (16-bit) at a specified address.*/ #define FLASH_TYPEPROGRAM_WORD 0x02U /*!<Program a word (32-bit) at a specified address.*/ #define FLASH_TYPEPROGRAM_DOUBLEWORD 0x03U /*!<Program a double word (64-bit) at a specified address*/ Там все это в алгоритме надежного сохранения делается и не только это, кучу всего дополнительного еще. Просто заинтересовал вопрос именно в железе. Что будет если флеш начинает сыпаться и ф-я стирания выдает ошибку. Что будет физически во флеш памяти. Можно ли надеятся что там везде будет FF, кроме сбойного бита или байта или слова.

Как это поймать побыстрее и полегче? Где при настройке чего проблема затаилась которой вроде как и не должно быть?

Это почему, объясните? Страница 2048 байт, кол-во стираний 10000. Если нужно сохранять в этой странице одну переменную максимального размера 4 байта то при одном стирании ее можно записать 512раз. Умножаем на 10000 циклов получаем больше 5 млн записей. Ошибка, разумеется)) Да причем тут ошибка? Это на верхнем уровне я ее получу от ф-ции стирания. Что будет физически во флеш FF везде? Ну кроме например сбойного бита или байта не важно. Алгоритм обхода просматривает память перед записью и пишет туда где FF.

Да каюсь спешил... Миллионы циклов записи данных. Стирание страницы то скорее всего будет заявленные 10000циклов * на количество страниц. Так не я управляю стиранием, это делает контроллер памяти. Вот в этом и вопрос как он стирает? Что будет если бит не сотрется мне функция выдаст ошибку, что процесс стирания прошел неудачно. А вот что будет во флеш памяти при этом? Контроллер сотрет до сбойного бита, и выйдет с ошибкой. Или вся страница будет стерта, а потом контроллер сам делает проверку и если там не FF уже мне на верхний уровень выдаст ошибку. При этом не стертым будет один сбойный бит? И я уже своим алгоритмов этот бит буду обходить и читать и писать дальше в другие области страницы. И так пока Флеш не сдохнет и не начнет сбоить?

Народ при создании файловой системы и алгоритма размазывания и надежного сохранения и восстановления данных, чтобы была возможность оперировать миллионами циклов записи и стирания, появился вопрос... Кто знает что будет в STM32 при стирании страницы если например 1 бит на странице битый, поврежденный. Функция до этого бита сотрет память и выкинет ошибку и какие-то области будут не стертыми? Или вся страница стирается и проверяется на FF после чего выдается ошибка? Можно ли потом работать и записывать в другие области этой недотертой страницы, обходя сбойные биты. Например после собственной проверки на FF, до этого сбойного бита и после где по идее должны быть единицы? Или страница помечается как битая при первом сбойном бите и дальше не стирается? Как можно промоделировать отказ Флеш памяти. Что происходит при стирании, какой алгоритм самого контроллера флеш-памяти.

Может есть у кого-то возможность простой проект создать для работы с CAN и у себя проверить наверняка есть такие процы у многих, если работает я проверю ваш проект у себя. Может у меня чип сбойный... Вот мой проект, только без драйверов, форум не дает больше 4Мб прикрепить TEST_CAN.7z

Да у меня такое и на STM32 было )) Год назад примерно осваивал какой-то модуль, так вот пока в определенный порядок не выставил функции инициализации не работало. Но сейчас, что-то никак все перетасовал. Да и тасовать то особа нечего... Вы про эти функции имели ввиду? HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_CAN_Init();

Могут конечно. Но я их не вижу. Все ноги задействованы в этом МК. Даже SWO-pin для отладки хотелось бы иметь, но и его пришлось задействовать. Все пины работают и порты ввода вывода лампочки мигают по UART с правильнами скоростями все передается и принимается. Частота тоже 72МГц иначе бы все тайминги уплыли, там и FreeRTOS и опрос каждые 10мс по CAN разных устройств и все четко работает. Кроме приема по CAN. Даташит смотрел, на сколько хватает моих познаний не увидел больших отличий. Поэтому и прошу помощи и наставлений у опытных людей.

Спасибо большое, но мне скорее нужно на базе текущей реализации проекта на базе HAL lib понять в чем различия в настройке CAN. Например какой-то бит не так настроен, чем отдельно на базе GD32 lib или регистров портировать весь проект. Может есть соображения на этот счет, буду рад любой информации )) Ткните носом где различия CAN модуля. Чтобы было понятно что вкл или откл при настройке CAN в текущем проекте через HAL lib.

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

Ну что ж будем ждать более конструктивной помощи. Поскольку KEIL не использую, для независимости от какой либо IDE. Проект текущий тестирую в Eclipse, собирается через makefile. По сути нужно решить одну проблему, почему пакеты не принимаются. Хотя все пакеты отправляются без проблем и ошибок и не отличаются от stm32. Может какой бит иначе нужно выставлять при настройке CAN в gd32 или наоборот сбрасывать...

Да всплывает то много чего, но мне нужна конкретика, четкие шаги, где взять то, где это, для того и этого чтобы исправить ситуацию, а не общие рассуждения... По вашей ссылке как раз просто обсуждения без технических подробностей и конкретики. Вот это уже интереснее )) Подробнее можно, на какой библиотеке настраивали, может примеры есть как скрестить HAL lib и библиотеку для GD32. А если напрямую сами регистрами управляете, можете ли поделиться исходником...

Всем привет. Народ подскажите есть ли у кого опыт, по переходу с STM32F103RET6 на GD32F103RET6. У меня в проекте все работает если прошивку от stm32 залить в туже плату только с GD32 и spi и uart и порты, но вот CAN не работает. Причем пакеты посылаются корректные все как stm32, но приема CAN пакетов от другого устройства не происходит. Фильтры все в 0, принимают все кадры. CAN-снифер показывает что посылки идут, но устройство на GD32 не принимает пакеты. Хотя посылает их корректно. При отладке не вызывается колбэк по приему, как будто в принципе не было пакетов на линии или они аппаратно CAN-контроллером не пропускаются на верхний уровень в приложение. Подскажите куда копать, кто сталкивался с такой проблемой?

Да вот что-то не нашел. Алгоритм может и не сильно будет зависеть, но свои нюансы могут быть.

Всем привет. Подскажите по сохранению данных во Flash. Есть голубая пилюля с STM32F103C8T6 на борту. Как можно надежно сохранить данные например при отключении питания и потом при включении гарантированно их считать. При этом требуется механизм размазывания, поскольку есть данные которые редко изменяются, а есть которые очень часто. Приветствуется любая информация.

Точно не получится. Когда 32байта массив был. Все работало на разных пультах кроме Филипса так - если ширина большая в 4х байтной переменной устанавливается соответствующий бит в 1 иначе 0. И на выходе 4х байтное число (32бита) - команда. Которых очень много можно записать в память - 16 кнопок управления если брать половину памяти в МК - 64байт. Проверял на пультах от ЭЛТ телевизоров Rubin, JVC, Samsung, на новом TFT телеке LG и на пульте от звукового ресивера-усилителя Yamaha А теперь при массиве в 65байт иначе. Точно не измерить ширину импульса в моем случае (тактируется все от внутреннего RC генератора, плавать значения будут в массиве всегда и по другим причинам - от загрузки МК ведь он прерывает работу и обрабатывает еще кучу всего, прерывания от компаратора например постоянно поступают раз в 10мс, детектирует переходы через 0 сетевого напр, еще прерывания от первого таймера управляет шириной импульса для управления симистором - вкл\выкл освещения, запоминание состояний, команд, уровня яркости в eeprom и само управлением яркостью через генерирование в разные моменты управляющих импульсов в зависимости от начала полупериода сетевого напр). Да мне точно и не нужно. Поскольку когда массив забивается, потом алгоритм нормирования все приводит к точным числам 1,2,3 --- соответственно 1-мин время импульса какое нашел в массиве, 2-среднее по длит время импульса какое было в массиве и 3-самое высокое время импульса которое было в массиве. А потом хеширование и на выходе уникальное число. Которых в мою память можно напихать кучу, соответственно и команд кучу можно запомнить. В принципе я уже решил задачу. В моем случае этого для управления пока освещением более чем достаточно. А в будущем просто МК с большей памятью прикручу и все )) Всем спасибо ))

У меня примерно так же только частота 4МГц и еще проверка разных кнопок какая нажата с какой длительностью и что делать. Плюс детектор нуля сетевого напряжения на компараторе и программа генерации и управления импульсами через таймер для MOC и ФИУ симистором. Ну и программа хеширования массива 65байт длительностей импульсов на выходе уникальное 2байтовое число характеризующее нажатую кнопку. С другими кнопками на пульте не совпадает и на разных пультах тоже не совпадает. Только по переполнению таймера детектируется конец кодовой посылки. А значение длительности импульса записывается при новом изменении на входе при прерывании.

Я с вами согласен. Но это потом я все переведу на 32битные STM или Atmel. Пока AT32UC3L064 управляет распознаванием речи почти в реальном времени, а ATtiny25 всем остальным командами с пульта с кнопок, импульсами команд от голосового модуля. Что есть то есть не выкидывать же деньги на ветер, послушался совета называется у разных профи... Что закупил нужно использовать. И платы разведены. Это не считая что Atmel кинула с ценой на AT32UC3L064. Которые пару лет назад стоили 122р... и наши бравые ребята наверху обвалив рубль... Сами что посоветуете макс дешевое из эл базы. Для распознавания голоса нужно 64кБ флеш и 16кб ОЗУ. А отдельная ATtiny25 просто нужна для освещения. Планируется как полный комплект функций, так и отдельно только управление с пульта и кнопками. Поэтому 2е отдельные МС использовал... И еще такой выбор был сделан из-за минимизации размеров и главное потребления, поскольку устройство работает сутками в реальном режиме, не отключаясь и не засыпая...

Я пока зашифровал команды все работает. И уменьшил количество кнопок управления с 4х до одной. Т.е. 8байт хранят 4 зашифрованные команды информацию по сути 4х - 65байтовых массивов длительностей, но 4 вариации одной команды полюбому сработает. Не будет 4х функций будет одна на первое время. Тестирую пробую пока все нормально за исключением мерцаний... А в будущем будет видно что и как. Поскольку главное размер и цена моего устройства. Конечно это пробный блин немножко комом оказался...

Я думаю ваш алгоритм сложен, у меня нет столько памяти, чтобы в несжатом виде хранить массивы длительностей. Массив у меня 65байт. Было 32байта ранее, работает кроме пультов от Филипса с RC6. Всего 128байт память и еще занято под программу ФИУ симистором, управлением освещением, плавным включением, яркостью различными режимами и блокировками поступающих команд и т.д. Это всего лишь одна опция моей системы, управление с пульта. Помимо управления кнопками и голосом. На Филипсе 3 вида длительностей оказалось и разная длительность команд. Может 35 импульсов плюнуть, а может 39 и т.д. Зависит от команды. В остальном похоже с вашим описанием. Плюют постоянно при удержании. И новую команду при повторном нажатии. Но есть еще кнопки, которые 3 команда разом плюют и ожидают. Конечно тайминги и задержки у меня тоже есть, не принимать вторичную посылку. Все упирается в память. Хотелось бы что-то попроще. Итак не успевает моргает свет при управлении с пульта пока обрабатывает прерывания и вычисляет команду, а управление симистором на это период упускает. На сколько помню в ATtiny25 нет режима захвата по таймеру.