Although TI are a lot more forthcoming with datasheets they will still hold back information on things like the DSP core inside an ARM SoC. So you get DSP based codecs as binary blobs and no information on how to target the DSP yourself. And then further up, in the same family, you'll get a similar processor that *does* have an accessible DSP core... but you have to pay for the privilege in chip cost (and it only makes sense to do that if you actually need that feature).
Then again, as you said, TI are good at letting you buy small amounts of these chips as well as devkits so it makes sense for most of the information about the chip to be accessible. There's no chance of going to Farnell and buying one of these Broadcom processors.

Apparently so.

From the video that someone linked to and may be somewhere in TFA:

'But the calculations are not done on this device themselves, they're done in the cloud *air quotes*... which is over here' *points*
I chuckled. And wanted to punch someone in marketing.

I take it a bitch isn't one of those problems though?

As long as they use some kind of virtual machine / presentation system that is supported by multiple platforms, then there would be no problem.

It'd need some way of presenting text and graphics (using some standardised system to represent that data), a way to control the rendering of that media and finally, a way of describing how interactive client-side behaviour would operate. If everyone agrees on how these three features would be described and represented, as well as how the network protocols would operate, then it would provide a solid platform to develop applications such as these... and possibly others!

Two lines?

if(1)
    strupr(mystr);

Is that what you meant?

Hello and welcome to the internet!

We all hope you enjoy your stay here and are confident that you will soon become accustomed to the local customs and culture.

Lots of love,
The Internet

True
False
FileNotFound

I'd say password protected and undocumented is far more hidden than a unpopulated footprint marked 'jtag' (I know I know, not all hardware debug i/faces are always that obvious either :-)
But yeah, no one should be particularly surprised... these are ridiculously complex chips and would be impossible to develop and debug (the chip that is, not software for it) without extra hidden circuitry.

I'm just guessing, as the site is still inaccessible, but it sounds like this is a set of debug functionality beyond what you'd get with the normal debug registers or with a JTAG interface. AFAIK modern desktop/server processors still have JTAG interfaces (not just SoC, embedded type processors). Sure JTAG interfaces are often 'hidden' as you say... maybe there's a footprint there but you have to solder on some flying leads or a connector.. but without knowing about these new registers you still wouldn't be able to use these debug features over JTAG.

Too right! Forget 'the year of Linux on the desktop', this is 'the decade of Linux in the thing'.
A catchier name is required though.

Because not everyone has the time, ability or inclination to put down a uController in a schematic, surround it with power circuitry and whatever basic logic and signal conditioning they might need, then layout a PCB for that schematic, then send off their design to a PCB house or make it themselves using one of a few different methods, before finding out that they messed something up that they can't fix with a cut-and-strap (or that it doesn't work but they don't know how to fault-find well enough to fix the issue) and have to GO TO 10 until they get it right.

Arduinos and other similar development/prototyping boards are great for people who are happy to plug various building blocks into each other to get the overall hardware design they need and want to get something working quickly and easily, without getting bogged down in a lot of the stuff usually involved in embedded design and development.

I've got no desire to play around with Arduinos as I much prefer working at the lower level (eg. PIC asm or C), or the higher level (eg. Linux on ARM9), but on more than one occasion I have recommended them when non-embedded developer friends have started talking to me about an embedded project they would like to tackle but don't know where to start.

(just realised this is way off-topic, but meh)

Having read your post, I'd say that any issues you come across in a word-processing package are most likely of your own doing.

Being Jewish doesn't necessarily have much to do with being Israeli (and vice-versa).

Thanks for the reply!

That makes more sense. Luckily for me the RMS stuff was done in hardware and I just had to sample an ADC... and I was writing this all in C.
Given the situation you outlined, I imagine it would've taken me a while longer as well. :-)

Not wishing to troll, but... Really? I recently had to implement a similar thing for a public transport voice announcement system (certain parts of the world require ambient noise compensation on their passenger announcements (plus sometimes customers want that anyway)).
As you say, running average (or similar) of RMS is a key part of it... but other than some very (very) simple logic and arithmetic (basically scale the volume (up to a limit) based on a scaling of the RMS against a calibrated value), nothing more was needed.
Was it particularly more complex when implementing this for use in a room (as opposed to on a vehicle)? I guess the more dynamic nature of TV/film vs. passenger announcements would probably make it a bit trickier.
Just curious :-)

(Oh and I agree on your last statement. The problem has only existed 'cos advertisers know they can get away with it, nothing technical at all!)