|
Afzaal Ahmad Zeeshan wrote: I am more of a "write-once use-anywhere" sort of guy
I agree but this doesn't always work well when your target platforms are vastly different. You can't write code that works well on a server with it's huge amount of resources and expect that to work well in an embedded device with limited processing power and RAM.
|
|
|
|
|
Quote: You can't write code that works well on a server with it's huge amount of resources and expect that to work well in an embedded device with limited processing power and RAM.
I wouldn't even bother thinking of the same thing, who would like to write the code for ASP.NET to run it on Arduino.
Raspberry Pi 2 is an exceptional case. I would love to write the code for ASP.NET website and host it on Raspberry Pi 2. Don't count Raspberry as a chipset? My bad.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
I personally work with mostly C++ for engineering/scientific applications.
|
|
|
|
|
... as such, until now, my challenge was always to make sure I could support the widest range of devices possible.
It's really the opposite of what is asked here, and I believe at least as challenging.
|
|
|
|
|
This is the typical case, the same happens with me
|
|
|
|
|
When you have to deliver real-time performances many subroutines may be thoroughly optimized. Where I work we have an assembler library with extra-optimizied functions to rotate and/or mirror 8 bit and 16 bit image buffers, plus I created from scratch a library to apply a normalization of the grayscale of those buffers. They all target systems from x86 to SSSE3, all Intel of course, with a function for every conspicuous change (all benchmarked of course).
If I'll change job I'd try to go for a similar one, where there is no everchanging bloated framework or the-next-big-thing-that-will-die-in-2-years.
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
den2k88 wrote: the-next-big-thing-that-will-die-in-2-days years FTFY
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
...you have to. Or pretty much, nothing is going to work...
In the PC world? No, I don't, and I have no plans to. PC Manufacturers change parts quicker than Lancia used to!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Still I'd love to own an original Delta or Thema (I loved them both, but the Delta Evoluzione 220 hp and Delta HF Integrale were absolutely mind blowing).
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
I know what you mean: I had a Beta HPE 2000, and loved the thing. But if you wanted a spare part, you had to take the old one with you as they changed components on a daily basis...
I think they just fitted whatever was on the shelf, myself.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
It still must be done for Lancia, Alfa and Fiat, to retrieve the correct spare you need at least to give the chassis number - that way they can trace the component list for that car. It is standard practice in Italy
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
I've done a lot of assembly with Amiga the old days...and would like to get some time to play with GPU programming to do some extra-fast math...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
It is called a 'hardware abstraction layer'. If it is device-specific, then it is part of the device-driver.
Device-specific code is a dependency that needs be eliminated.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
When it comes to embedded systems, it's never really that clear cut. If you want to use all resources available, you have to be flexible, otherwise your processes are going to be unnecessarily slow.
|
|
|
|
|
My Raspberri works fine using Mono - without the need for low-level hardware access.
It might not be that clear cut if you are working with a PLC or custom hardware. Otherwise, good luck in getting direct hardware access +)
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You need low-level hardware access to squeeze performance for certain applications.
|
|
|
|
|
Yes, so the popular saying goes.
If you are optimizing, you are not designing. Check out CUDA, or my own article on a RAM-disk.
What you need is to understand how the stuff works; you do not need to implement a serial com port, we have rather efficient drivers. Set a baudrate, some stopbits and off you are.
You wanna beat that com-port implementation?
--edit
Done a few embedded projects, in the time before .NET
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You must have been working on embedded processes where performance didn't matter... Let's see, I've been at it over a decade so...
|
|
|
|
|
Nice assumption; I'm not going to continue this thread
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: If you are optimizing, you are not designing.
This is debatable, in engineering applications one may have (and usually has) cost, platform, thermal, power or resistance requirements. Also not every interface is standard - even COM ports, I had to redevelop COM drivers a couple of times to interface with equipment that we couldn't change. The other solution was to lose the customer, and not a small one.
One optimizes when constrained, and that is the usual circumstance for engineers.
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
den2k88 wrote: in engineering applications one may have (and usually has) cost, platform, thermal, power or resistance requirements That would not include Revit.
Yes, if you develop hardware, you'll need to write your own driver; and yes, it will be specific to that part of hardware. In normal software-developing, this is not done.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Yes, if you develop hardware, you'll need to write your own driver;
Not only for that: even if you can only choose the hardware on which to implement - like the elaboration and control unit of most industrial machinery (labelers, cappers, metal detectors, X-Ray contaminant detectors and so on) is most of the times a standard PC. Still it may have requirements as being fanless because the machine has to be sealed towards dust or paricles, so high powered processors could not be mounted. Sometimes the customer mounted UPS can't support the power peaks of some equipment, further limiting the choices.
Of course if you consider producing an entire machine as producing hardware (albeit a colossal piece of it composed of other big and separate components) you are simply right, in normal software development this kind of optimization is not needed or not convenient at all. Nobody cares if an algorithm of image enhancing takes 1 or 1.2 seconds to run on GIMP, but the same algorithm used as a step for automatically eliminating bad products from a production line has strong constraints on response time.
Geek code v 3.12 {
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++*
Weapons extension: ma- k++ F+2 X
}
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
|
|
|
|
|
den2k88 wrote: in normal software development this kind of optimization is not needed or not convenient at all That is an understatement. It is not done in "normal" software development.
And yes, if you create the hardware, then you probably also need to create some software to use it, and it would be nice if that is optimized; but the average Joe that builds applications has no idea of the hardware, let alone that they optimize for a specific part of hardware.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: the average Joe that builds applications has no idea of the hardware, let alone that they optimize for a specific part of hardware.
Maybe you don't, but for some of us... it's our job to understand the software AND hardware and make it better if we have to. I'm an engineer, not just a "coder".
|
|
|
|