Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • Apr 20 01:51
    esden commented #2
  • Apr 20 01:50

    esden on master

    Update to recent libopencm3 (compare)

  • Apr 20 01:50
    esden closed #2
  • Jan 04 00:37
    schodet opened #2
  • Oct 20 2021 08:57
    tommcq opened #17
  • Jun 19 2021 05:58

    esden on master

    Updated LOCM3. Improved the clean target. Ignore if st-link/dfu-util is n… and 9 more (compare)

  • Aug 05 2020 21:27

    0xdec on v2.0a

    More WIP (compare)

  • Jul 31 2020 21:36

    0xdec on v2.0a

    WIP migration + v2.0a (compare)

  • Nov 06 2018 16:29
    esden commented #16
  • Nov 06 2018 16:28

    esden on master

    Fix formatting, typos, grammar … (compare)

  • Nov 06 2018 16:28
    esden closed #16
  • Nov 06 2018 03:42
    0xdec opened #16
  • Oct 21 2018 20:53
    Poofjunior opened #15
  • Oct 12 2018 05:48
    frankalicious closed #10
  • Aug 24 2018 22:49
    irandms opened #5
  • Aug 22 2018 11:38
    elektor-labs edited #14
  • Aug 22 2018 11:36
    elektor-labs opened #14
  • May 24 2018 12:17

    kbob on master

    Improve audio clock calculation. Experiment with different color… Added bit definitions for the g… and 1 more (compare)

  • Apr 23 2018 12:45
    RandoSY edited #13
  • Apr 23 2018 12:44
    RandoSY edited #13
Luke Beno
ok, question for anyone out there... I'm trying to use the 1bitsy TIM5 as an input capture with libopencm3
Here is a gist of my strung together code https://gist.github.com/lgbeno/ada9be9792f1dffa1ff7253e105235a3
so with the gist above, I can confirm with BMP that my timer is running, it overflows at 32bits and trigger an interrupt
the only issue is that I am not triggering the input capture with the IO despite feeding a signal into pin A0
Luke Beno
I noticed that the chip used in Paparazzi has a RCC_AFIO (rcc_periph_clock_enable(RCC_AFIO);)
but I don't think that this is the case for STM32F415?
Piotr Esden-Tempski
yeah that is for the STM32F1 chips
paparazzi supports both STM32F1 and STM32F4 and more recently STM32F7 too
Luke Beno
Cool, for the most part I was simply using the Paparazzi code as reference for using TIM5, of which it has gotten me pretty far
There must just be something subtle that I'm missing in getting the PA0 port routed to TIM5
this is the main difference between F1 and F4
if you look at the legends here: https://github.com/1bitsy/1bitsy-hardware
if you look here you will see that T5C1 on PA0 needs to be mapped to AF2
this means that the line needs to be:
gpio_mode_setup(GPIOA, GPIO_MODE_AF,
                    GPIO_PUPD_NONE, GPIO0);
gpio_set_af(GPIOA, GPIO_AF2, GPIO0);
Luke Beno
Excellent, that worked!
I know it was something along those lines, this is sometimes the pain of using a new family of micros for the first time
btw, that legend is great, I was referencing the one that came printed with 1bitsy, but this one even has the AF settings!
Piotr Esden-Tempski
yeah I could not fit the full thing on the cards
so I had to compress it
Luke Beno
well both are great references, thank you for the quick help!
Piotr Esden-Tempski
no problem, thanks for diving into it :D
Luke Beno
I'm coming from ATSAMD11 and ATSAMD21, these F4 micros are bad ass comparatively speaking
working on a project now with F410 and BlueNRG
Nothing wrong with ATSAMDx1 either, I just need more umph for Floating point math
but yeah, calling it a day after this victory, thanks again!
Piotr Esden-Tempski
Great! Have a good night. :)
What to do you call 1bitsy + Rust? I'm going with 1rusty for now. Managed to get the Cortex-M RTFM environment running on 1bitsy thanks to the work of @miek, @japaric, and @esden. Now it's time to write some Rust code. :)
@hooperfly that sounds interesting, I'm trying to get into rust myself but it's a very differnt mode of thinking from standard C programming
Luke Beno
is there a reference for using the libopencm3 SPI2 abstraction

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_set(GPIOB, GPIO12);

    spi_set_baudrate_prescaler(SPI2, SPI_CR1_BR_FPCLK_DIV_64);


Then in main, I will do:

spi_send(SPI2, 0xDE);
spi_send(SPI2, 0xAD);
spi_send(SPI2, 0xBE);
spi_send(SPI2, 0xEF);
Luke Beno
I also have the
Luke Beno
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!
Chuck McManis
@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.
Luke Beno
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
Chuck McManis
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;
   gpio_set(<pin to set data/command line>);
  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.

Keith Legg
I have a working SPI and I2C example I cooked up if anyone wants them. I wish the example projects came with some more basic examples like these. It was a good learning experience to write them both
Amitesh Singh
Spi send funtion does wait for previous transfer to.complete before writing to data register.
Spi_write function does not wait.
SPI_DR(SPI1) = data;
Amitesh Singh
Chuck, is this the case with stm32? Or any spi interface irrespective of mcu.
Chuck McManis
@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.
Amitesh Singh
@ChuckM aha, good to know. thanks