On a sunny day (Tue, 17 Mar 2020 11:51:34 +0000) it happened The Natural
Philosopher  wrote in :

>On 17/03/2020 11:17, Jan Panteltje wrote:
>> On a sunny day (Tue, 17 Mar 2020 11:16:38 +0100) it happened "A. Dumas"
>>  wrote in :
>>
>>> On 17/03/2020 08:18, Jan Panteltje wrote:
>>>> Not so sure about that, once tried the latest download
>>>> and tried it in my old PI, and it did not even boot.
>>>> Checksum was OK, no download error.
>>>
>>> Something else was wrong. The old full-size SD card slots were wonky,
>>> maybe that failed? All downloads of the RPi Foundation work with all
>>> RPis. That's precisely the reason why they stayed on 32-bit.
>>
>> Possible, but bit unlikely, been using those SDcards without problems for
years.
>> And, even if it booted, then it still would not work for some
>> software due to the GPIO addressing, example:
>>   http://panteltje.com/panteltje/newsflex/download.html#freq_pi
>>
>>
>> I usually get a recent release, like that Buster for my P4,
>> and from that point onwards modify it, never 'upgrade'.
>> If I ever buy a Pi5 ?? same procedure ;-)
>>
>> What would a Pi5 be able to do? Interesting question.
>>
>> Maybe it is my hardware background,
>> I see the software and hardware as one thing,
>> raspberry is not just an operating system (Linux)[1] but a huge wilderness
of applications.
>> Expecting to - or making it to run on all models would be a very limiting
requirement.
>>
>> But maybe you are right, maybe it detects the processor on boot up,
>> but this is my experience.
>>
>> [1] the function of an operating system is to as much as possible make an
>> interface to the hardware that allows the same programs to run on as  many
types of hardware.
>> For programs that by-pass that OS and use user space access to the hardware
>> it would be a tall order to make those run on every model (they don't),
needs a rewrite if at all possible.
>>
>> So much for the basics part :-)
>>
>> My advice is keep it simple, too much spaghetti in all those releases.
>>
>> As to 32 bits... mm you know, programming in asm on a Microchip PIC,
>> setting and testing a flag
>>   btfss   spi_byte, 7
>> ...
>>   bsf             SPI_SCK
>>
>> takes ONE bit of ONE byte.
>>
>> Now even in C I see this:
>> int too_hot;
>> int alarm_flag;
>> if(too_hot) alarm_flag = 1;
>>
>> On an int that takes 64 bit system this takes 8 bytes!
>> Basically 8 * 8 = 64 x less efficient.
>> Not even mentioning the memory access delay.. alignment.
>> Just FYI.
>>
>> LOL
>> And I wonder, Yes I wonder, Why
>>
>> But bloat sells.
>> And memory per byte gets cheaper all the time
>>
>> Just something to think about...
>>
>>
>>
>The point is that RAM is cheap and the C example does just two memory
>accesses which are the CPU time
>
>I would say the ASM case on a small processor is slower by far

mm, the PIC  18F14K22 that I use runs at 64 MHz clock (internal PLL).

The timing for bit test and set instructions are (taken from
18F1XK22_datasheet_41365C.pdf):
BIT-ORIENTED OPERATIONS
instruction      description              cycles       16 bit instruction word
BCF       f, b, a Bit Clear f               1          1001 bbba ffff ffff
BSF       f, b, a Bit Set f                 1          1000 bbba ffff ffff
BTFSC     f, b, a Bit Test f, Skip if Clear 1 (2 or 3) 1011 bbba ffff ffff
BTFSS     f, b, a Bit Test f, Skip if Set   1 (2 or 3) 1010 bbba ffff ffff
BTG       f, b, a Bit Toggle f              1          0111 bbba ffff ffff


the 'skip if..' skips the next instruction, typical and very handy for these
chips,
so you can write:

#define ALARM  LATC,7  ; some output pin
btfss address,1        ; test bit 1 of address
jump somewhere         ; if bit not set do your thing
bsf ALARM              ; activate the alarm if bit was set
...


The PICs use 4 clock cycles per instruction, so the BTFSC at maximum 12, makes
12 * (1 / 64e6) = 1.875e-07 seconds,
makes almost 200nS
or  4 * (1 / 64e6) = 6.25e-08 makes 62.5 ns

On top of that it is not interrupted by a task switch as it does not run Linux
or any other OS.
This makes it possible for example to do very nice things, like real time
analog video processing,
like I do here:
 https://www.youtube.com/watch?v=xS_K4caj7vc
  here ONE PIC processes the video from a Sony-CCD-650TVL 0.01 Lux Starlight
camera  (analog PAL output),
  finds and tracks a bright spot (IR emission from for example a missile)
  and at the same time generates 2 RC servo signals to steer that spot to
center screen (so aim it).
There is no way in this universe your raspi can do that, as the PIC has for
example nice analog input comparators
and the PIC only costs about 2 $, and uses milliwatts, as much as the servos
take actually.
I did not release the asm for this as it would make that US F35 look so
silly... ;-)

So, if you scale it up, go single tasking sure ARM can do SOME of that in asm,
you need to add some comparators,
loads of batteries, cooling? And then what do you have...
On top of that ARM asm well... ;-( not me thank you.

And memory use? WHAT memory use?

So always see things in perspective, maybe the next WW will clean the crap.



>Gun Control: The law that ensures that only criminals have guns.

Ah now I see what I posted that link to my TAT experiment (Target Acquisition
Tracking) ;-)

Have fun!

--- SoupGate-Win32 v1.05