Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:cost and durability (Score 1) 325

The main issue is that any watch over $200 is expected to last 10-20+ years. A smart watch is designed to last 1-2 years.

I'm sure that's not correct - people who buy those digital casios for $50 expect them to last for 10+ years. My $30 casio is over ten years old and I haven't even had to change the battery yet (it might be charging off sunlight).

Comment Re:Incidents vs. population? (Score 1) 269

To be fair, being only 4x more dangerous at this early stage of experimental testing sounds pretty impressive.

It's only impressive if you consider the problem solvable. It's irrelevant if the problem is intractable - we were "almost there" with AI for 20+ years before they finally figured out that the problem was harder than it looks.

I see the same thing with SDC. We've had good enough sensors for 20+ years. We've had the software that was 98% of the way there for almost 20 years. I give it another few years before the penny drops and the engineers realise they are trying to solve an intractable problem.

Comment Re:self-driving or assisted driving ? (Score 1) 186

Tesla has self-driving software under test, that mostly works with their current cars.

We've had software that mostly work since the nineties. It's still at the "mostly works, in perfect conditions" stage that it's been in for almost two decades.

It is not yet ready for the public, but that isn't because of any deficiencies in the sensors.

We've had adequate sensors for far longer than we've had software that mostly works.

Hardware isn't the problem. Software is the problem, a problem that hasn't been solved since the nineties despite the huge amounts of money thrown at it.

Comment Re:I bet half the people who said "C" actually (Score 1) 252

IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).

With exceptions: yes. I thought I read somewhere that had been done. Apparently not.

With new, that's only sort of true. The compiler provides new and delete as operators, but you'll get a link error since there's no runtime for them. You can of course few trivial functions along the lines of:

void* operator new(size_t s) noexcept { return nullptr; }

which fits the letter of the standard.

I doubt it - the standard specifies the behaviour of new, The type of free store management you want on an AVR is almost certainly domain specific anyway.

The compiler also certainly supports placement new.

Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!)

Depends on what you mean by "awfully stupid". It's very rare that throwing from a destructor is a good idea.

It's very common to throw from a constructor. In fact, that's the only way to signal an error in the constructor.

There's also no harm in using constructors which have no error condition. There's not much problem with failing to acquire resources: all resources on such small devices are entirely statically determined.

Memory, certainly. Nothing else, though. In embedded devices memory is statically allocated, but there are multiple *other* resources which can fail. Putting the initialisation in the constructor of a class while not being able to catch exceptions mean that the caller has no way to tell if a device is ready.

For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it.

I don't see why that's a problem.

It' a problem because double-initialisation (or double de-initialisation) of attached hardware almost always results in errors. An initialisation that occurs more than once is an error. Any initialisation needs to return error or success. Lacking exceptions, you can't put anything important in a constructor or a destructor.

So, sure, you can use classes, if you restrict yourself to classes with no exceptions, which means not using anything that relies on exceptions to signal errors. So, yeah, C++ works fine in embedded if you don't use constructors, destructors, overloaded operators, object assignment, object-as-parameters in function calls... probably a few other things too.

IOW, as long as you use a *subset* of C++.

Anyway, if you want a well-reasoned example, then there's this talk from the recent C++ conference:

The guy writes a simple Pong for his Commodore 64 using C++17, and keeps rather close track of the asm code being generated. He uses classes, constructors, destructors, lambdas, templates and compile-time computation.

Very unimpressing indeed. The C64 had a ton of impressive software - a spreadsheet, first-person-view mazes, platformers... and yet using C++ he could only fit a pong clone into it? This example is a case *against* C++, not for it. FWIW, I wrote a pong clone for the C64 when I was 10, and I recall taking a single weekend to do it, using a fraction of the available ram. Why not compare the C++ pong with the existing pong binaries for the C64?

Comment Re:I bet half the people who said "C" actually (Score 1) 252

Sorry, no. It's a *subset* of C++.

It's complete non-hosted C++, with templates, lambdas, namespaces, interitance, constexpr, r-value references, auto, and so on. The C++ standard notes that non-hosted platforms are not required to provide the standard library.

IIRC, a freestanding implementation still has to provide 'new', 'delete' and exceptions, none of which are capable within the avr-gcc + atmega328 that the arduino uses (last I checked, anyway).

Without exceptions you'd be awfully stupid to use constructors/destructors (can't return error values!), which means your composite objects will have to be written using functions to create and destroy them.

For all practical purposes, you would not be able to use classes because creation/destruction would occur without the user knowing about it. You'll run into a similar issue when you try to do polymorphism without exceptions.

So, yeah, it's a pretty significant portion of C++ that can't be used.

Comment Re: As it should be (Score 1) 230

The software was 98% there 18 years ago. That last 2% hasn't been achieved in 18 years, yet you think it will be achieved in the next five?

Please cite a source for your otherwise made up numbers.

Sure thing, from the history of self-driving cars


n 1994, the twin robot vehicles VaMP and Vita-2 of Daimler-Benz and Ernst Dickmanns of UniBwM drove more than 620 miles (1,000 km) on a Paris three-lane highway in standard heavy traffic at speeds up to 81 miles per hour (130 km/h), albeit semi-autonomously with human interventions. They demonstrated autonomous driving in free lanes, convoy driving, and lane changes with autonomous passing of other cars


In 1995, Carnegie Mellon University's Navlab project completed a 3,100 miles (5,000 km) cross-country journey, of which 98.2% was autonomously controlled, dubbed "No Hands Across America".[37]


Also in 1995, Dickmanns' re-engineered autonomous S-Class Mercedes-Benz undertook a 990 miles (1,590 km) journey from Munich in Bavaria, Germany to Copenhagen, Denmark and back, using saccadic computer vision and transputers to react in real time. The robot achieved speeds exceeding 109 miles per hour (175 km/h) on the German Autobahn, with a mean time between human interventions of 5.6 miles (9.0 km), or 95% autonomous driving. It drove in traffic, executing manoeuvres to pass other cars. Despite being a research system without emphasis on long distance reliability, it drove up to 98 miles (158 km) without human intervention.

SDC's have gotten more hype the last five years than many Apple products. This does in any way mean that there have been advances over the 158km stretch of self-driving that occurred in 1995.

Comment Re:Hey Lunkhead - "Before testing them" (Score 1) 230

"Before testing them". Not before selling them. Before *testing* them.

They want to run their tests on real roads with real people; they want to put at risk innocent bystanders who are not in the least bit remotely interested in their product.

Before putting your untested crap on the road to drive amongst uninterested third parties, they *should* be validating the shit out of the system.

Real roads and real people are not there for your personal use as guinea pigs.

Comment Re:Not one business to remain! (Score 1) 230

government of California will not be satisfied until the last evil "business" has been driven from the state...

I'm surprised they don't test in the 3rd world where fewer formally care if people die from mistakes.

Because the traffic conditions are far from perfect, and the state-of-the-art in SDC battles to handle anything but near-perfect conditions.

Comment Re:RULE #1 (Score 1) 230

This time - when someone gets killed - the code review should start the same day.

Code reviews do not help with machine-learned algorithms. The algorithm is opaque even to the developer. They should not be using machine-learning and/or neural nets to steer cars. The resulting systems cannot be reviewed for accuracy and reproducibility. They can only be tested.

Comment Re:Now I know what self driving car not to buy (Score 1) 230

Brilliant and informative post. I do have a few questions myself:

-Invalid pointers (pointers not checked for validity before being used)

How do you check a pointer for validity? You can only check for NULLness, right?

-No runtime stack monitoring to ensure it doesn't overflow

How do you check this? Most uCs don't have a valgrind (although the newer Atmels have MPEs) and I'm not sure how hard it is to add stack canaries to the compiler.

Slashdot Top Deals

"Confound these ancestors.... They've stolen our best ideas!" - Ben Jonson