Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 08:57
    tommcq opened #17
  • Jun 19 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
  • Apr 23 2018 12:33
    RandoSY opened #13
  • Apr 01 2018 06:53

    esden on master

    Removed digital volume up/down … (compare)

  • Apr 01 2018 06:50

    esden on master

    Updated PKL. Added MEMS microphone input. (compare)

  • Apr 01 2018 00:16

    esden on master

    Added FPGA. (iCEBreaker circuit… (compare)

John Whitmore
@johnfwhitmore
Premature send. That sounded a bit abrupt. Thanks for that HooperFly, I'll try give @esden a shout.
Piotr Esden-Tempski
@esden
@johnfwhitmore I don't think I have seen a pull request from you regarding timer ... I will check in a sec
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
Anyways thank you for making a new patch and trying to send it our way that is always very appreciated. The flow needs some learning but it is at the end very efficient on the maintainer side of things if done right. :)
Thanks!
Piotr Esden-Tempski
@esden
@johnfwhitmore anyways I just pulled your patch from your repository into the offical repo! Thank you for your contribution. :)
John Whitmore
@johnfwhitmore
Oops, sorry if I did that wrong, and thanks for the link. I'll go through that before next attempt.
Piotr Esden-Tempski
@esden
@johnfwhitmore yeah no worries. I did not find the pull request as you mentioned. So I just pulled your patch that I found. :) Thanks! :)
Brett Smith
@brettklinesmith
Is the Vin pin on the 1Bitsy 5V tolerant?
Adam Haile
@adammhaile
Anyone have a TLC5940 library that works with the 1bitsy?
Maybe this could be adapted? https://github.com/PaulStoffregen/Tlc5940
rmemory
@rmemory
Newbie question. I've connected my black magic probe and my 1bitsy to my computer's USB (a new Dell), which is running Ubuntu 16.04. I do not find the Black Magic probe in the output from dmesg. And likewise I don't see /dev/ttcyACM*. I've also created 99-blackmagic.rules according to the 1bitsy FAQ, also with no luck. Possibly, did I miss a step? @esden
Will
@wmarone
is there anything in the output from dmesg?
rmemory
@rmemory
[ 928.218812] usb 1-6: New USB device found, idVendor=8087, idProduct=0a2b
[ 928.218820] usb 1-6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
rmemory@cob-rmemory-lt:~$ dmesg | grep -i black
[ 1.208053] Allocating IMA MOK and blacklist keyrings.
Will
@wmarone
Hmm, those aren't the IDs for the probe
lights are on?
Amitesh Singh
@amitesh-singh
lsusb can you tell you that.
Will
@wmarone
true
Amitesh Singh
@amitesh-singh
Dmesg now does not spit out usb manufacturer name in recent kernel
rmemory
@rmemory
I had forgotten about lsusb ... thanks ... here is its output. And to answer the question about LEDs, yes. One amber, one green
rmemory@cob-rmemory-lt:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0a2b Intel Corp.
Bus 001 Device 003: ID 0bda:5686 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 0a5c:5832 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hu
Will
@wmarone
the cable wouldn't happen to be a charging-only cable, would it?
rmemory
@rmemory
You know what .... I am guessing yes. That is a very good idea
Will
@wmarone
I've had to tag mine so I don't waste time using them
great for powering the 1bitsy if you're not doing USB though
rmemory
@rmemory
Time to head to the electronic store (tomorrow). Thanks much for the pointer
Peter Mortensen
@PeterMortensen
How can the 1Bitsy run at 168 MHz when the external crystal is 25 MHz (168 MHz is not a multiple of 25 MHz)?
Piotr Esden-Tempski
@esden
the pll can also divide
Peter Mortensen
@PeterMortensen
So it is literally first dividing the frequency by 25 and then multiplying by 168 (no common prime factors between 25 and 168)?
*frequency -> external clock signal
Piotr Esden-Tempski
@esden

if you look into the examples, the clock table used for 1bitsy is the following:

        { /* 168MHz */
                .pllm = 25,
                .plln = 336,
                .pllp = 2,
                .pllq = 7,
                .pllr = 0,
                .hpre = RCC_CFGR_HPRE_DIV_NONE,
                .ppre1 = RCC_CFGR_PPRE_DIV_4,
                .ppre2 = RCC_CFGR_PPRE_DIV_2,
                .flash_config = FLASH_ACR_DCEN | FLASH_ACR_ICEN |
                                FLASH_ACR_LATENCY_5WS,
                .ahb_frequency  = 168000000,
                .apb1_frequency = 42000000,
                .apb2_frequency = 84000000,
        },

you can find it in: libopencm3/lib/stm32/f4/rcc.c

then you can look into the clocktree in the stm32 datasheet and plug in the above numbers to see how the clock frequencies are constructed
but yes you are pretty much correct... the external clock is divided by 25 and then multiplied up to get 168 mhz on the first glance ...
but it is actually divided by 25 then multiplied by 336/2
Peter Mortensen
@PeterMortensen
Thanks. The context is an observed bit time of 2.8 usec on USART 2 when flashing a Forth (Mecrisp - http://mecrisp.sourceforge.net/) into the 1BitSy (using Black Magic Probe). It is probably some software error or other error.
Peter Mortensen
@PeterMortensen
The hex file for the STM32F407 is supposed to work in the 1BitSy. (The continuous serial output happens after the flashing, e.g. after a power cycle.)
Piotr Esden-Tempski
@esden
are you sure? ... the page is talking about 8mhz xtal not 25mhz on the mecrisp page...
if it is assuming an 8mhz external xtal it will definitely not set up the pll correctly
Chuck McManis
@ChuckM
@PeterMortensen yes (on the PLL question). Typically you divide by source crystal frequency and then multiply by the desired frequency to get what you need. There are other constraints (like being able to produce a 48Mhz clock for USB or SDIO or Ethernet. Later chips have 3 PLLs so that different clocks can be generated for the SAI audio chips etc.
Peter Mortensen
@PeterMortensen

Yes, there are discrepancies, also which serial channel is actual used for the terminal connected to the Forth system (USART1 vs. USART2, and perhaps the alternate pins for USART1). User "0033mer" on YouTube (awesome videos, BTW - and very responsive in YouTube comments) claims he has done this - it is in this video: https://www.youtube.com/watch?v=0d2ASWBD0bg&lc=Ugx_Vb8a-avQN7ueV7p4AaABAg

I am trying to repeat what he has done, getting a Forth system up and running on a 1Bitsy.

Ah, yes. It fits. The 2.8 usec observed bit time corresponds to a baud rate 357,000. 25 MHz / 8 MHz is approximately equal to 357,000 / 115,200 (115,200 is what I expect the baud rate to be).
Peter Mortensen
@PeterMortensen
Did some early versions of 1Bitsy have a 8 MHz external crystal instead of 25 MHz?
Chuck McManis
@ChuckM
@PeterMortensen I don't think so (8Mhz) but that was the crystal speed of the original ST Micro discovery board that used the '407 so a lot of examples used it to set up the clock.
Peter Mortensen
@PeterMortensen
I managed to get Mecrisp Forth working on 1Bitsy and am now at the blinky stage!