Ребята,

Я смотрел на LIB VS1003 и подумал, что было бы неплохо попытаться воспроизводить и mp3 с SD -карты, но вместо того, чтобы запустить SD и MP3 -плеер VS1003 на одном и том же SPI, я подумал, что изменил бы VS1003 LIB чтобы я мог добавить дополнительный аргумент в конструктор для экземпляра устройства / класса SPI, который не выполняется SPI

Тем не менее, я разбиваю 2 выпуска

Я тоже не заинтересован в стиле кода, либо,... Беги со мной в этом.

Сначала добавьте аргумент для _spi и по умолчанию в SPI

Vs1003 (uint8_t _cs_pin, uint8_t _dcs_pin, uint8_t _dreq_pin, uint8_t _reset_pin, Spiclass _spi = spi);

Затем установите участник my_spi с этим в конструкторе.
#define SWODEBUG 1

Роджер, я думаю, что проблема конструктора в этом случае может иметь решение, но мне это не нравится.
Вы можете установить приоритет конструктора SPI до более низкого числа (более высокий приоритет), чем конструктор библиотеки VS1003.
Но это означает, что необходимость изменить обе библиотеки, чтобы добавить приоритетные номера.
Если мы начнем по этому пути, назначая разные приоритеты каждому конструктору, мы можем получить слишком много из них, а затем пройти проверку библиотек, чтобы найти то, что имеет более высокий приоритет, чем что -то другое.
Либо мы тщательно присваиваем приоритеты всему, в зависимости от того, что зависит от того, что еще, либо лучше не пытаемся использовать устройства в конструкторе.
Это только мое мнение. Теперь я уверен, что если вы установите приоритет для тех, кто делает VS с самым низким приоритетом, это должно решить проблему для этого случая. Мне просто не нравится это делать.

Кроме того, другой вариант может заключаться в том, чтобы изменить конструктор библиотеки VS, поэтому он экземпляет сам SPI -порты, прежде чем пытаться что -то еще сделать

Виктор

Я бы предпочел не идти по пути назначения приоритетов.

Я найду другой способ.

На данный момент я не уверен, является ли my_spi NULL, когда называется конструктор VS1003, или что -то внутри SPI, которое недопустимо.

Думая об этом, я даже не уверен, что бы сделал компилятор, когда я назначил my_spi = spi

я.эн

Я предполагал, что my_spi фактически является указателем на объект класса, как и SPI, но я немного туман в этом, как обычно, если бы я не кодировал Arduino, я всегда использовал бы новый, чтобы создать урок, который возвращает указатель. класс, который делает все намного более очевидным.

Кстати, есть и что -то еще странное, что висит компилятор

Если LIB нуждается в SPI, он может включать SPI.H в его заголовка или CPP, ну, кажется, нужно сделать это, но если я опускаю, включая SPI.H Из эскиза, компилятор, кажется, висит при составлении рассматриваемой LIB.
Я предполагаю, что это причуда Arduino, но кажется странным повесить компилятор.

Rogerclark написал:
Если LIB нуждается в SPI, он может включать SPI.H в его заголовка или CPP, ну, кажется, нужно сделать это, но если я опускаю, включая SPI.H Из эскиза, компилятор, кажется, висит при составлении рассматриваемой LIB.
Я предполагаю, что это причуда Arduino, но кажется странным повесить компилятор.

Вы можете попробовать размещение нового. Я взял свой класс ActiveLowled и использовал его с новым размещением в коде ниже. Этот класс выполняет вызовы pinmode () в своем конструкторе. Если вы использовали размещение новое, как я сделал ниже, конструктор не вызван до первого светодиода ().Blink () звонок. Конечно, есть накладные расходы на это, и он использует странный синтаксис для доступа к светодиодному объекту. Единственным преимуществом для этого является то, что память, связанная с классом, является частью сегмента данных, а не кучи, поэтому вы не собираетесь сталкиваться с проблемами управления память. Если это не подходит, когда вы компилируете, это скажет вам.
#define SWODEBUG 1

Единственным преимуществом для этого является то, что память, связанная с классом, является частью сегмента данных, а не кучи, поэтому вы не собираетесь сталкиваться с проблемами управления память. Очень, очень интересно!

Луча

Mrburnette написал:Очень, очень интересно!

На самом деле я забираю это, это заканчивается в .раздел BSS так, как я объявил. Что все еще лучше, чем куча.

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

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

Я склонен скопировать папку класса SPI и переименовать ее в SPI_STM и удалить глобальное экземпляр

На самом деле, я бы действительно предпочел назвать это чем -то более полезным, но SPI_NOGLOBAL - это, возможно, немного длинное для имени (но, возможно, нет)

Тогда, если кто -то хотел, чтобы SPI был устройством SPI 2, они могли бы объявить это сами

Spiclass SPI (2)

Хотя я признаю, я не уверен, будут ли другие либералы Arduino, которые используют SPI как глобальный.

Мне нужно попробовать это. Но, возможно, внешность в заголовке SPI может остановить другие либера.

Рик Кимбалл написал:На самом деле я забираю это, это заканчивается в .раздел BSS так, как я объявил. Что все еще лучше, чем куча.

Просто быстрое обновление.

Если создать создание класса VS1003 Inside Setup, он отлично работает на канале SPI 1 и SPI -канале 2.
#if (SWODEBUG > 0) SWO_Channel SWO; #define SWO_ErrLog(...) \ SWO.printf(__VA_ARGS__); \ SWO.printf("LINE: %d, FUNCTION: %s, FILE: %s \r\n", __LINE__, __FILE__, __FUNCTION__); #else /* Not DEBUG */ #define SWO_ErrLog(...) #endif

ХОРОШО
Я думаю, у меня есть обходной путь для этого, но я признаю, что не уверен, почему это работает.


Если я использую это в качестве объявления конструктора, это не работает
dfu-util 0.9 These binaries are for Microsoft Windows 64-bit They were built using MinGW-64 from MSYS2 with gcc 5.3.0, for build instructions please see: http://dfu-util.sourceforge.net/build.html Source code: https://sourceforge.net/p/dfu-util/dfu-util/ci/v0.9/tree/ dfu-util.exe requires libusb-1.0.dll. The shipped libusb-1.0.dll is built from libusb 1.0.20 and can be replaced with another version if desired. dfu-util-static.exe has the libusb 1.0.20 code embedded and runs without any libusb-1.0.dll. Notes: 1. To work around a bug in gcc/mingw, a small patch was applied, see https://sourceforge.net/p/dfu-util/tickets/13/ 2. The dfu-util-static.exe includes libusb that has been patched to work around a silicon bug in STM32F42X devices: https://github.com/axoloti/axoloti/blob/master/platform_osx/src/libusb.stdfu.patch 2016-02-11 Tormod Volden