## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• 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

• Mar 31 2018 06:35

esden on master

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.
Peter Mortensen
@PeterMortensen
The baud rate can brought down from 360,000 interactively by writing to the appropriate register (USART_BRR).
First some definitions:
$40004400 constant USART2_BASE$08 USART2_BASE + constant USART2_BRR
217 constant BAUD_RATE_DIVISOR_115200
Then the change of baud rate:
BAUD_RATE_DIVISOR_115200 USART2_BRR !
The "ok." response from Forth is garbled in the terminal because the baud rate change takes place immediately. Opening a new terminal session with 115200 works.
Peter Mortensen
@PeterMortensen
Incidentally, the 25 MHz crystal on the 1Bitsy turns out to result in a much closer match for the standard 115,200 baud rate than a 8 MHz crystal, +0.006% versus -0.794% (not that it really matters, though).
Peter Mortensen
@PeterMortensen
The baud rate change can be made permanent (so it can work in Linux with Minimon's default of 115200) by putting it into word "init". See https://jeelabs.org/2015/07/22/forth-on-a-dip/, near "runs that code on power up". I haven't tried that yet, though.
James Hagerman
@JamesHagerman
Man, I'm having issues finding the 1bitsy footprint in KiCad. I've got the https://github.com/1Bitsy/1bitsy-hardware-lib repo cloned...
I got the part, I just can't find the footprint in Cvpcb
Any hints?
James Hagerman
@JamesHagerman
Oh. Damnit. Added the wrong directory.
Anthony DiGirolamo
@AnthonyDiGirolamo
@PeterMortensen were you able to get the 1bitsy working well with mecrisp-stellaris? I just got mine in the mail and would like to try forth on it. I've run mecrisp on the stf303 discovery board but had to add to load https://github.com/jeelabs/mecrisp-stellaris/blob/master/stm32f303/basisdefinitions.txt to get access to all the ports. Do you have something similar for the 1bitsy? It looks like there is a tool to help build register words mentioned here: http://hightechdoc.net/mecrisp-stellaris/_build/html/register-generator.html
Peter Mortensen
@PeterMortensen
@AnthonyDiGirolamo Indeed I was. It can be done straight from the hex file (no compilation/build needed) provided with Mecrisp-Stellaris, \mecrisp-stellaris-2.4.0\stm32f407\mecrisp-stellaris-stm32f407.hex, from https://sourceforge.net/projects/mecrisp/files/ (but not from the green button!). But the entire flash memory MUST be erased before flashing (I used "mon erase" with Black Magic Probe). Then you will get a Forth system running at 25 MHz clock speed and at 300,000 baud on USART2, pin A2 and A3.
Peter Mortensen
@PeterMortensen
I have found the addresses in the reference manual, but this is time-consuming. This is the code (including definitions) I have so far: http://pmortensen.eu/temp2/ForthCodeForBlinkOn1Bitsy.txt
Anthony DiGirolamo
@AnthonyDiGirolamo
Ah nice! I just ran the svd2forth tool on https://github.com/posborne/cmsis-svd/blob/master/data/STMicro/STM32F41x.svd (not sure if that's the right one) and put the results here: https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy Generated registers are here: https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy/blob/master/m I haven't disabled anything in template.xml
Which peripherals / ports in https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy/blob/master/template.xml are not needed for the 1bitsy?
Peter Mortensen
@PeterMortensen
That is awesome! That will certainly save a lot of work. So file "https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy/blob/master/m" is the primary for the base definitions, like GPIOA_MODER?
I am not an expert on 1Bitsy. Perhaps someone else can chime in?
Anthony DiGirolamo
@AnthonyDiGirolamo
Yep! It looks correct. I spot checked what you had in http://pmortensen.eu/temp2/ForthCodeForBlinkOn1Bitsy.txt and it matches what's in https://github.com/AnthonyDiGirolamo/svd2forth-1bitsy/blob/master/m
Paul Fernquist
@PaulF8080
I haven't been here in awhile so I may be answering a very old post. Another way to look at a PLL is that it multiplies the slow frequency by dividing the VCO frequency with a counter. So I say multiply first and then divide with a counter and compare second. The problem is that the duty cycle isn't 50% so the counter /compare generates twice the wanted frequency and divides by two with a flip-flop to get 50%.
Anthony DiGirolamo
@AnthonyDiGirolamo
@PeterMortensen only other thing we should probably change is the available amount of RAM and Flash that forth sees. https://github.com/jeelabs/mecrisp-stellaris/blob/master/mecrisp-stellaris-source/stm32f411/mecrisp-stellaris-stm32f411.s#L49 I'm not sure where in the source this needs changing but I'll give it a shot later this week.
Peter Mortensen
@PeterMortensen
@AnthonyDiGirolamo Yes, and perhaps have an entry for STM32F415 created. I am not sure what the primary point of contact is. It may or may not be http://jeelabs.net/projects/cafe/boards/ (from From https://groups.google.com/forum/#!topic/comp.lang.forth/QIuNkMkCRvE, 2017-03-27: "Nowadays Mecrisp users meet at the Jeelabs forum: http://jeelabs.net/projects/cafe/boards/"). Possible ghost towns are https://groups.yahoo.com/neo/groups/MecrispForth/info and https://groups.io/g/mecrispforth.
Anthony DiGirolamo
@AnthonyDiGirolamo
@PeterMortensen I'm writing an email to the author Matthias Koch m-atthias@users.sf.net asking the best way to do it.