What a nice RTFM!

I have some fond memories of working with a capable C programmer on an Atmel Butterfly as a platform.  I relied heavily on the data sheet to understand the capability of the ATmega169 at the time and several times was able to identify paths forward by doing so. We were squeezing a lot of functionality out of this little chip which was probably not wise though I thought it was quite fun.

I came to appreciate those data sheets which I found at first intimidating but later I began to really appreciate them and the excellent writing in them.

I have not touched embedded stuff for a few years now but I stay on this list just for such posts.  Keeps my gray matter functional.

Ian

On 6/9/19 4:42 PM, Erich Wälde wrote:
Dear Jan,

allow me to observe the following things:

// enable SPI.Master
   SPI.setDataMode(SPI_MODE0);
   SPI.setBitOrder(MSBFIRST);
   SPI.setClockDivider(SPI_CLOCK_DIV4);
   SPI.begin();
The words and the concepts behind them are documented in great
detail in the datasheet of your controller. You mentioned
"arduino" at the beginning of this thread, so I *guess*
you are using a "atmega328p" controller.

http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf
yes I know, this is a big thing with >600 pages. And no, noone
expects you (or anyone else) to learn all of this by heart.
However, I do expect you to read the relevant sections.

The table of contents will suggest you look at chapter 19. SPI
--- Serial Peripheral Interface.

SPI is a piece of hardware, which will do the clocking and byte
transfers for you, no need to bit bang (i.e. setting pins high
and low) it yourself. The price for this nicety is that you need
to configure it properly.

- is the first bit in transfer the *most* or *least* significant
   bit?
- is the data valid at rising of falling edges of the clock?
   (19.4 Data Modes)
- which speed should the interface be clocked with?
- is a transfer currently ongoing or can I write the next Byte
   to register SPDR
and so on.

I can give you my routines, but I guess you will be unable to
use them if you do not understand these details, I'm afraid.


So any spi transfer goes through these steps:

setup bitorder, data mode, speed, maybe more (once)
turn the spi module on (once or before every tx session)

for every byte to transfer
- fetch the next byte from a meaningful place
- write the next byte to SPDR
- wait until tx has completed
- read the answer byte from SPDR (yes the same register!)
- store the answer byte in a meaningful place
repeat until no bytes are left to transmit.

c!@spi will do one transfer: it sends the lower byte of the top
of stack element to spi and places the result byte on the stack
afterwards. It handles the body of the loop outlined above.

!@spi will transfer 2 bytes == 1 word instead.

it is "!" store "@" fetch spi, every transmit ("!") will provide
an answer ("@").

That is why you want "!@spi" and "c!@spi" compiled into your
AmForth.

The example at
http://amforth.sourceforge.net/TG/recipes/SPI.html
might be a bit terse, however, it does point you to

trunk/avr8/lib/hardware/spi.frt
which defines words and constants for all the details.

trunk/avr8/lib/hardware/mmc.frt and
trunk/common/lib/hardware/mmc-test.frt
create an elaborate example, how to use the spi interface.


As others have said: the datasheet is your friend, and once you
understand, how to configure a certain piece of the controller
for your project, setting the appropriate bits in its Control
Register are not a big deal any more. The big deal is to find
out, which bits to set. The C libraries do all of this for you,
but you need to read the source and the datasheet to understand,
why it is working. Once you understand this for SPI you will
find that all the other parts of the controller are operated
similarly: there is one or a few control registers, a set of
data registers, a few flag bits here and there, and possibly a
connection to one or few interrupts, to make all of this work.


Also, the amforth source is full of examples and use cases. If
you are on Linux, grep and find are your friends to find
relevant places. If you are on MacOS or Windows, there are other
tools to search file names or content, I'm sure.


So, don't give up too soon. We have all been through this stage.

Cheers,
Erich


What to do with

\ check SPI device datasheet for mode settings
: spi.setmode ( spi-mode -- )
  spi.mode pin!
;

With kindly regards,

Jan





Op 8 jun. 2019, om 20:45 heeft Matthias Trute 
<mtr...@web.de<mailto:mtr...@web.de>> het volgende geschreven:

Hi,

You can also use the following words to avoid c!@spi, which is
missing from the preassembled package for the Arduino:


\ send a byte, ignore received byte
: c!spi ( c -- )
    SPDR c! ( c addr -- )
;

  \ receive a byte, send a dummy one
: c@spi ( -- c)
    0 SPDR c! 1 ms SPDR c@
;

SPDR is a constant holding the address of the SPI data register (&78)

Thanks, I've added some comments to the spi.frt file.

Matthias


_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net<mailto:Amforth-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/amforth-devel


_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

--
May the Forth be with you ...


_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel


_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Reply via email to