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.
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
'Tis zimple hehe
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.
Not when the customer says "oh, I need /that/, but also I need something like that but also with /this/ little change".
It is akin to applied philosophy: extracting the essence of what a customer needs, and codifying that in an executable form.
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.
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:
China is already there it it seems:
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 wrote in :
How about eating icecream?
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.
Assemblers are a lot simpler - it's rare to find a bug in them!
Of course.
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.
David Brown wrote
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:
mmm :-) But I did.
There should always be a serial port or at least a pin and software UART for debugging.
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.
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.
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.
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.
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
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, snipped-for-privacy@nospam.org wrote (in article ):
This successive approximation approach is well known in computer science, where it is called ?binary search? in English. As you note, it is very fast.
.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
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.
... provided there are no collisions. Ensuring no collisions takes arbitrary space - an example of the classic space-time tradeoff.
Tom Gardner wrote
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.
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:
Joseph Gwinn wrote
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?
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.
It was free, courtesy of my InterRail ticket :)
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 :(
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 t*ts 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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.