Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 06 02:33
    SaintGimp edited #4
  • 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
Piotr Esden-Tempski
@esden
Send us an email at info@1bitsquared.com or we can meet in Portland the next time I will be going up there.
Paul Fernquist
@PaulF8080
I was only trying to show that that is a common problem and can happen to anyone. That said, I have no clue what happened.
Paul Fernquist
@PaulF8080
Now that I rethink this. The components used on your boards probably passed a burn-in test. It is frustrating because I have had very few unsolved failures.
Paul Fernquist
@PaulF8080
Just checking in. Thanks for the offer, but I think it was my fault. The board I plugged the BMP into is a mess because my soldering was terrible. I held my breath when I first plugged it in. The solder stencil worked great, but my hands weren't steady enough to place tiny caps etc. I bought a cheap laser to make stencils and to learn to solder better on my next project. New BMP later.
Luke Beno
@lgbeno
Hi Everyone, I'm curious is there is a base template for a 1bitsy project aside from hacking on one of the examples
I'm asking simply because the directory structure of the 1bitsy examples has a makefile structure that is difficult for me to follow
Never mind, maybe this is it! https://github.com/1Bitsy/1bitsy-locm3-template
Luke Beno
@lgbeno
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
@lgbeno
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
@esden
yeah that is for the STM32F1 chips
paparazzi supports both STM32F1 and STM32F4 and more recently STM32F7 too
Luke Beno
@lgbeno
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
@lgbeno
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
@esden
yeah I could not fit the full thing on the cards
so I had to compress it
Luke Beno
@lgbeno
well both are great references, thank you for the quick help!
Piotr Esden-Tempski
@esden
no problem, thanks for diving into it :D
Luke Beno
@lgbeno
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
@esden
Great! Have a good night. :)
HooperFly
@hooperfly
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. :)
Will
@wmarone
@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
@lgbeno
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_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);
Luke Beno
@lgbeno
I also have the
rcc_periph_clock_enable(RCC_SPI2);
Luke Beno
@lgbeno
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
@ChuckM
@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
@lgbeno
Thanks
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
@ChuckM
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.