DxCore
DxCore copied to clipboard
SpenceKonde
Add automated tests of AVR DD-series parts
I suspect this item is mostly intended to cover compilation. But:
I feature creeped my in-design calibration rig to also support running automated tests between a pair of MCUs. I'm about half done with the hardware design.
Essentially two copies of an MCU are connected mostly pin-to-pin through current limiting resistors. Except a UART and an i2c bus are connected in ways that will work. (the two targets are on pluggable daughterboards that control the pin assignment and allow replacement/changes to target mcus - the test socket for the calibration use is one such pluggable board).
There is still a separate control MCU that is configured to be able to program both and observe much of what happens.
The intent is to program the code to be tested to one and a test harness to the other that provides whatever stimuli are needed and decides whether the test passes or fails to the other.
This is still a work in progress and is very much one of those projects that may or may not ever get done. But the plan is to have a few of these set up (different MCU types) connected to a raspberry pi to allow me to run automated regression tests against my code.
If this is something you are interested in I can think about an interface to submit jobs remotely - might be cool to run a limited test harness for mTC and DxCore in an automated way (that actually runs tests on the chips). On the Dx side need to think about how to handle the shitty endurance but as long as it isn't a weekly occurrence I don't care if I have to occasionally swap DD14s.
This is something I have thought about ever since I started using CI. I infect made some crude test boards (thought hry were aimed at testing assembed product before sale) to play with this and assembled a half dozen, but the head of DxCore hasn't compiled even Bare Minimum for about a month so I haven't tried them :-/
The tests IMHO can be focused very tightly on the stuff that we "can't" test with just compile-tests.. that is, the peripherals - the USART, the CCL and evsys (those have had so many problems - all due to bugs in my code amd to a lesser extent @mcudude's code where we are trying to make three implementations of the event system present the same API) (his code has less bugs befcause he's focused om MegaCoreX/ Tiny0/1 is drastically different, and DX/tiny2 are different and EA will be different). A test that was built using the libraries IMHO is the way to go, rather than directo register writes for each kind of chiop. We care more about what our libraries tell the registers to do and whether that matches the behavior of everything else/
On Mon, Aug 15, 2022 at 11:57 AM ObviousInRetrospect < @.***> wrote:
I suspect this item is mostly intended to cover compilation. But:
I feature creeped my in-design calibration rig to also support running automated tests between a pair of MCUs. I'm about half done with the hardware design.
Essentially two copies of an MCU are connected mostly pin-to-pin through current limiting resistors. Except a UART and an i2c bus are connected in ways that will work. (the two targets are on pluggable daughterboards that control the pin assignment and allow replacement/changes to target mcus - the test socket for the calibration use is one such pluggable board).
There is still a separate control MCU that is configured to be able to program both and observe much of what happens.
The intent is to program the code to be tested to one and a test harness to the other that provides whatever stimuli are needed and decides whether the test passes or fails to the other.
This is still a work in progress and is very much one of those projects that may or may not ever get done. But the plan is to have a few of these set up (different MCU types) connected to a raspberry pi to allow me to run automated regression tests against my code.
If this is something you are interested in I can think about an interface to submit jobs remotely - might be cool to run a limited test harness for mTC and DxCore in an automated way (that actually runs tests on the chips). On the Dx side need to think about how to handle the shitty endurance but as long as it isn't a weekly occurrence I don't care if I have to occasionally swap DD14s.
— Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/issues/326#issuecomment-1215228813, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEWYGKPIAWJP4C6346Y3VZJSHVANCNFSM56RFPDJQ . You are receiving this because you authored the thread.Message ID: @.***>
--
Spence Konde Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore https://github.com/SpenceKonde/ATTinyCore: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore https://github.com/SpenceKonde/megaTinyCore: Arduino support for all post-2016 tinyAVR parts! DxCore https://github.com/SpenceKonde/DxCore: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: @.***
These tests are now in. They're not all passing, but it's mostly stupid stuff in libraries thats broken.