Description
===========
Added thread model for function SingleTest::execute where for each target we
have separate thread.
Added new experimental feature. Currently we are only building in parallel
mbed SDK and libraries with dependencies.
Each MUT is flashed separately, but with this new feature we are able to
flash multiple boards at the same time and get results in parallel.
Test execution time is reduced by n where n is number of MUTs (MUT: mbed under
test).
using --parallel means that:
* separate thread will be spawned to build mbed SDK and dependencies (libraries)
for each unique target with all declared toolchains.
E.g:
Thread(n==1): LPC1768: ARM, uARM, GCC_ARM
Thread(n==2): K64F: ARM, GCC_ARM
Thread(n==3): NUCLEO_X: uARM
.
.
.
Thread(4): for toolchain in NUCLEO_Z[toolchains]
-> build mbed SDK
-> build libs
-> build project
-> run MUT testrunner
return test results for NUCLEO_Z[toolchain]
Done:
1. Added option --parallel.
2. Decoupled execute function so it can be run in parallel with other execute
functions.
3. Thread join via Queue, not Thread::Join() to avoid deadlocks or waits for
particular thread to finish.
4. All builds are in parallel, but because each target and library for each
toolchain have different directory we do not worry about building in
parallel and compiler collisions.
Missing:
1. No sync for 'print' (TODO).
2. No sync on test result structures - not needed because we only append to
them (?).
Experimental --parallel bugfix: self.test_suite_properties_ext dict was not
populated with target name.
Utilised Header file mask defines for clock set up's.
Tested default Teensy3.1 set up 3 and set up 0 (IRC mode).
Modes 1 and 2 require 8MHz crystal to test.
Added extra code for Teensy3.1 deepsleep wake up restore function.
For some reason the Teensy3.1 would not wake from deepsleep, problem with restoring clock set ups. Possibly due to the higher clock frequencies requiring additional PLL locking time.
Most of the SystemInit() code was required. Teensy3.1 has no debug facilities, USBSerial is not usable during deepsleep/wakeup processes. Unless anyone has a better option.
Fully tested with InterruptIn and soft WakeUp.
Deepsleep is not really viable for this platform as it is not possible to isolate the interface chip from the power supply, 2.5mA at best in deepsleep mode.
Added USB clock set divider up for 48MHz operation, corrected oscillator MCU loading capacitor defines.
External capacitors not fitted to the Teensy3.1 PCB.
USBSerial tested using official Hello World program for serial communication to pc terminal.
The OS_TASKCNT is set to 6, could be more.
The OS_SCHEDULERSTKSIZE is set to 112, could also be more.
The OS_CLOCK is set to 72000000 which matches the description on https://developer.mbed.org/platforms/ST-Nucleo-F303RE/
Cheers
I am not sure if it's the right SP, but the basic blink code works.
What does the SP stand for? Stack pointer?
Also, if you could tell me where to look for the correct address, I would.
I looked in the reference manual and the programming manual that STM provides, with no luck.
Cheers
The old code for the K20 PWM had an issue where calling for example
pwm.period and pwm.write after each other resulted in the pwm.write
function setting the pulsewidth with the value of the old pwm period.
This makes sure it waits until the latest pwm period is written before
it will do so.
Martin Kojtal
Przemek Wirkus
bcostm
0x4E656F00
Paul Staron
dominus97
Sissors
Mihail Stoyanov