высокоскоростная трассировка

If you can use an output port on the microcontrollers without disturbing other hardware too much you can output the current task number and capture it with a logic analyzer.

Somewhat more light-weight than the ARM ETM highlighted by Johan, the MIPI System Trace Protocol has been designed for just this sort of trace activity. It is designed for instrumentation trace, and typical implementations offer around 500 Mbit/s of trace bandwidth over a four-bit port.

However, it is unlikely your board has support for it. :-( Also, you need a trace receiver, which again can cost the price of a small car (Lauterbach have one).

Я не знаю, какую платформу вы используете, но ...

У ARM есть блок под названием ETM , который решает вашу проблему. И с помощью хардкорного отладчика от Lauterbach вы можете использовать этот блок.

Обратной стороной является высокая стоимость, примерно такая же, как у маленькой новой машины :)

И я не знаю если в вашем оборудовании есть блок ETM ...

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

Это звучит так, как будто вы выполняете блокирующую запись в последовательный порт (приношу свои извинения, если я ошибаюсь.)

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

При 57 600 бит / с, 8-N-1, вы могли бы передавать вверх до 5760 байт в секунду. Если ваш переключатель задач генерирует 2-байтовую метку времени плюс 1-байтовый идентификатор задачи, то вы можете отслеживать до 1900 переключений задач в секунду. Но вы можете захотеть кадрировать его, например, используя COBS , что будет означать 5 байтов на запись, так что вы можете отслеживать до 1,

Сначала посчитайте, сколько переключателей задач у вас будет, и сравните со скоростью вашего последовательного порта. Может просто нет возможности запихнуть такой объем данных? Считайте, что

• USB - до 480 Мбит / с
• RS485 - должен дать вам от 100 Кбит / с до 35 Мбит / с
• I2C - дает около 100 Кбит / с

Если серийного номера достаточно, то, может быть, пойти с кешем? Сначала запись в память и отдельная задача - получение данных из памяти в блоках, отправленных по последовательному каналу. Ищите такие вещи, как круговая буферизация , чтобы избежать блокировки.

Вам нужно поведение в реальном времени при запуске трассировки? Я имею в виду, можно ли войти в ОЗУ до тех пор, пока буфер (почти) не будет заполнен, а затем войти в критическую секцию, предотвращающую переключение задач и обслуживание прерывания, а также сброс буфера по последовательной линии. Это заблокирует работу приложения на некоторое время, но в зависимости от выполняемого вами теста это может быть приемлемым. Любая трассировка в реальном времени через последовательный порт, USB, ... будет влиять на поведение приложения, поэтому нет уверенности в том, что то, что вы измеряете, имеет значение.

Еще одна вещь, которую вы можете сделать (если вы еще этого не сделали), - это сделать ведение журнала должно быть как можно меньше, например: 1 байт на переключатель задачи, причем старший байт - это идентификатор старой задачи, а наименее значимый - это идентификатор новой задачи. Таким образом вы сможете охватить множество переключателей задач в 512 КБ памяти.

• И когда я пытаюсь записать в ОЗУ, он overflows ~~

Что вы регистрируете и какой размер буфера вы разрешаете? Не зная, как вы это реализовали, трудно дать совет, но, вероятно, вы можете многое сделать для оптимизации ведения журнала в памяти.

Если при каждом переключении контекста вы регистрируете идентификатор задачи и отметку времени (скажем, 3 байта на событие), вы должны получить 341 переключение контекста на килобайт. Во многих системах это будет значительный период, и помните, что это всего лишь 1 КБ буфера. Если вы также регистрируете прерывания, это может быть дороже, как и регистрация всех системных вызовов, а не только переключения контекста. Возможно, вы могли бы реализовать фильтр в журнале, чтобы он регистрировал только задачи или интересующие события. Вы также можете реализовать триггеры событий, чтобы зарегистрированные данные автоматически сбрасывались на ваш последовательный порт при возникновении такого события (и когда произошло интересующее событие, чтобы процесс передачи не мешал вашему расследованию). Вы также должны реализовать буфер как кольцевой буфер, чтобы вместо переполнения

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