Hacker News Reader

Comment by rasz | Hacker News Reader

Do you really need multicore linux computer with gigabyte of ram to send temperature over the network?

Yep, that's a fair point: both the Raspberry Pis and the smart PLCs were indeed absolutely overkill for the project. However, they're what we know best, and minimising development time for a small prototype multi-site deployment was more of a concern than using expensive-ish hardware. For production, obviously we'd move to something less ridiculous.

That depends on how fast you're sending it, how you are sending it, how precise it is, and if edge calculations have to be run, and calibration workloads.

All valid points in 1985. Nowadays smallest cheapest microcontroller has more processing power than fastest desktop from 1995.

And in the last 30+ years do you think that maybe some of what we do with temperature data has changed? Or how we interact with a network? Or the data that sensors can produce?

If you think you can answer parents problems without even knowing the problem space, you're behaving foolishly.

Hey, it's alright - rasz just asked a question, and it was a fair one :)

There's asking a question to learn and there's indicating that someone did something the wrong way without understanding the problem space.

Understand the problem, then propose solutions.

Anything else is ass backwards.

OP described remote temperature sensor for a PLC. What you might want to do with data might changed, but how we gather it only got optimized down to specialized controller chips. Amplification, compensation, linearization - all taken care of by dedicated interface chips, something like AD849x, MAX6675/MAX31855 or ADS1118. There is nothing left to do at the remote end that cant be done further down the line. Measurement is pretty much Push Button, Receive Bacon to the point you can build your own soldering station with arduino, one of those chips, mosfet and a display module in 100 lines of code.

When it comes to sensors and latency, you can use a 200mhz cortex m3 with a bespoke runtime you write in a couple weeks, or you can throw a real OS on top of multiple Ghz and cores in order to make up for the overhead of having a real OS.

SRAM running at 200mhz with 1 cycle latency can perform what looks like miracles when placed side by side with DRAM running at LOLWTF Ghz that is stuck behind 100 cycles of delay talking to the CPU that first tries to work its way through multiple steps of onboard cache and lookup buffers and all sorts of fun things.

Embedded controls can do stupid amazing things with very little resources because all of a sudden you have removed a huge constant delay from all memory accesses.

Throughput, however, they don't do so well on throughput. :-D

Yep. DRAM latency is no joke -- ask your fancy 32 core 5GHz super-duper-scaler CPU to chase a linked list and it turns back into one of those old beige boxes with the turbo button, but with the turbo button not pressed!

Linked lists and SRAM are so much fun.... All sorts of data structures that are cache and dram unfriendly are a-ok in embedded land.

If I remember correctly, pressing the turbo button actually slowed down the CPU clock.

Linked lists are fine. Trees with tagged pointers less so.

No and you don't want it either. In lieu of reliable hardware (PLCs), it is what is needed for virtual PLCs.

Reply on news.ycombinator.com