Now we have a hierarchical structure of test Suites and test cases (=functions) we should allow them to be executed separately.
proposed command: test <name> <idx>
where the optional 'name' identifies the test suite and with idx you could call a single test function within that suite.

to show whats available we could add either another 'listTests' cmd or make '-?' as special par1.

... optionally make the trivial cases (buffer of primitives with known size e.g. chars) faster.

I think it will benefit to use *x = *y compiler provided copy of variables iso memcopy used to insert the general purpose (void *) / sizeof(structureUsed) element in all trivial cases using elements with size 1,2,4.

with current version there are 2 Problems for new projects:

1. as we removed the DEBUG configuration of the library you heve to replace the lib search path of your Linker Config to get it found correctly (under TestConfig_1 or TestConfig_2)

2. The generated Project code makes a Call to Chip_SystemInit() which we romoved on some stage 😞 . -> provide a (dummy) call and make doku how to initilize a specific Hardware Project.....

This is somehow related to #7 but to put it more general:

The MCUXpressos debug cycle depends on a lot of settings and configuration for the used debug probe and sets up the link-server, detection and configuration of the CMSIS-DAP probe, the gnu gdb process and manages somehow to load the built image file to the target and start it with a set break point in main() ......

Working with earlier versions and now with my version of MCUXpresso IDE v11.1.1 [Build 3241] [2020-03-02] I repeatably experience following scenario:

The Terminate-Build-Debug button from quickstart menu works without problem (or doing everything with manual extra steps also works...) but after flash was loaded and main() break point reached - the following Run does not find all HW-Configs of the target chip (LPC1769 in my case) set up as expected. This is especially annoying when playing around with some basic configuration options (e.g. changing and assigning timer match registers and irq settings) because you can never be sure which (hw/gpio?-)configuration you really see while debugging!

The only consistent workaround to avoid such confusions I found until now is to manually RESET or power cycle the target board, which is both not very user friendly during development.

Any findings on that issue and settings to try out appreciated ....

Make the code currently under folder ai2c ready to be moved into ADO Lib.

• rethink job queue structure together with SPI and DMA SPI code in ADO (more abstract callbacks?, common worker queue? )
• add 'Bus select' GPIO pin in a way to be usable with OBC EM2 hardware

with current version there are 2 Problems for new projects:

1. as we removed the DEBUG configuration of the library you have to replace the lib search path of your Linker Config to get it found correctly (under TestConfig_1 or TestConfig_2)

2. The generated Project code makes a Call to Chip_SystemInit() which we removed on some stage 😞 . -> provide a (dummy) call and make doku how to initialize a specific Hardware Project.....

• make possible to use more than 1 chip (select)
• remove (dummy) Rx byte when TX only. (Always writes an additional 0xFF on the end of the block!)

Running all test one of 4 codes tests fails with:

>A test String writing something to the output cons f:2.200000 i:55
Heap diff: 56 ( H: 24 - 80)
3/4 Tests ok
Error in .test_systemconfigs.c/sys_testPrintFNotusingHeap() at 71:
Wrong Heap size used!?

where the numbers on heap measurement differ on subsequent calls.

Try to make this test independent of heap history.

If you execute
setTime 2020 7 31 10 0 0

you get the time output as UTC: "0.8.2020 10:00:xx"

Both LPC1769 and LPC1768 microcontrollers are in use but the LPC1768 supports max. 100 MHz as CPU clock frequency (reliably). To prevent issues as unreliable UART communication and other clock related problems my suggestion is to change the clock rate initialization to 96 MHz instead of 120 MHz.

As far as I have seen this should be easily possible by removing line

resulting in 96 MHz CPU clock.

take the ado_mram module as last (most advanced) example of an ado module having init / main loop state machine and separation of CLI from binary commands.
more improvements missing:

• How to avoid the MRAM_CHIP_CNT define and provide means for memory assignment for different HW configurations from Library User.
• develop 'general OO-Instantiation' mechanism for this kind of memory initializations from outside the lib code.......
• 'abstract' usage of EventLogger interface for error loggings.

• make it possible to use more (2?) instances of SDC modules to be used with both SSP0, SSP1 at the same time.
  (or >2 with seperate CS callbacks!?)
• make the feature - use SSL automode/use CS callback an init choice per module instance.

Since I wrote the 4 performance tests for the ring-buffer, I experienced different results with each build/debug cycle of the software. I slowly increased the accepted times to be used in the test but there are always builds/runs which are out of this accepted test tolerances.

Normal Values of this test:

Push/pop test (char): 8313/29688 us.
Push/pop test (ptr): 8756/32501 us.

This still shows an error because currently the test checks for 8500/30100 and 8900/32400 us.

But now (after experimenting some settings in the debugger config...) I get crazy long values like:
Push/pop test (char): 19754/65939 us.
Push/pop test (ptr): 22889/70940 us.

At this moment I have a image where when I disconnect the debug session, the values change back to normal ones. But this behavior is somehow unpredictable. I do not know now what causes this and whats the dependencies to the MCUXpresso build/debug settings.

To test and use SWO trace and its 'ITM Console' with a SWD/SWO compatible probe make available different SystemInit() variants.
Additonal to current LpcExpresso1769Init() we could think of using other board variants to be switched by commenting the correct one in sysinit.c line 50.
....

In order to avoid buffer copy and duplication for MRAM Write jobs we could/should provide a version of the scattered DMA which suports TX1-TX2 blocks to get the command header and the data from different memory sources.

-> generalizations of this DMA usage should also make code more readable 😄 as I didn't understand my own coding for fixing #12 🤣 !!!

The CRC8 implemented here does give different result to the crc8 needed in Climb thruster communications -> analise and make common CRC8 routine with optional Polynoms (like CRC16).

Summary says all.

Make the TX buffer a feature which can be moved to the ADO LIB.

Current versions are coded for Debug-If, Thruster, GPS

Cutting out the CLI commands did move the generation of CRC (and start data token) to the CLI. It should be relocated to be in binary mod again!

Make a board routine to fully configure ALL aspects of the chip hardware ( timings, GPIO mux, enable disable of all hw units and so on ...) without relying on any default values after RESET. Maybe this could solve #8 ...