Nice MCU for small jobs

On 09/05/2018 01:57 AM, bitrex wrote:
> On 09/05/2018 01:10 AM, 698839253X6D445TD@nospam.org wrote:
>> bitrex wrote
>>> Yes it's easy enough to write multiple functions for the primitive types
>>> and have circular buffers for char, int, float, etc. But that
>>> implementation example works for _anything_. It can just as easily be
>>> circular buffer for a user-defined struct, whatever it is, whatever it
>>> contains, maybe it holds 20 pointers who knows. or even a whole object,
>>> whatever it is.
>>>
>>> No need to do any extra work except change one one line and then the
>>> compiler decides what needs to happen to create code for your particular
>>> use-case.
>>
>> Na ya, bringing a screwdriver set from size 1 mm to 1 meter every time 
>> you need to tighten
>> one small screw is a bit heavy and in increases workload, space used, 
>> efficiency,
>> fuel consumption and causes glowball worming I'm sure.
>> It may damage the screws if you pick the wrong tool, and you lose your 
>> view of proportion.
>> It is more expensive and slower, ...
>> :-)
>>
> 
> Slower for the compiler, maybe. Not my problem how hard the compiler has 
> to work that's what all those 8 cores running at 3 GHz or w/e are there 
> for. You can see from the example the compiler doesn't generate any push 
> or pop routines for anything you don't use.

at other optimization levels it doesn't even generate them at all the 
compiler recognizes that the main routine is so simple it can just
eliminate the actual use of a circular buffer completely and inline a 
bunch of stuff.

bitrex wrote
>On 09/05/2018 01:57 AM, bitrex wrote:

>> On 09/05/2018 01:10 AM, 698839253X6D445TD@nospam.org wrote:
>>> bitrex wrote
>>>> Yes it's easy enough to write multiple functions for the primitive types
>>>> and have circular buffers for char, int, float, etc. But that
>>>> implementation example works for _anything_. It can just as easily be
>>>> circular buffer for a user-defined struct, whatever it is, whatever it
>>>> contains, maybe it holds 20 pointers who knows. or even a whole object,
>>>> whatever it is.
>>>>
>>>> No need to do any extra work except change one one line and then the
>>>> compiler decides what needs to happen to create code for your particular
>>>> use-case.
>>>
>>> Na ya, bringing a screwdriver set from size 1 mm to 1 meter every time 
>>> you need to tighten
>>> one small screw is a bit heavy and in increases workload, space used, 
>>> efficiency,
>>> fuel consumption and causes glowball worming I'm sure.
>>> It may damage the screws if you pick the wrong tool, and you lose your 
>>> view of proportion.
>>> It is more expensive and slower, ...
>>> :-)
>>>
>> 
>> Slower for the compiler, maybe. Not my problem how hard the compiler has 
>> to work that's what all those 8 cores running at 3 GHz or w/e are there 
>> for. You can see from the example the compiler doesn't generate any push 
>> or pop routines for anything you don't use.
>
>at other optimization levels it doesn't even generate them at all the 
>compiler recognizes that the main routine is so simple it can just
>eliminate the actual use of a circular buffer completely and inline a 
>bunch of stuff.

That sort of optimization, where the actual structural design is changed,
is not what I would like to see.

If seeplushplush makes you 'appy keep using it.
I have had to use it (in MS Windows) for my job and never looked back.
I think for me the gist is
object oriented is not how computers work,
computer work sequential.
Using object oriented as a starting point is wrong, and requires an extra conversion in the brain-world interface.

What else is a computah program than a step by step instruction on a map where to go to designation X?

Go left, second right, third left, next right, over bridge.. ... destination.

If you start with ME here, House there, dunno library, object bridge, 
well ....

:-)

Let's have piece [pees, peace], in these language wars,
 but really I am serious, object oriented is simply overhead,
not to mention [having to type] blahblah:beepbeep in plushplush versus beepbeep in C.
Prototype your functions, that prevents errors.

From xgpspc planes.c

    if(show_more_plane_info_flag)
        {
        if(use_metric_flag)
            {
            snprintf(temp, 16, "SPD %dkm/h", pa -> speed_kmh);
            // int text_to_rgb32_buffer(char *text, int x, int y, int fr, int fg, int fb,  int br, int bg, int bb,  int xsize, int ysize,  int double_height, int double_width,  int transparency,  unsigned char *buffer);
            text_to_rgb32_buffer(temp, xpos + 22, vpos,  0, 0, 0,   200, 200, 200,  viewport_width, viewport_height,  0,  0,  0,  xbuffer);
            vpos += 10;

            if(position_fix_indicator)
                {
                if(valid_magnetic_heading_flag)
                    {
                    snprintf(temp, 24, "DIR %.0lf%c %d o'clock", pa -> heading_to_plane, 96, pa -> direction_plane_h);
                    // int text_to_rgb32_buffer(char *text, int x, int y, int fr, int fg, int fb,  int br, int bg, int bb,  int xsize, int ysize,  int double_height, int double_width,  int transparency,  unsigned char *buffer);
                    text_to_rgb32_buffer(temp, xpos + 22, vpos,  0, 0, 0,   200, 200, 200,  viewport_width, viewport_height,  0,  0,  0,  xbuffer);
                    vpos += 10;
                    }
                else
                    {
                    snprintf(temp, 16, "DIR %.0lf%c", pa -> heading_to_plane, 96);
                    // int text_to_rgb32_buffer(char *text, int x, int y, int fr, int fg, int fb,  int br, int bg, int bb,  int xsize, int ysize,  int double_height, int double_width,  int transparency,  unsigned char *buffer);
                    text_to_rgb32_buffer(temp, xpos + 22, vpos,  0, 0, 0,   200, 200, 200,  viewport_width, viewport_height,  0,  0,  0,  xbuffer);
                    vpos += 10;
                    }    

                snprintf(temp, 16, "ELV %.2lf%c", pa -> elevation, 96);
                // int text_to_rgb32_buffer(char *text, int x, int y, int fr, int fg, int fb,  int br, int bg, int bb,  int xsize, int ysize,  int double_height, int double_width,  int transparency,  unsigned char *buffer);
                text_to_rgb32_buffer(temp, xpos + 22, vpos,  0, 0, 0,   200, 200, 200,  viewport_width, viewport_height,  0,  0,  0,  xbuffer);
                vpos += 10;

                snprintf(temp, 16, "TDI %.2lfkm", pa -> true_distance_to_plane_m / 1000.0);
                // int text_to_rgb32_buffer(char *text, int x, int y, int fr, int fg, int fb,  int br, int bg, int bb,  int xsize, int ysize,  int double_height, int double_width,  int transparency,  unsigned char *buffer);
                text_to_rgb32_buffer(temp, xpos + 22, vpos,  0, 0, 0,   200, 200, 200,  viewport_width, viewport_height,  0,  0,  0,  xbuffer);
                vpos += 10;
                }
            }
        else
            {

You do not - / or may want to see  text_to_rgb32_buffer() in graphics.c

You need a decent text editior to write this code FAST, I use 'joe' in Linux.
Even typing this in joe now (from my newsreader).
In a rxvt terminal.
 http://www.panteltje.com/pub/joe_in_rxvt_for_newsflex.gif

9 virtual desktops, 8 with a rxvt, 
one docs, one source, one compile / test, switch with ctlr shift, one browser, one news reader, one remote app for xgpspc, one audio mixer,
and one with icons.... icons an other silly thing :-) so much easier to type (allows voice control too) what you want.
never a clogged up screen with silly small windows.

Just imagine a language (country) where for every thing you did not have a word but had to show a picture.
Supermarket is bad enough if they keep replacing things in different locations.
In the good old shop you would ask the shopkeeper for 'whatever' and he would get it, his problem where he stored it.
Buying online and google is a relief.

PS, 
I have screen width to about 240 characters when programming in C, I get windows claustrofobia if smaller
 http://panteltje.com/pub/joe_in_rxvt_for_programing.gif
Note the 'verbose' statements, for debug and or development I just comment out the verbose line[s] ... where I want to look.

'Tis zimple
hehe

On 05/09/18 06:10, 698839253X6D445TD@nospam.org wrote:
> ,, in the time needed replying to computah language wars I can write a
> completely new program...

In the time needed to reply to 'pooter language wars I can write a completely
new (domain specific) language.

Neither is a good use of time.

On 05/09/18 08:11, 698839253X6D445TD@nospam.org wrote:
> Using object oriented as a starting point is wrong, and requires an extra conversion in the brain-world interface.

Not when the customer says "oh, I need /that/, but also I need something like 
that but also with /this/ little change".


> What else is a computah program than a step by step instruction on a map where to go to designation X?

It is akin to applied philosophy: extracting the essence of what a customer 
needs, and codifying that in an executable form.

Tom Gardner wrote
>On 05/09/18 08:11, 698839253X6D445TD@nospam.org wrote:
>> Using object oriented as a starting point is wrong, and requires an extra conversion in the brain-world interface.
>
>Not when the customer says "oh, I need /that/, but also I need something like 
>that but also with /this/ little change".

Yea, but it is up to the _programmer_ to translate customer dreams into realistic scenarios (for lack of a better word).

I have done that a couple of times, with success every time, also for hardware design.
The worst that happened was when customer was a local county board and changed spec and requirements every Wednesday when they had a meeting
were my boss was invited, he came back after each meeting with new requirements that required a board layout change.
That was hardware, and there I argued for a processor 8052 IIRC to make it easier to adapt.
And it had a clear deadline...
We made the deadline, I worked some nights.


>> What else is a computah program than a step by step instruction on a map where to go to designation X?
>
>It is akin to applied philosophy: extracting the essence of what a customer 
>needs, and codifying that in an executable form.

Yes.

Sometimes you need to help things a bit to point 'customer' to some options,
but some companies / entities will just see a money making adventure / opportunity sucking the maximum out of 'customer'.
Such as sucking the maximum out of taxpayers for mil projects that are a joke in any real war situation.
F35

In my case I as thinking in the airplane follow situation if I could not use passive radar to track F35,
In passive radar you use the TV and radio transmitter reflections from the plane to your receiver to locate it.
Of course in a war situation the media stations are the first to get hit (I know I worked there, it is part of the protocol),
but with all those cellphone towers and now 5G .. there is a lot of RF energy emitted over a wide range of frequencies.
There are passive radar experiments on youtube with equipment that costs only  a few $$,
it may be so much easier, makes a F35 a joke, not even mentioning that joke shines bright in the IR.
Soon some will be flying here again, so could test that and sell it to RUSSIA LOL.
That plane is a clean mirror at some of these lower frequencies.
Basic principle:
 https://www.youtube.com/watch?v=wJUucoULFdc

China is already there it it seems:
 https://www.youtube.com/watch?v=F2ZyjafmxOI

Passive radar stations are very hard to detect, as those do not emit significant any RF.

Na .. they now know my coordinates...

On a sunny day (Wed, 5 Sep 2018 08:32:09 +0100) it happened Tom Gardner
<spamjunk@blueyonder.co.uk> wrote in <ZDLjD.139793$av.116836@fx30.am4>:

>On 05/09/18 06:10, 698839253X6D445TD@nospam.org wrote:
>> ,, in the time needed replying to computah language wars I can write a
>> completely new program...
>
>In the time needed to reply to 'pooter language wars I can write a completely
>new (domain specific) language.
>
>Neither is a good use of time.

How about eating icecream?

(I don't know what newsclient you are using, but your line lengths are
badly muddled.  If you can fix it, that would be nice.)

On 04/09/18 17:27, 698839253X6D445TD@nospam.org wrote:
> David Brown wrote
>> Long ago, gcc's ARM backend was quite inefficient.  Once it got popular,
>> however, it was quickly improved.  But commercial ARM compiler companies
>> love to tell you how slow gcc-generated ARM code is, or how limited the
>> compiler is - it's just marketing nonsense.  They will happily compare
>> their latest toolchains and optimal flags with an ancient version of gcc
>> with questionable flag choices - and sue anyone who tries to publish
>> their own benchmarks using the commercial compilers.
>>
>> There can be good reasons for choosing to buy an expensive ARM toolchain
>> such as IAR, Green Hills, Keil, or various others.  But performance of
>> the generated code is unlikely to be a sensible reason.  The differences
>> in speed are going to be small, and my money would be on gcc winning in
>> most cases.  (Performance /measuring/ tools, on the other hand, can
>> certainly be a consideration.)
>>
>> Standards compliance is also not a reason for picking IAR or others.
>> IAR does better than most commercial toolchain vendors - it currently
>> supports C11 and C++14.  gcc - the build from GNU ARM Embedded with ARM
>> backing and support - is on C11 and C++17 for version gcc 7.  If you
>> want a cutting-edge toolchain with less testing and support, you get
>> experimental C17/C18 and C++20 support.
>>
>> The big commercial toolchain companies give you more testing or
>> certifications, development tools for debugging, profiling, etc., static
>> analysis including MISRA, and the warm fuzzy feeling you get from an
>> expensive box, hardware or software license keys to lose, and someone
>> who has to stay on the telephone support line even when you shout at them.
> 
> I have now written thousands and thousands of lines of code in C for
> ARM (Raspberry Pi), using gcc.
> Apart from some minor reporting issues i have been unable to find any fault with gcc.

gcc certainly has its faults and bugs, but they are not often seen in
most code.  I've only seen a couple of cases where the generated object
code was not correct, and I have used gcc for decades on a dozen targets.

> 
> But then again I have.. thou... PIC 18F asm with gpasm and ... never an issue.
> 

Assemblers are a lot simpler - it's rare to find a bug in them!

> Faster ARM C compiler than gcc? Maybe, but if your code is that
> critical I would look for
> the bottle necks and fix that, because it likely sucks.

Of course.

> All those debugging tools? Who needs them, use printf().

Debugging tools are extremely useful in many cases.  printf can be handy
on a Pi - but it's not much use when you are debugging an embedded board
with no screen or serial port.  Nor is it of use with a motor
controller, or when the execution time of printf is hundreds of times
longer than the actual useful code.

<snip>

David Brown wrote
>(I don't know what newsclient you are using, but your line lengths are
>badly muddled.  If you can fix it, that would be nice.)

In the rfc997 there is no official line length limit for Usenet.
If you read things in a crappy silly small window get a real newsreader.
Best if of course mine:
 http://panteltje.com/panteltje/newsflex/index.html

>gcc certainly has its faults and bugs, but they are not often seen in
>most code.  I've only seen a couple of cases where the generated object
>code was not correct, and I have used gcc for decades on a dozen targets.
>
>> 
>> But then again I have.. thou... PIC 18F asm with gpasm and ... never an issue.
>> 
>
>Assemblers are a lot simpler - it's rare to find a bug in them!

mmm
:-)
But I did.



>> Faster ARM C compiler than gcc? Maybe, but if your code is that
>> critical I would look for
>> the bottle necks and fix that, because it likely sucks.
>
>Of course.
>
>> All those debugging tools? Who needs them, use printf().
>
>Debugging tools are extremely useful in many cases.  printf can be handy
>on a Pi - but it's not much use when you are debugging an embedded board
>with no screen or serial port.

There should always be a serial port or at least a pin and software UART
for debugging.



>Nor is it of use with a motor
>controller, or when the execution time of printf is hundreds of times
>longer than the actual useful code.

That has nothing to do with it for debugging
All ye need is a scope.
If not then you do not understand the processor you use.

On 05/09/18 12:09, 698839253X6D445TD@nospam.org wrote:
> David Brown wrote
>> (I don't know what newsclient you are using, but your line lengths are
>> badly muddled.  If you can fix it, that would be nice.)
> 
> In the rfc997 there is no official line length limit for Usenet.
> If you read things in a crappy silly small window get a real newsreader.
> Best if of course mine:
>  http://panteltje.com/panteltje/newsflex/index.html

It is a matter of convention - for the benefit of all Usenet users.
Still, in this group lots of people use the far worse and non-standard
google groups interface, and seem unaware of key conventions like
snipping.  So, I have asked you if you can configure your newsclient to
use conventional Usenet line lengths.  If you can't, or don't want to,
then that's up to you.  It is a matter of convenience and politeness,
not of necessity.

> 
>>> Faster ARM C compiler than gcc? Maybe, but if your code is that
>>> critical I would look for
>>> the bottle necks and fix that, because it likely sucks.
>>
>> Of course.
>>
>>> All those debugging tools? Who needs them, use printf().
>>
>> Debugging tools are extremely useful in many cases.  printf can be handy
>> on a Pi - but it's not much use when you are debugging an embedded board
>> with no screen or serial port.
> 
> There should always be a serial port or at least a pin and software UART
> for debugging.
> 

That's nice in theory, and usually possible with modern microcontrollers
with multiple UARTs.  But it is not always the case - you might not have
extra pins, extra UARTs, extra space on the board.  And while a UART and
printf can certainly be helpful in debugging and testing, it is
certainly not a replacement for a JTAG-style debugger.

> 
> 
>> Nor is it of use with a motor
>> controller, or when the execution time of printf is hundreds of times
>> longer than the actual useful code.
> 
> That has nothing to do with it for debugging
> All ye need is a scope.
> If not then you do not understand the processor you use.
> 

Bollocks.

Debugging and testing can involve lots of tools - different tools being
better for different purposes.  printf can be useful, but it is not good
for everything.  The same applies to a scope.  And the same applies to a
debugger.

bitrex wrote:

> Where I can definitely learn from the "desktop guys" is their
> computer-science-type knowledge of data structures and algorithms is
> usually more sophisticated than mine is

This is my background and profession. I almost got a Ph.D. degree, but
was sober enough to escape to the industry, as they were kind enough to
add one zero to my wage.

	Best regards, Piotr