Closed morbos closed 6 years ago
Hi @morbos,
What I would do is to change the Send_8bit_Mode
procedure to use a different hardware mapping than This.Periph.DR.DR
. For example:
procedure Send_8bit_Mode
(This : in out SPI_Port;
Outgoing : HAL.SPI.SPI_Data_8b)
is
[...]
Data_8bit : UInt8 with Volatile, Address => This.Periph.DR.DR'Address;
begin
[...]
while Tx_Count > 0 loop
[...]
Data_8bit := Outgoing (Index);
[...]
end loop;
[...]
end Send_8bit_Mode;
This should force the compiler to use 8-bit writes.
HI Fabien,
That works! Slight mod to make it happen though:
Data_8bit : UInt8 with Volatile, Address => This.Periph.DR'Address
Without that omission of the second DR, it does some odd 16bit sign ext and leaves the address as a ram local.
Thanks!
Hedley
Cool! Don't hesitate to submit a fix ;)
On the F7 and L4 the SPI clock trains length seems to be determined by the greater of this logic:
1) The DS[3:0] field 2) The size of the instr used to read/wr (ld/st, ldh/sth, ldb/stb)
A new L4/F7 field is data size DS[3:0] = 7 (=8bits (chip default btw)) but use a 32bit st instr to write the DR reg... you will get the maximal 16 clocks.
Of course, the svd file has volatile, size => 32. Perhaps you can now see where this is going...
Unless the volatile write is for a size 8 bit field, the SPI clock train will get widened to 16 despite DS's smaller setting.
On the F1 and F4 the CR1 bit11 DFF field dictates clock train size. The DFF field has been changed in the L4 and F7 to CRCL int the RM but remains DFF in the svd(!).
As a workaround, I funnel all 8bit read/writes to a asm peek poke funcs. Ugly... but works.
tnx
Hedley