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.
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.
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!
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.
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.
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!)
Its a safe bet that this chip has DMA capabilities for most, if not all of its built in peripherals. Otherwise you're left to perform interrupt or polling based data transfers which just wouldn't let it get anything done. I don't know this for a fact, but I'd say that all chips in this class have DMA capabilities. A few ARM chips now seem to have quite flexible DMA that allows for BitBlt operations which can be quite handy.
clearly was a pet that someone had so little thought for that they did not even bother to put a collar on.
Or maybe the cat didn't have a collar because the owner was worried about the risk of strangulation, which can happen even with elasticated collars. I don't think you can say that the owner didn't care about their cat because of the lack of collar.
I know this. My point is that in some cases the source is enough, because you can use knowledge of other visible aspects of the system (such as the bootloader) to create your own build environment. Somewhere else in the comments people were complaining about the fact that although you can unpack some source and build it, the method needed to create the binary image suitable for flashing on to the device is a complete unknown if you don't have build scripts. I don't think this is necessarily the case if you're prepared to put it the work and have the relevant knowledge.
Anyway, as you said, its all about patching the binary if you're gonna do it properly!
Actually... I've seen a few commercial ARM compilers that are supplied with microkernels (Keil is one that springs to mind). And the Linux distribution I'm currently using from Texas Instruments for one of their ARM chips is supplied with a gcc cross-compiler compiled for Linux and Windows (and I think even OSX).
As much as not having the build environment (ie. scripts) can be an annoyance, companies seem to often use uBoot or RedBoot [yes, citation needed, I know... this is just what I've seen so I could be very wrong], meaning that if you have an upgrade image to pick apart, you can work out how you're meant to be building your own upgrade image.
Slashdot Mirror
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.
99)... ... ... ...
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.
It was not easy
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!)
Dictionary man
aaaand Thesaurus boy!
you maybe need something like DMA
Its a safe bet that this chip has DMA capabilities for most, if not all of its built in peripherals. Otherwise you're left to perform interrupt or polling based data transfers which just wouldn't let it get anything done.
I don't know this for a fact, but I'd say that all chips in this class have DMA capabilities. A few ARM chips now seem to have quite flexible DMA that allows for BitBlt operations which can be quite handy.
What about that whooshing sound... how much do you care about that?
clearly was a pet that someone had so little thought for that they did not even bother to put a collar on.
Or maybe the cat didn't have a collar because the owner was worried about the risk of strangulation, which can happen even with elasticated collars. I don't think you can say that the owner didn't care about their cat because of the lack of collar.
Redboot is a boot loader, not a build environment
I know this. My point is that in some cases the source is enough, because you can use knowledge of other visible aspects of the system (such as the bootloader) to create your own build environment.
Somewhere else in the comments people were complaining about the fact that although you can unpack some source and build it, the method needed to create the binary image suitable for flashing on to the device is a complete unknown if you don't have build scripts. I don't think this is necessarily the case if you're prepared to put it the work and have the relevant knowledge.
Anyway, as you said, its all about patching the binary if you're gonna do it properly!
Actually... I've seen a few commercial ARM compilers that are supplied with microkernels (Keil is one that springs to mind). And the Linux distribution I'm currently using from Texas Instruments for one of their ARM chips is supplied with a gcc cross-compiler compiled for Linux and Windows (and I think even OSX).
As much as not having the build environment (ie. scripts) can be an annoyance, companies seem to often use uBoot or RedBoot [yes, citation needed, I know... this is just what I've seen so I could be very wrong], meaning that if you have an upgrade image to pick apart, you can work out how you're meant to be building your own upgrade image.
So, err, how did you come across that picture then?
Strange how a British website is selling stuff in dollars
Ooh and with that unification think of the DRM possibilities!
'splain me how ARM can be 'the embedded processor maker' at the same time as not making any processors, please.