Path: ...!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: Mon, 18 Nov 2024 20:56:58 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vhg9mo$2j4be$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> <vhdick$29o3r$1@paganini.bofh.team> <vhent9$iddd$1@solani.org> <vhf5ec$2h6bb$1@paganini.bofh.team> <vhf7vv$bl41$1@solani.org>
Injection-Date: Mon, 18 Nov 2024 20:56:58 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="2724206"; 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: 6933
Lines: 107

Jan Panteltje <alien@comet.invalid> wrote:
> On a sunny day (Mon, 18 Nov 2024 10:38:06 -0000 (UTC)) it happened
> antispam@fricas.org (Waldek Hebisch) wrote in
> <vhf5ec$2h6bb$1@paganini.bofh.team>:
> 
>>Jan Panteltje <alien@comet.invalid> wrote:
>>> 
>>> 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.
>>
>>Around 1985 I planned to build a Z80 machine, but then I got ZX Spectrum
>>and there was no need to build it.
>>
>>> 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.
>>
>>Well, I used to think "assembler requires comparable effort to C and
>>is more efficient", but then I looked how much time both take
>>and compared efficiency: assembler may be more efficient but
>>efficient assember requires significantly more effort than C.
>>One can write assembler in a way that saves effort, but then
>>it tends to be less efficient than output of a good C compiler,
>>and still takes a bit more effort than C.  You may be used
>>to assembler, but if you are used to both, then reading C is
>>easier than reading assembler.
> 
>>Anyway, I see no reason to use PIC-s, from normal sources
>>I would have to pay more for them than I pay for STM32 and
>>I see no special advantage of PICs.
>>
>>BTW: It seems that there are few thousends of instructions in
>>your code, AFAICS object code for such a program when compiled
>>for something like STM32 would be of comparable size and C source
>>would be smaller.
> 
> Yep, but most of that is in every 18F14K22 PIC code I wrote or from that
> so all that just an afternoon or 2 to make it work.
> 
> I am not against C, but so close to the hardware as in the example I gave it makes little sense.

"so close to the hardware" does not change much.  I have routines
handling almost all buitin devices in STM32F030, most devices
in STM32F103 and many devices in other models (STM has resonable
compatibility between models so a single routine covers a lot
of models).  They directly access device register, configure them
etc.  I do not see how you could get "closer to the hardware".
Writing them in C was significantly easier than writing them in
assembler, using them is easier too.  Assembler could give me
some marginal efficiency gains which in most cases do no matter.
And when extra efficiency really matteres I can rewrite _what is
needed_ in assembler.  For example, I wanted to know how far
I can push nominally 400kHz I2C periferial in MSP430.  Bottleneck
was in I2C interrupt handler, so I did it in assembler.  And the
answer is: I2C worked reasonably well up to about 1.4MHz and
almost worked at 2.4MHz (almost worked meant that data went
back and forth, but was slightly mangled).  But for normal use
at 400kHz interrupt handler in C is fine.

BTW, the routines I mention are written by me and deliberatly
are very close to the hardware.  When I needed to use things
unhanlded by my routines (mainly USB and ENC28J60) I used
C routines that I fetched from the net.  ENC28J60 routine
actually was for AVR, but most of it was idependent of the
CPU, so I just replaced the critical part and used the
rest without changes.  You can find changes that I made to
'libmaple' on the Github (however orginal authors do not
develop it anymore and I also for most things am using
different code).

> I use C all the time:
>  https://panteltje.nl/panteltje/newsflex/download.html
>  this Newsrreader I am using to read and reply here is written in C:
>   https://panteltje.nl/panteltje/newsflex/index.html
>    that uses linked lists,
>   I have a database of Usenet postings that goes back to my first Linux use in 1998 or so...
>   wrote that newsreader as there was no Free Agent for Linux...
> Also in C is all the raspi code I wrote, no asm there at all,
> but I use many libraries that may contain asm...
>  https://panteltje.nl/panteltje/newsflex/download.html
> No C plush plush here... No Python either..
> The problem with using someone else's libraries is that those often change,
> change maintainer and then lose functionalities or do not work at all anymore.

Well, I am using libopencm3 from about 2015 (newer version have
significant incompatibilities).  Actually I am phasing out use of it,
ATM I am using it mainly for definitions of various magic constants.
I decided to write may own routines which as I wrote are closer to
the hardware and smaller than routines in libopencm3 (which in turn
seem to be smaller than routines in STM developement pack).

So one can use old code or enhance it when mainainers make undesirable
changes.  At some moment I intended to do signioficant developement
on libmaple, but then decided that the design had significant
problems, so did my routines in quite a different way.

-- 
                              Waldek Hebisch