Я занимаюсь разработкой на c ++ для моей платы STM32F3 Discovery и использую std :: deque в качестве очереди. После попытки отладки моего кода (непосредственно на устройстве с ST-link или в симуляторе) код в конечном итоге останавливается на точке останова, даже не вводя мой код в main (). Тем не менее, SystemInit () настраивает плату просто отлично ..
Я проследил это поведение до использования push_back () (и push_front), поскольку комментирование его из кода решает проблему. Через дизассемблирование я обнаружил, что после его использования выполнение останавливается в команде BKPT с точкой останова и не будет двигаться дальше после возобновления выполнения. Эта инструкция является частью вызова _sysopen () с путем вызова:
__main -> __scatterload -> __scatterload_null -> __rt_entry -> __rt_lib_init -> __rt_lib_init_atexit_1 -> _initio -> freopen -> _sysopen
Что меня интригует, так это призыв к _initio
, который отсутствует, если push_back не используется, потому что нет __rt_lib_init_atexit_1
, Введение push_back также увеличивает размер кода с 10 кБ до 34 кБ.
Может ли это быть результатом неправильной конфигурации или я должен попробовать другую IDE? У меня нет идей.
У меня такая же проблема. Я узнал, что это как-то связано с так называемым «полухостингом» и
что я должен построить с моим файлом проекта ‘retarget.c’, который содержит определения
функции типа ‘_sys_xxxx ()’, которые являются целевыми функциями уровня драйвера
(многие версии ‘retarget.c’ являются частью Keil-MDK и также могут быть найдены в сети).
Так что я сделал, но затем компоновщик сгенерировал ошибки, подобные этой:
Error: L6200E: Symbol _sys_open multiply defined (by arm_xxx_lib.o and retarget.o)
Error: L6200E: Symbol _sys_close multiply defined (by arm_xxx_lib.o and retarget.o)
...
Я решил эту проблему, отредактировав оригинальный файл «retarget.c», чтобы функции, определенные в нем,
переопределите те в библиотеках Keil-MDK. Новый retarged.c находится здесь:
#include <stdio.h>
#include <rt_misc.h>
#pragma import(__use_no_semihosting_swi)
#include <rt_sys.h>
extern void $Super$$_sys_open(void);
FILEHANDLE $Sub$$_sys_open(const char *name, int openmode)
{
return 1; /* everything goes to the same output */
}
extern void $Super$$_sys_close(void);
int $Sub$$_sys_close(FILEHANDLE fh)
{
return 0;
}
extern void $Super$$_sys_write(void);
int $Sub$$_sys_write(FILEHANDLE fh, const unsigned char *buf,
unsigned len, int mode)
{
//your_device_write(buf, len);
return 0;
}
extern void $Super$$_sys_read(void);
int $Sub$$_sys_read(FILEHANDLE fh, unsigned char *buf,
unsigned len, int mode)
{
return -1; /* not supported */
}
extern void $Super$$_ttywrch(void);
void $Sub$$_ttywrch(int ch)
{
char c = ch;
//your_device_write(&c, 1);
}
extern void $Super$$_sys_istty(void);
int $Sub$$_sys_istty(FILEHANDLE fh)
{
return 0; /* buffered output */
}
extern void $Super$$_sys_seek(void);
int $Sub$$_sys_seek(FILEHANDLE fh, long pos)
{
return -1; /* not supported */
}
extern void $Super$$_sys_flen(void);
long $Sub$$_sys_flen(FILEHANDLE fh)
{
return -1; /* not supported */
}
extern void $Super$$_sys_exit(void);
long $Sub$$_sys_exit(FILEHANDLE fh)
{
return -1; /* not supported */
}
С этой версией ‘retarget.c’ компоновщик был удовлетворен, и моя программа работала без проблем.
Может быть, это поможет вам.
Попробуйте проверить, содержит ли scale_buffer какой-либо элемент (scale_buffer.empty()
) до звонков .back()
а также .front()
: вы, вероятно, читаете и пишете какую-то фигню, что делает deque недействительным, подготавливая почву для сбоя при вызове push_back()