Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: sci.electronics.design
Subject: Re: Grounded grid VHF front-end
Date: Sun, 17 Nov 2024 20:06:46 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vhdick$29o3r$1@paganini.bofh.team>
References: <1r2rj8l.msi28f14weovyN%liz@poppyrecords.invalid.invalid> <vgpiks$e1ei$1@solani.org> <vgq12n$ao84$2@dont-email.me> <vgq4rj$eagg$1@solani.org> <eld1jjl15hq8ohgm3kifpodkktupt1lr3g@4ax.com> <vgqg85$6t1$1@solani.org> <vhbh7j$26abk$1@paganini.bofh.team> <vhc2ts$9v2r$1@solani.org> <vhcvsg$28q26$1@paganini.bofh.team> <vhd6dk$enst$1@solani.org>
Injection-Date: Sun, 17 Nov 2024 20:06:46 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2416763"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 6407
Lines: 136

Jan Panteltje <alien@comet.invalid> wrote:
> On a sunny day (Sun, 17 Nov 2024 14:50:58 -0000 (UTC)) it happened
> antispam@fricas.org (Waldek Hebisch) wrote in
> <vhcvsg$28q26$1@paganini.bofh.team>:
> 
>>Jan Panteltje <alien@comet.invalid> wrote:
>>> On a sunny day (Sun, 17 Nov 2024 01:34:45 -0000 (UTC)) it happened
>>> antispam@fricas.org (Waldek Hebisch) wrote in
>>> <vhbh7j$26abk$1@paganini.bofh.team>:
>>> 
>>>>Jan Panteltje <alien@comet.invalid> wrote:
> 
>>> Anyways how much processing power do I really need?
>>> 
>>> I program a lot of stuff in asm for Microchip PICs:
>>>  https://panteltje.nl/panteltje/pic/index.html
>>
>>Nice.  I have avoided PICs, using now mostly STM32 and coding in C.
>>One can create quite small and efficient programs in C.  I use
>>assembler when I feel it is better but currently that is mainly
>>for delay loop.  Doing all in efficient assembler would be large
>>effort for moderate gain (maybe 20% efficiency/size improvement),
>>and IME "easy assembler" tend to be less efficient than C.
> 
> In case of small micros like PICs you are so close to the hardware that you will need
> to know how the various registers and stuff work anyways, no space / too much risc to allow for a compiler to change things.
> Then C or some other high level language makes little sense.
> After programming a few PICs you have build up an asm library and things become simple, repeats.

Well, I heard that PICs are hard to program in C.  I am not sure how
small you mean.  Smallest micros I have are MSP430 with 256 bytes of
RAM and 8kB flash (but AFAICS C would work fine also on smaller ones,
say 64 bytes of RAM and 1kB flash).  Cheapest one is STM8 with 1kB RAM
and 8kB flash.  Smallest STM32 I have has 4kB RAM and 16kB flash, that
is plenty for many programs (actually I run most test programs entiriely
in RAM, so 4kB code+data).  Of course one needs to work with hardware
registers and understand hardware.  Below is my UART receive routine
(called from an interrupt handler)  Actual data reception is very easy,
first line gets the data from UART.  Rest of routine deals with receive
buffer (cyclic one):

void
do_usart1_rx(void)
{
    uint8_t c = USART1_DR;
    uint8_t head = i_buff.head;
    uint8_t cnt = (head - i_buff.tail)&BUFF_SIZE_MASK;
    /* Drop characters in case of buffer overflow */
    if (cnt != BUFF_SIZE_MASK) {
        i_buff.buff[head] = c;
        head++;
        head &= BUFF_SIZE_MASK;
        i_buff.head = head;
    }
}

Compiler generated assembly for STM32F103 (Cortex M3) is below:

        .global do_usart1_rx
        .thumb
        .thumb_func
        .type   do_usart1_rx, %function
do_usart1_rx:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        ldr     r3, .L7
        ldr     r0, [r3]
        ldr     r3, .L7+4
        uxtb    r0, r0
        ldrb    r2, [r3]        @ zero_extendqisi2
        ldrb    r1, [r3, #1]    @ zero_extendqisi2
        uxtb    r2, r2
        subs    r1, r2, r1
        and     r1, r1, #15
        cmp     r1, #15
        beq     .L1
        adds    r1, r3, r2
        adds    r2, r2, #1
        and     r2, r2, #15
        strb    r0, [r1, #2]
        strb    r2, [r3]
..L1:
        bx      lr
..L8:
        .align  2
..L7:
        .word   1073821700
        .word   .LANCHOR0
        .size   do_usart1_rx, .-do_usart1_rx

That is 17 executable instructions, 48 bytes of code and AFAICS only
two zero-extend instructions could be dropped.  So one could save
2 instructions, but the rest is very much forced by how the processor
works (and by cyclic buffer logic).  Compiled code for Cortex M0
is slightly different.  The same C routine should work on STM8
(UART port address is different but data register should behave
the same as on STM32) and GD32VF103 (Riscv core but peripherials
compatible with STM32F103).  Cyclic buffer logic could be copied
and used on different processors, like MSP430 or AVR.

Test program for UART routines is 1192 bytes code and uses probably
about 100 bytes of RAM (36 for global data, the rest is stack (I
made a conservative guess for possible stack use)).   That is about
1.8% of available code space and 0.5% of available RAM.  Of the code
336 bytes is table of interrupt vectors (essentially its presence is
forced by the hardware).  The program includes setting clock to desired
frequency, configuration of pins, UART and interrupt controller.

BTW, the interrupt handler itself is:

void
usart1_isr(void)
{
    uint32_t isr = USART1_SR;
    if (isr&USART_SR_RXNE) {
        do_usart1_rx();
    }
    if (isr&USART_SR_TXE) {
        do_usart1_tx();
    }
}

which generates 32 bytes of code.

> I use somebody else's integer math library.

Cortex M have hardware 32-bit mutiplication and C compiler will
expand inline most of 64-bit operations.  MSP430 and STM8 needs
support routines.

> Have not needed floats yet.. not even here in Fourier transform:
>  https://panteltje.nl/panteltje/pic/scope_pic/
> And I opensource everything.

-- 
                              Waldek Hebisch