So far this is what I'm trying
static void spi_setup(void) {
/* INIT SPI GPIO */
gpio_mode_setup(GPIOB, GPIO_MODE_AF, GPIO_PUPD_NONE, GPIO13|GPIO14|GPIO15);
gpio_set_af(GPIOB, GPIO_AF5, GPIO13|GPIO14|GPIO15);
/* INIT SPI SS GPIO */
gpio_mode_setup(GPIOB, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, GPIO12);
gpio_set(GPIOB, GPIO12);
spi_set_master_mode(SPI2);
spi_set_baudrate_prescaler(SPI2, SPI_CR1_BR_FPCLK_DIV_64);
spi_set_clock_polarity_0(SPI2);
spi_set_clock_phase_0(SPI2);
spi_set_full_duplex_mode(SPI2);
spi_send_msb_first(SPI2);
spi_set_nss_high(SPI2);
spi_enable(SPI2);
}Then in main, I will do:
spi_send(SPI2, 0xDE);
spi_send(SPI2, 0xAD);
spi_send(SPI2, 0xBE);
spi_send(SPI2, 0xEF);
ok, I found a better example in the comments of the libopencm3 code https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/common/spi_common_all.c#L22
Bits are now twiddling!
@lgbeno also note that if you use
spi_xfer rather than spi_send then it will return once the byte has been completely sent. This can be important in controlling displays where they want you to send the control byte first, then set a pin to indicate data, and send data bytes next.
reading the docs between the two, it looks like xfer also reads back at the same time as write
although _send says that it blocks as well although not sure that this is true
right now with my current config, I can only get the port to work at 20MHz, (despite trying to config for 1MHz) need to slow it down for the chip that I want to talk to
It is the way SPI works, it always clocks in a byte at the same time it clocks out a byte. But the peripheral is double buffered, so if you tell it to send it will put the byte in the transmit buffer and start sending. The next time you tell it to send it will put the byte into the double buffer and return. And the third time you send it will wait for the first one to finish, the second one to get transferred over to the xmit buffer, and then put the byte into the double buffer and return.
A number of people have run into issues when their code does
uint8_t *cmd_buf;
spi_send(*cmd_buf++);
gpio_set(<pin to set data/command line>);
spi_send(*cmd_buf++);
...
gpio_clear(<pin to set data/command>);That ends up setting the command/data line about 3 or 4 bits into the first transmission and often confuses the heck out of an SPI driven display.
Spi_write function does not wait.
SPI_DR(SPI1) = data;
@amitesh-singh it is a the case with the version of the SPI interface on the chip used on the 1BitSy. ST has an older interface that was used on some earlier (like the old F1 chips) that is a bit different in some ways. All of the 'new' versions have support for the automatic control of NSS or "multi-master" support.
@ChuckM "It is the way SPI works, it always clocks in a byte at the same time it clocks out a byte." -> this is what i have known from AVR experience.
@amitesh-singh well the challenge is that SPI has a very limited "specification" which was intentional to make it easy to implement in just a few gates on a microprocessor. As a result you have hardware versions with varying levels of sophistication. Apparently the F7's version is more sophisticated still but I haven't had a chance to dig into that one yet.
Piotr Esden-Tempski
Embedded Programming with Black Magic and the Lights On
Sunday 13:45 - 15:45 | Supplyframe HQ LA time
Embedded Programming with Black Magic and the Lights On
Sunday 13:45 - 15:45 | Supplyframe HQ LA time
:D
Hey everyone... we are having a traditional sale this week at 1BitSquared: http://mailchi.mp/5037e0ca0dbe/black-friday-week-long-sale-2539109 https://twitter.com/1bitsquared/status/933470541905842177
I'm looking at the datasheet for the STM32F415xx and it's not the datasheet I'm looking for? I'd assumed that the datasheet, DocID022063, was what I was looking for but it has an overview of the various timers. Not the config registers and how they should be configured. Perhaps I'm missing something but all I can find is that datasheet and not a programming guide. Is there a programmers guide? Should I be looking for an M4 programming guide? I'd assumed that the timers etc were bolted on to the M4 by STM and not part of that manual?
@johnfwhitmore , maybe RM0090 is what you need? http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf
Just trying to confirm that I'm getting into my Timer2 ISR and clearing the flag. gdb isn't getting to a breakpoint, but my LED is on suggesting it got in there.
There's obviously not a great deal of traffic on this channel, so probably not the best place to post, however... About a week ago I added an example to the 1bitsy-examples project of using Timer2 to flash the on board LED. I was sure I'd created a pull request for my additions on github. I can't see any record of that pull request. I'm not sure it wasn't just dumped, in which case there's no point in my re-trying, or if I actually made a mistake in my attempted pull request, so it never happened. Anybody official got their ears on here?
Premature send. That sounded a bit abrupt. Thanks for that HooperFly, I'll try give @esden a shout.
you might have sent the pull request to the wrong repository
it happens sometimes when you create a pull request on github that the dropdown by default points to the wrong destination
You have the patch you are mentioning in your repository here: https://github.com/johnfwhitmore/1bitsy-examples/commits/master
you should have feature branches this makes things easier especially if changes are needed before your patch can be merged up stream