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: References: <1r2rj8l.msi28f14weovyN%liz@poppyrecords.invalid.invalid> 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 wrote: > On a sunny day (Sun, 17 Nov 2024 14:50:58 -0000 (UTC)) it happened > antispam@fricas.org (Waldek Hebisch) wrote in > : > >>Jan Panteltje wrote: >>> On a sunny day (Sun, 17 Nov 2024 01:34:45 -0000 (UTC)) it happened >>> antispam@fricas.org (Waldek Hebisch) wrote in >>> : >>> >>>>Jan Panteltje 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