Automated testing environment on real hardware

hackndev / zinc

The bare metal stack for rust

zinc.rs

Apache License 2.0

1k stars 100 forks source link

Automated testing environment on real hardware #195

Open farcaller opened 10 years ago

farcaller commented 10 years ago

A bunch of rtos code is hard to test without real hardware (e.g. https://github.com/hackndev/zinc/pull/194). Possible solution is to hook some board to CI (pyocd seem to be scriptable enough for that).

bharrisau commented 10 years ago

Agree. Though the first step is to endorse a platform. Do you have anything in mind that is easy to get plus has the debugging broken out? On 19/10/2014 4:45 pm, "Vladimir Pouzanov" notifications@github.com wrote:

A bunch of rtos code is hard to test without real hardware (e.g. #194 https://github.com/hackndev/zinc/pull/194). Possible solution is to hook some board to CI (pyocd seem to be scriptable enough for that).

— Reply to this email directly or view it on GitHub https://github.com/hackndev/zinc/issues/195.

farcaller commented 10 years ago

There's VTOR thing in cortex-m3 to remap vector table to ram, so we can boot any chip from ram.

On hardware; pyOCD-supported board should be best as that one is scriptable in python (vs. scriptable in gdb which is harder).

farcaller commented 10 years ago

So far the test idea looks this way:

each test gets linked into dedicated bin file where main() starts the test
upon test end, it must issue bkpt and test state in r0

Test is successful if there's a breakpoint hit and r0 is 0 (caveat: abort() in zinc hits breakpoint too). Test is failed on any other r0 value or timeout.

Should be simple to implement.

bharrisau commented 10 years ago

It would be nice if there was a dual chip reference board. One can be the usb-debug interface the other the target.

Plus when you want to test the USB-host, you can have the second chip reset and program the main chip, run the test, then reset back to normal.

It would be a nice dev board for high reliability stuff too. On 19/10/2014 5:49 pm, "Vladimir Pouzanov" notifications@github.com wrote:

There's VTOR thing in cortex-m3 to remap vector table to ram, so we can boot any chip from ram.

On hardware; pyOCD-supported board should be best as that one is scriptable in python (vs. scriptable in gdb which is harder).

— Reply to this email directly or view it on GitHub https://github.com/hackndev/zinc/issues/195#issuecomment-59664684.

farcaller commented 10 years ago

I have exactly that kind of board :wink:

bharrisau commented 10 years ago

Can I buy one somewhere? Sounds like a good board to bless as a zinc reference platform. On 19/10/2014 5:57 pm, "Vladimir Pouzanov" notifications@github.com wrote:

I have exactly that kind of board [image: :wink:]

— Reply to this email directly or view it on GitHub https://github.com/hackndev/zinc/issues/195#issuecomment-59665033.

farcaller commented 10 years ago

http://developer.mbed.org/platforms/mbed-LPC1768/, it's not exactly cheap though.

errordeveloper commented 10 years ago

I think that's exactly what mbed guys use pyOCD for... Although, I'm wondering if qemu wouldn't be sufficient for this specific purpose?

farcaller commented 10 years ago

qemu would be a really good option, but cortex-m support in qemu is poor to non-existent.

0xc0170 commented 10 years ago

@errordeveloper not exactly correct, but that's the main advantage of pyOCD. :wink:

I'll be glad to help out.