Path: ...!news.mixmin.net!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: Jan Panteltje <alien@comet.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Grounded grid VHF front-end
Date: Mon, 18 Nov 2024 06:47:04 GMT
Message-ID: <vhent9$iddd$1@solani.org>
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> <vhdick$29o3r$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 18 Nov 2024 06:47:06 -0000 (UTC)
Injection-Info: solani.org;
	logging-data="603565"; mail-complaints-to="abuse@news.solani.org"
User-Agent: NewsFleX-1.5.7.5 (Linux-5.15.32-v7l+)
Cancel-Lock: sha1:TT2qf3BtFqzcr2iBm8erBSwY4ZQ=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform
 NewsFleX homepage: http://www.panteltje.nl/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/ 
X-User-ID: eJwFwQkBACAIA8BKQxhqHB7pH8E7qovXNqcbh5O3iM3bGjon9ynJCKBwYlY/CdOM9PS211cIqRLUsgAV/GlBFcE=
Bytes: 7825
Lines: 153

On a sunny day (Sun, 17 Nov 2024 20:06:46 -0000 (UTC)) it happened
antispam@fricas.org (Waldek Hebisch) wrote in
<vhdick$29o3r$1@paganini.bofh.team>:

>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.

Yes it all depends, I still have my old 8052 BASIC computer:
 https://panteltje.nl/pub/8052AH_BASIC_computer/8052AH_BASIC_computer_inside2_img_1757.jpg
wrote an assembler for it so I could do inline assembler in the BASIC.
I used 5 pole audio connectors to make teh i2c bus external, with sensors and stuff connected to it all around the house.
from before year 2000.

As to PIC serial code
As you can see from the below example, PIC asm is very simple and straight forward.
That is the code in my GPS based radiation meter / logger with OLED display and SDcard storage:
 https://panteltje.nl/panteltje/pic/gm_pic2/
Still working 24/7 after all these years... can hear it ticking on rasiation, logs to a Raspberry Pi 4 4 GB via a serial to USB adaptor.
ASM code:
 https://panteltje.nl/panteltje/pic/gm_pic2/gm_pic2-0.8.asm

I like to comment in the code, but it is basically very simple.