Я пишу приложение UWP на C # для Windows 10 IoT Core на Raspberry Pi 3B, которое должно взаимодействовать с 16-разрядным АЦП TI ADS1601.Чтобы установить связь с этим чипом, я должен побить простой SPI-подобный последовательный протокол связи и сначала инициировать преобразование посредством своевременно отправленных сигналов, что показано на изображении ниже, взятом из руководства ADS1601:
Чтобы инициировать АЦП, я должен послать импульс SYNC в соответствии с CLK (тактовым сигналом) от кварцевого генератора, и после считывания действительного ответа от чипа он готов к извлечению данных,Обнаружение краев - вот где я начинаю испытывать трудности.
Мой код, вдохновленный непосредственно официальным примером IoT Core GPIO для Windows :
// Open GPIO 27 - CLK (clock generator signal) listener
CLK2 = gpio.OpenPin(27);
CLK2.SetDriveMode(GpioPinDriveMode.Input);
CLK2.ValueChanged += EdgeDetCLKOnValueChanged; // event handler
Обработчик событий выглядит следующим образом:
private void EdgeDetCLKOnValueChanged(GpioPin sender, GpioPinValueChangedEventArgs args)
{
if (args.Edge.Equals(GpioPinEdge.FallingEdge))
CLKedge = F_; //F_ == 0b11110000;
if (args.Edge.Equals(GpioPinEdge.RisingEdge))
CLKedge = _R; //_R == 0b00001111;
}
По сути, он просто устанавливает необычный токен, указывающий, какое ребро произошло.Он используется и очищается в методе, отвечающем за связь init.В основном я использую (я хотел бы использовать) такие обработчики для события ValueChange для пары других выводов.
Все они (токен, экземпляр GpioPin, обработчик событий и методы init) являются членами одного и того же открытого класса SimpleSerialProtocol. Здесь можно проверить весь код.
ПРОБЛЕМА, когда обработчик событий подключается и начинает срабатывать (потому что он работает), сборщик мусора сходит с ума и начинает слишком часто вылетать,в той степени, в которой оно замораживает все приложение.
- В верхнем поле отображается использование памяти, а желтые точки представляют случаи GC.
В этом проекте у меня есть селектор частоты CLK, и когда я выбираю низкую частоту (около 112 Гц), приложение работает сорта (GC срабатывает каждые 5-10 с), но иногда кадр данных, который я получаю от АЦП, получаетиспортилКогда я начинаю выбирать более высокие частоты, GC появляется все чаще и чаще (что имеет смысл, так как событие ValueChanged на GpioPin чаще возбуждается) до точки, где приложение зависает и вылетает.Я также могу проиллюстрировать это поведение с помощью этого изображения:
, взятого из теста в VisualStudio Performance Profiler.Он представляет около 30 секунд простоя приложения, слева присутствует обработчик ValueChanged (подписан), справа он закомментирован.Кроме того, на левом рисунке все остальные действия отфильтрованы, так что они могут как-то соответствовать и показать степень хаоса, вызванного сборщиком мусора, представленным оранжевыми полосами.
Я очень запуган этой проблемой, как я себе представляювсе вещи для сборки мусора бесконечно сложны.Не могли бы вы помочь мне устранить это, явно ошибочное поведение?Извините за подробное описание, я надеюсь, что оно настолько компактно, насколько это возможно, и, тем не менее, понятно.
РЕДАКТИРОВАТЬ
Я сделал несколько снимков из инструмента использования памяти
и отображается состояние кучи и суммированной разницы в количестве объектов / ссылок между этими снимками (я сделал первый на холостом ходу перед подпиской обработчиков на ValueChanged и еще четыре на протяжении различныхоперации, которые используют эти обработчики).
В списке различий большинство различий находится в RuntimeType объектах, и когда я выбираю этот элемент для более подробной информации, эта фраза появляется надlist:
Object [] (закрепленный доступ) (отображается на польском языке, поэтому моя попытка перевести его может быть ошибочной).
Сейчас нет,однако, что это может означать, и я не могу найти более конкретной информации об этих объектах (например, некоторые ссылки на мой код).