Electronics-Related.com
Forums

Nice MCU for small jobs

Started by Phil Hobbs September 3, 2018
On 05/09/18 10:25, 698839253X6D445TD@nospam.org wrote:
> 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?
Italian ice cream: yes[1]. US ice cream: if that's all that's available, yes Ice non-dairy-fat-whitener: no. [1] I was once in Copenhagen with a couple of days to spare, so I thought "I know a good ice cream shop in Stresa (on Lake Maggiore, Italy)". So I went there before going home.
On Sep 5, 2018, 698839253X6D445TD@nospam.org wrote
(in article <pmnoi8$12kf$5@gioia.aioe.org>):

> > Sure, linked list is not the only thing I use in C. > An other thing, also used in xgpspc, is the worldwide list of ships, > basically ALL ships in the world that have radio are in that list: > -rw-r--r-- 1 root root 31637292 Oct 3 2016 listv.tx > 31,637,292 > > 31 MB that looks like this: > 203013200 OEX2023 APSYRTE AUT PL MTB W25884 2,30 7 V SRI: VHFDSC > > When a radio message is received from a ship it contains the MMSI (the first > number on the previous line), > and xgpspc has to look it up in the list to get the ship-name, what it is, > etc... > In that case we first sort the list by number ONCE, and then do a successive > approximation search > and have the answer in a few ms for every message. > No plush plush needed, > > Maybe a hundred lines of code..
This successive approximation approach is well known in computer science, where it is called &ldquo;binary search&rdquo; in English. As you note, it is very fast. .<https://en.wikipedia.org/wiki/Binary_search_algorithm> The only algorithm that is faster is hashing, which is also discussed in the above wiki article. The lookup time for hashing is constant, regardless of the size of the dataset. Joe Gwinn
On 05/09/18 10:20, 698839253X6D445TD@nospam.org wrote:
> 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...
I've found the "cellphone radar" to be less than compelling. Yes, it works, in the sense that you can spot where the aircraft are /over/ your territory - which is later than desirable. The halfway house to a passive radar is a bistatic radar, with the (hopefully cheap) emitter Somewhere Else.
On 05/09/18 14:35, Joseph Gwinn wrote:
> On Sep 5, 2018, 698839253X6D445TD@nospam.org wrote > (in article <pmnoi8$12kf$5@gioia.aioe.org>): > >> >> Sure, linked list is not the only thing I use in C. >> An other thing, also used in xgpspc, is the worldwide list of ships, >> basically ALL ships in the world that have radio are in that list: >> -rw-r--r-- 1 root root 31637292 Oct 3 2016 listv.tx >> 31,637,292 >> >> 31 MB that looks like this: >> 203013200 OEX2023 APSYRTE AUT PL MTB W25884 2,30 7 V SRI: VHFDSC >> >> When a radio message is received from a ship it contains the MMSI (the first >> number on the previous line), >> and xgpspc has to look it up in the list to get the ship-name, what it is, >> etc... >> In that case we first sort the list by number ONCE, and then do a successive >> approximation search >> and have the answer in a few ms for every message. >> No plush plush needed, >> >> Maybe a hundred lines of code.. > > This successive approximation approach is well known in computer science, > where it is called &ldquo;binary search&rdquo; in English. As you note, it is very > fast. > > .<https://en.wikipedia.org/wiki/Binary_search_algorithm> > > The only algorithm that is faster is hashing, which is also discussed in the > above wiki article. The lookup time for hashing is constant, regardless of > the size of the dataset.
... provided there are no collisions. Ensuring no collisions takes arbitrary space - an example of the classic space-time tradeoff.
Tom Gardner wrote
>I've found the "cellphone radar" to be less than compelling. Yes, >it works, in the sense that you can spot where the aircraft are >/over/ your territory - which is later than desirable. > >The halfway house to a passive radar is a bistatic radar, with >the (hopefully cheap) emitter Somewhere Else.
I will have to look that up. Am very close to a mil airport, we had F35 here last year, will be an interesting experiment.
Tom Gardner wrote
>On 05/09/18 10:25, 698839253X6D445TD@nospam.org wrote: >> 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? > >Italian ice cream: yes[1]. > >US ice cream: if that's all that's available, yes > >Ice non-dairy-fat-whitener: no. > >[1] I was once in Copenhagen with a couple of days to spare, >so I thought "I know a good ice cream shop in Stresa (on >Lake Maggiore, Italy)". So I went there before going home.
That is some trip from Copenhagen (been there too) to Italy. I am a big icecream consumer, one liter box from the supermarket every time I am there. So I just emptied that one... I use the empty boxes to store 'tronics parts: http://panteltje.com/pub/ice_cream_boxes_IMG_6540.JPG Temperatures have been the highest ever measured here this year. Long ago I lived across the street from an Italian style (run by an real Italian) icecream shop. Spend a lot of my time sitting there chatting, drinking coffee. His coffee was very special too, own mix, never found that anywhere else.
Joseph Gwinn wrote
>On Sep 5, 2018, 698839253X6D445TD@nospam.org wrote >This successive approximation approach is well known in computer science, >where it is called &ldquo;binary search&rdquo; in English. As you note, it is very >fast. > >.<https://en.wikipedia.org/wiki/Binary_search_algorithm> > >The only algorithm that is faster is hashing, which is also discussed in the >above wiki article. The lookup time for hashing is constant, regardless of >the size of the dataset.
I am not sure hashing is faster, what gives you that idea? I have used it, was long time ago, trying to remember... You may well be right, but why?
On 05/09/18 15:35, Joseph Gwinn wrote:
> On Sep 5, 2018, 698839253X6D445TD@nospam.org wrote > (in article <pmnoi8$12kf$5@gioia.aioe.org>): > >> >> Sure, linked list is not the only thing I use in C. >> An other thing, also used in xgpspc, is the worldwide list of ships, >> basically ALL ships in the world that have radio are in that list: >> -rw-r--r-- 1 root root 31637292 Oct 3 2016 listv.tx >> 31,637,292 >> >> 31 MB that looks like this: >> 203013200 OEX2023 APSYRTE AUT PL MTB W25884 2,30 7 V SRI: VHFDSC >> >> When a radio message is received from a ship it contains the MMSI (the first >> number on the previous line), >> and xgpspc has to look it up in the list to get the ship-name, what it is, >> etc... >> In that case we first sort the list by number ONCE, and then do a successive >> approximation search >> and have the answer in a few ms for every message. >> No plush plush needed, >> >> Maybe a hundred lines of code.. > > This successive approximation approach is well known in computer science, > where it is called &ldquo;binary search&rdquo; in English. As you note, it is very > fast. > > .<https://en.wikipedia.org/wiki/Binary_search_algorithm> > > The only algorithm that is faster is hashing, which is also discussed in the > above wiki article. The lookup time for hashing is constant, regardless of > the size of the dataset. >
There are many search and sorting algorithms, some of which are faster than binary search - for some value of "faster", and in some circumstances. Hashing is one example, but of course its speed depends on the collision rate, which also depends on the space available. And lookup speed may be fast in theory (it's just one array index) but slow in practice (the array is spread over memory that is not in caches) - an algorithm that is theoretically slower might be faster in practice if it is more cache-friendly. Then there are parallel algorithms... Binary search is optimal from a theoretical viewpoint in a simple system. It's usually also very good in practice, but it does not always work out that way.
On 05/09/18 16:00, 698839253X6D445TD@nospam.org wrote:
> Tom Gardner wrote >> On 05/09/18 10:25, 698839253X6D445TD@nospam.org wrote: >>> 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? >> >> Italian ice cream: yes[1]. >> >> US ice cream: if that's all that's available, yes >> >> Ice non-dairy-fat-whitener: no. >> >> [1] I was once in Copenhagen with a couple of days to spare, >> so I thought "I know a good ice cream shop in Stresa (on >> Lake Maggiore, Italy)". So I went there before going home. > > That is some trip from Copenhagen (been there too) to Italy.
It was free, courtesy of my InterRail ticket :)
> I am a big icecream consumer, one liter box from the supermarket every time I am there. > So I just emptied that one... > I use the empty boxes to store 'tronics parts: > http://panteltje.com/pub/ice_cream_boxes_IMG_6540.JPG > Temperatures have been the highest ever measured here this year. > Long ago I lived across the street from an Italian style (run by an real Italian) icecream shop. > Spend a lot of my time sitting there chatting, drinking coffee. > His coffee was very special too, own mix, never found that anywhere else.
30 years ago I used to visit an Italian ice cream shop in Tottenham Court Rd London whenever I was near there. They had a display cabinet maybe 1m*0.5m*0.5m full of trophies. Unfortunately they retired :(
On 09/05/2018 06:48 AM, Piotr Wyderski wrote:
> 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. > > &#4294967295;&#4294967295;&#4294967295;&#4294967295;Best regards, Piotr >
For the stuff they do, e,g, back-ends for Web sites receiving hundreds of thousands or millions of hits a day, being up to speed on the latest hip stuff in data structures is really important. The kiddie stuff I learned, linked lists, binary trees, insertion sort, etc. is fine as far as it goes but they're mostly obsessed with scalability and most of the kiddie stuff just doesn't scale well when dealing with the workload they see on the regular IRL. I have a book on modern PC game programming in C++ which has a lot of useful patterns for general-purpose embedded design as well. The "disagreement" here such as it is up to what you're doing, like if what you need your uP to do is crunch numbers as fast as possible in e.g. a laser controller than I can see why one might think all this OOP nonsense is tits on a bull. I don't really do much of that I'm doing stuff with complex menu interfaces etc. where the primary constraint is that the spec can be changed on a dime so I have to think more like a desktop/Web coder. My development "process" such as it is is try to write as much of it in generic ISO C/C++ for a desktop architecture as I can and then "port" it to either a bare metal embedded processor or one with some kind of embedded OS as the last step. I love analysis tools like Valgrind and Compiler Explorer and being able to do most of the work in Starbucks, once you have that setup you really don't want to go back to sitting at a bench all day and poking around with a scope and JTAG debugger. Or at least as little as possible.