[ell-i-developers] Re: First version of SPI transfer test pushed to feature-encX24J600-wip branch
- From: Eero Hakala <eero.k.hakala@xxxxxxxxx>
- To: ell-i-developers <ell-i-developers@xxxxxxxxxxxxx>
- Date: Mon, 15 Sep 2014 10:23:23 +0300
Compiles on Ubuntu (14.04) and gives same results too!!!
-eero-
On Sun, Sep 14, 2014 at 10:14 PM, Pekka Nikander <pekka.nikander@xxxxxx>
wrote:
> I just pushed the first version of an SPI transfer test:
>
>
> https://github.com/Ell-i/Runtime/commit/3afe5dac3ed60ffb2abbaa096fb75869b0884cac
>
> It includes a Python script that works for me on the Mac, when run with
> the 32-bit version of Python.
>
> This is very good news, since it indicates that we should get the emulator
> and RF framework finally integrated and pushed to master very soon. Sure,
> more work will be needed before everything will get polished, but tomorrow
> we will most probably have the framework for working TDD for the first time.
>
> Today, in my tests, the emulator run shows the status register reads
> during the 6-byte SPI transfer. It does not show the actual data written
> and read at the DR register, as that goes through a pointer which is not
> tracked by the emulator.
>
> Direct tracking of reads and writes through pointer write won't work,
> either, at least not easily (I tried). Hence, my currently plan is to make
> the SR polls to print out also the data. But that must wait for tomorrow.
>
> If you want to test it yourself:
>
> git clone https://github.com/Ell-i/Runtime.git
> cd Runtime
> git checkout 3afe5dac3ed60ffb2abbaa096fb75869b0884cac
> cd stm32/tests
> make # will take quite some time
> cd test_SPI_transfer
> python-32 test_SPI_transfer.py
>
> This should print out the following:
>
> GPIO:BSRR:value=0->=0
> GPIO:MODER:value=0->=40000000
> GPIO:AFR:value=0->=0
> GPIO:AFR:value=0->=0
> GPIO:MODER:value=0->=200
> GPIO:MODER:value=0->=200
> GPIO:AFR:value=0->=0
> GPIO:AFR:value=0->=0
> GPIO:MODER:value=200->=a00
> GPIO:MODER:value=200->=a00
> GPIO:AFR:value=0->=0
> GPIO:AFR:value=0->=0
> GPIO:MODER:value=a00->=a80
> GPIO:MODER:value=a00->=a80
> GPIO:BSRR:value=0->=0
> GPIO:MODER:value=40000000->=40000000
> GPIO:AFR:value=0->=0
> GPIO:AFR:value=0->=0
> GPIO:MODER:value=a80->=20000a80
> GPIO:MODER:value=a80->=20000a80
> GPIO:AFR:value=0->=0
> GPIO:AFR:value=0->=0
> GPIO:MODER:value=20000a80->=a0000a80
> GPIO:MODER:value=20000a80->=a0000a80
> GPIO:AFR:value=0->=0
> GPIO:AFR:value=0->=0
> GPIO:MODER:value=a0000a80->=a8000a80
> GPIO:MODER:value=a0000a80->=a8000a80
> GPIO:BRR:value=0->=0
> SPI:CR1:value=0->=4354
> SPI:SR:value=600->&(16b)600
> SPI:SR:value=600->&(16b)600
> SPI:SR:value=600->&(16b)600
> SPI:SR:value=600->&(16b)600
> SPI:SR:value=600->&(16b)600
> SPI:SR:value=600->&(16b)600
> GPIO:BSRR:value=0->=0
>
> If you inspect that carefully, you will see that some of the output and
> register access looks dubious. Hence, there is still work to be done even
> there.
>
> --Pekka
>
>
Other related posts:
