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)

Piotr Esden-Tempski
@esden
Thanks!
@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!
Peter Mortensen
@PeterMortensen
It turned out it was crucial to erase the entire flash memory (I used Black Magic Probe, "mon erase") before flashing the Mecrisp STM32F407 hex file (from inside "mecrisp-stellaris-2.4.0.tar.gz" on https://sourceforge.net/projects/mecrisp/files/ (NOT the green button stuff!)).
It works at 360,000 baud (but not so well with long lines), and I am currently using the auxiliary COM port in Black Magic Probe with PuTTY on Windows (I couldn't immediately get it to work with Minimon or PuTTY on Linux).
Peter Mortensen
@PeterMortensen
The Forth source code for the blinky is currently in YouTube comments at https://www.youtube.com/watch?v=0d2ASWBD0bg&lc=UgwXHZYgCd00eMqsBD54AaABAg.8c8lcTUGiwz8cE-k929ksm, but it will soon appear in a blog post and perhaps at GitHub.
So, blinky on the 1Bitsy using Forth!
Peter Mortensen
@PeterMortensen
I followed this video:
But I had to change every address, every control register except the port output register, and abandon byte addressing (as the LED on the 1Bitsy is not in the lower 8 bits on port A). The STM32F103 (in the Blue Pill) and the STM32F415RGT6 (in the 1Bitsy) are quite different.
Peter Mortensen
@PeterMortensen
Serial input/output is on USART2, PA2 / PA3.