You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

58 lines
1.2 KiB

tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project's "USB Gadget Zero" idea, and in theory, this should be testable with <kernelsrc>/tools/usb/testusb.c but... not yet. It's tricky to set that up and poorly documented, so we've got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic "rules.mk" is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it's working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project's makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
#include <stdint.h>
#include <libopencm3/cm3/common.h>
#include <libopencm3/cm3/memorymap.h>
#include <libopencm3/cm3/itm.h>
#include "trace.h"
void trace_send_blocking8(int stimulus_port, char c)
{
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
if (!(ITM_TER[0] & (1<<stimulus_port))) {
return;
}
while (!(ITM_STIM8(stimulus_port) & ITM_STIM_FIFOREADY));
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
ITM_STIM8(stimulus_port) = c;
}
void trace_send8(int stimulus_port, char val)
{
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
if (!(ITM_TER[0] & (1<<stimulus_port))) {
return;
}
ITM_STIM8(stimulus_port) = val;
}
void trace_send_blocking16(int stimulus_port, uint16_t val)
{
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
if (!(ITM_TER[0] & (1<<stimulus_port))) {
return;
}
while (!(ITM_STIM16(stimulus_port) & ITM_STIM_FIFOREADY));
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
ITM_STIM16(stimulus_port) = val;
}
void trace_send16(int stimulus_port, uint16_t val)
{
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
if (!(ITM_TER[0] & (1<<stimulus_port))) {
return;
}
ITM_STIM16(stimulus_port) = val;
}
void trace_send_blocking32(int stimulus_port, uint32_t val)
{
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
if (!(ITM_TER[0] & (1<<stimulus_port))) {
return;
}
while (!(ITM_STIM32(stimulus_port) & ITM_STIM_FIFOREADY));
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
ITM_STIM32(stimulus_port) = val;
}
void trace_send32(int stimulus_port, uint32_t val)
{
tests: usb: gadget0 compatible interface (stm32f4) This introduces the first firmware setup specifically for automated testing. Based heavily on the linux kernel project&#39;s &#34;USB Gadget Zero&#34; idea, and in theory, this should be testable with &lt;kernelsrc&gt;/tools/usb/testusb.c but... not yet. It&#39;s tricky to set that up and poorly documented, so we&#39;ve got our own tests instead. Instead, we include a set of python unit tests using pyusb. These currently only test a basic core subset of functionality, but have already been very helpful in finding latent bugs. In this first stage, we support only the stm32f4 disco board, (MB997) and FullSpeed USB devices. A generic &#34;rules.mk&#34; is introduced to support multi platform builds. (See below) Some basic performance tests are included, but as they take some time to run, you must manually enable them. See the README for more information NOTE! Only the source/sink functional interface is supported, loopback will require some comparision with a real gadget zero to check exactly how it&#39;s working. FOOTNOTES 1: This introduces a rules.mk file that is arguably substantially simpler[1] for re-use, and then uses this rules.mk file to support multiple target outputs from the same shared source tree. Less path requirements are imposed, and less variables need to be defined in each project&#39;s makefile. A separate bin directory is created for each project. All useful settings and configurations imported from the original library rules file. cxx support untested, but lifted from the original library rules file. [1] Than the file in the libopencm3-examples repo it is loosely based on.
9 years ago
if (!(ITM_TER[0] & (1<<stimulus_port))) {
return;
}
ITM_STIM32(stimulus_port) = val;
}