robertk66 / ado-chip-175x-6x Goto Github PK
View Code? Open in Web Editor NEWA basis Chip Library to use with MCUXpresso and LPC1769
License: MIT License
A basis Chip Library to use with MCUXpresso and LPC1769
License: MIT License
Make the code currently under folder ai2c ready to be moved into ADO Lib.
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.
... 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.
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 ....
with current version there are 2 Problems for new projects:
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)
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.....
with current version there are 2 Problems for new projects:
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)
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.....
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.
....
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 ...
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!
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.
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.
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.
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:
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.
Make the TX buffer a feature which can be moved to the ADO LIB.
Current versions are coded for Debug-If, Thruster, GPS
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.