Get an FPGA development system and implement your hardware in the FPGA, then ask a chip manufacturer to turn it into an ASIC. Expect to pay bucketloads of money on the way, though. It's only feasible if either costs are not an issue or you expect the resulting device to be mass-proced (six or better yet seven digit numbers manufactured per yeat).
... the main task of GPUs is floating point calculations, and I doubt you need many of those when monitoring networks. Wrong tool for the job.
It's like saying that GPUs are "terrific" for Bitcoin mining, until you realize that they require one or more orders of magnitude more power for the same amount of processing than specialized hardware. And network monitoring is probably a common enough task that it's worthwhile to use hardware tailored to this particular job.
Strawman fallacy, don't be obtuse. I am aware that those substances contain trace amounts of alcohol, but you cannot consume enough of them to even approach the beginnings of intoxication.
You can, however, consume enough of them to have a non-zero BAC, provided the testing method is sensitive enough. You mentioned the yeast infection, too.
Wait 10 minutes for the liver to process it, then drive.
A regular liver processes alcohol at a rate that lowers BAC by about 0.01% per hour. Ten minutes isn't anywhere near enough time to significantly lower the BAC. If you're fit to drive 10 minutes after consuming alcohol, you would have been fit to drive right after consuming alcohol in nearly all possible cases.
... USB ports have to supply (and USB devices may draw)? Drawing more power is outside the spec.
Also, don't USB devices usually have to request the high power mode explicitly? Some USB power supplies are "dumb" and only supply power, but don't speak USB. Some devices are curteous enough not to draw 500mA if they haven't received permission from the USB host to do so. In this case, they'll slowly load with 100mA...
The reason they pulled me over is because they "saw me swerving". I was doing nothing of the sort.
It's a trick. Some people may actually confirm that they were swerving (even though they weren't, and the cop knows it). This is where fun for the cops start, because a) the person just admitted not following the rules and b) maybe they did so because they have something to hide, so they're a good target for any search they can can be tricked into consenting to.
Also, people will admit the craziest things. "Do you know why I've stopped you?" "Yes, officer, you stopped me because of the the dead body in my trunk! Oh no, don't tell me you stopped me because of the bag of drugs under my seat..."
Now, being forced to vote, as at least 50% of the people in the UK and USA are smart enough to realise, would mean being forced to vote FOR THE SYSTEM, regardless of which way a vote was cast.
Do they check if your ballot is actually valid, and if so, how does that work with elections being secret?
Also, not voting changes nothing. It's not a vote against the system, it's a vote of not caring.
Of course "driving is a privilidge' but from a libertarian standpoint, how much is it really?
Driving is not a privilege, but a right, to libertarians - as long as you do it on your own property. Driving on somebody elses property is not a right; you'll have to get permission and abide by the rules set by that somebody else, or just drive there.
'If I take my cruiser and I meet [reluctant witnesses] to talk, eventually they can follow me and say why were you in a back dark street for 45 minutes?'
This is where you pick the dark back street behind the donut shop.
That doesn't change the fact that there is no open GPU.
Well, the system could also stick with 2D acceleration only. I'm sure learning the proper use of that and maybe doing some 3D on the CPU (*) is more educational than learning how to prod and poke a proprietary blob to produce pretty pictures.
(*) Isn't that what David Braben is famous for? Elite, Zarch/Virus, etc?
... to cross interstellar distances even at ridiculously low velocities. Something travelling at less than 100 m/s will travel over ten light years in 65 million years. Chunks from Earth might have ended up in the Alpha Centauri system by now.
Btw, have we found any extrasolar debris in our star system? It might be like looking for a needle in a haystack, but I'm sure we could find some pieces of exoplanets right in our back yard.
Why would you need an ARMv7 when an ARMv6 is sufficient for all the things people use Pis for and costs less?
I don't think the type of the core changes the cost of the thing that much. The problem would be to find a SoC with low enough specs (no onbard Ethernet, etc) to fit in the $25/$35 price bracket.
Evidently, the Raspberry Pi B uses one USB port for the Ethernet connection, which looks like an expensive hack.
However I would like to hear more about why did go with arch programming (as in armv7) and not platform programming (as in raspi/bbb/whatever) and also, why not an OS on it in order to delegate the burden of arch specific stuff to the os devs?
I'm dealing with microcontrollers (48 MHz, 64 kB RAM) that only need to one certain thing (talk with an A/D converter via SPI on one side, do some processing and twiddle some port pins, talk to another computer over an UART on the other side). An operating system would just add unnecessary complexity, especially since the ARMv7-Ms interrupt controller provides all the features in hardware that I previously (on the ARMv4TDMI part) used an RTOS for.
Been there, done that (8051-based microcontroller; getting into 68k assembly and some Mitsubishi 16-bit uC to understand previous products, etc).
1. Price. They are DIRT cheap.
You can get dirt-cheap Cortex-M3 or (even cheaper) Cortex-M0 microcontrollers. If you then still worry about price differences to simpler 8-bit uCs, then you're probably not worried about blowing through a dozen during development, but about two cents difference when you're buying half a million of them per year for manufacturing.
2. Resilience. These old chips are incredibly resilient to noise.
Valid point. However, I usually deal with measuring voltages in the microvolt range, so the correct reaction of the product to harsh environments is to return to normal operation after the interference ends without having suffered lasting damage.
3. Energy consumption. These chips can work on microamps.
Newer chips can do that, too (Cortex-M3 or, if you're really looking at single microamps, Cortex-M0s).
If you've dealt with small 8-bit uCs, have a look at a Cortex-M3 part. It's not just faster, it contains some incredibly convenient features.
Although it's common sense that v4->v7 is a huge change, care to post some examples?
I dealt with a switch from ARMv4TDMI to ARMv7-M, which is slightly different from the other ARMv7 architectures, but here are some things I fould really helpful:
Intergration of the interrupt controller in the actual CPU core. In ARMv4TDMI, each chip manufacturer would have to tack their own interrupt controller onto the v4 ARM core, which then fiddled with the cores two interrupt lines ("normal" and "fast" interrupt). On an interrupt, the programmer then first has to figure out what actually caused the interrupt (by asking the tacked-on interrupt controller, usually) and react accordingly. Oh, and interrupt service routines had to follow certain conventions that made them different from normal functions, and nesting interrupts could cause all kinds of headaches. And of course since the interrupt controller is manufacturer-specific, you have to re-learn its workings every time you change chip manufacturers.
In ARMv7-M, not only is the interrupt controller the same for each chip (because it's part of the core and not a peripheral added by the manufacturer), it also uses a nice interrupt vector table that contains pointers to plain C functions (since interrupt functions follow the calling convention). Creating an interrupt service routine is as simple as writing a plain C function and putting its address in the vector table. The nested vectored interrupt controller also takes care of interrupt nesting (or rather, it does correct nesting as its default behavior) and has some nifty features like tail-chaining and correctly handling priorities of late-arriving interrupts.
ARMv7-M also dumped the ARM instruction set completely and only uses THUMB instructions. No more switching back and forth between two instruction sets.
Debug features also became part of the core, instead of each chip manufacturer coming up with their own solution and tacking it onto an ARMv4 core.
Hardware support for semaphores, which is nice for the (RT)OS folks (due to the new interrupt controller, I was able to kick the operating system out of my application, and I haven't been missing it.)
How can you be sure that you "solved" bugs in the closed part of the hardware? Oh, you can't.
All modern GPU have binary blobs.
As I said, a not-so-beefy, but open GPU would be my preference. This way, you can personally experiment with all kinds of creative ways of using, misusing and abusing the computing power in the GPU.
I've personally made the step from an ARMv4TDMI to an ARMv7 core and it was amazing how practically relevant the improvements were. It's not just a few new instructions here and there, but changes that made my work easier.
Slashdot Mirror
It's not stealing the car that will kill you, it's curiosity and greed coupled with ignorance of the radiation hazard sign.
"Oh, what's in this box? It's all locked up and covered in pretty symbols, so it must be something good." ...
Did they find any truck thieves that died of acute radiation poisoning nearby?
... then the company already knows who they will hire.
You haven't seen people watch a movie, play Angry Birds, ear a bowl of soup or make coffee while driving?
If we took 100 experienced US drivers and gave them a Western Australian driving test, I'd be surprised if 2 passed.
Indeed. They'd probably be driving on the wrong side of the road in the first place.
Get an FPGA development system and implement your hardware in the FPGA, then ask a chip manufacturer to turn it into an ASIC. Expect to pay bucketloads of money on the way, though. It's only feasible if either costs are not an issue or you expect the resulting device to be mass-proced (six or better yet seven digit numbers manufactured per yeat).
It's like saying that GPUs are "terrific" for Bitcoin mining, until you realize that they require one or more orders of magnitude more power for the same amount of processing than specialized hardware. And network monitoring is probably a common enough task that it's worthwhile to use hardware tailored to this particular job.
You can, however, consume enough of them to have a non-zero BAC, provided the testing method is sensitive enough. You mentioned the yeast infection, too.
Wait 10 minutes for the liver to process it, then drive.
A regular liver processes alcohol at a rate that lowers BAC by about 0.01% per hour. Ten minutes isn't anywhere near enough time to significantly lower the BAC. If you're fit to drive 10 minutes after consuming alcohol, you would have been fit to drive right after consuming alcohol in nearly all possible cases.
You want to keep thugs and goons from voluntarily following a head honcho, by force? That isn't anarchy, either.
So no juice, fruit or bread before driving? They all contain alcohol.
Also, don't USB devices usually have to request the high power mode explicitly? Some USB power supplies are "dumb" and only supply power, but don't speak USB. Some devices are curteous enough not to draw 500mA if they haven't received permission from the USB host to do so. In this case, they'll slowly load with 100mA ...
It's a trick. Some people may actually confirm that they were swerving (even though they weren't, and the cop knows it). This is where fun for the cops start, because a) the person just admitted not following the rules and b) maybe they did so because they have something to hide, so they're a good target for any search they can can be tricked into consenting to.
Also, people will admit the craziest things. "Do you know why I've stopped you?" "Yes, officer, you stopped me because of the the dead body in my trunk! Oh no, don't tell me you stopped me because of the bag of drugs under my seat ..."
Do they check if your ballot is actually valid, and if so, how does that work with elections being secret?
Also, not voting changes nothing. It's not a vote against the system, it's a vote of not caring.
Driving is not a privilege, but a right, to libertarians - as long as you do it on your own property. Driving on somebody elses property is not a right; you'll have to get permission and abide by the rules set by that somebody else, or just drive there.
This is where you pick the dark back street behind the donut shop.
" The GPU blob is an 18MB elf file, including libraries. It does an awful lot. "
Very well put.
Well, the system could also stick with 2D acceleration only. I'm sure learning the proper use of that and maybe doing some 3D on the CPU (*) is more educational than learning how to prod and poke a proprietary blob to produce pretty pictures.
(*) Isn't that what David Braben is famous for? Elite, Zarch/Virus, etc?
Btw, have we found any extrasolar debris in our star system? It might be like looking for a needle in a haystack, but I'm sure we could find some pieces of exoplanets right in our back yard.
I don't think the type of the core changes the cost of the thing that much. The problem would be to find a SoC with low enough specs (no onbard Ethernet, etc) to fit in the $25/$35 price bracket.
Evidently, the Raspberry Pi B uses one USB port for the Ethernet connection, which looks like an expensive hack.
I'm dealing with microcontrollers (48 MHz, 64 kB RAM) that only need to one certain thing (talk with an A/D converter via SPI on one side, do some processing and twiddle some port pins, talk to another computer over an UART on the other side). An operating system would just add unnecessary complexity, especially since the ARMv7-Ms interrupt controller provides all the features in hardware that I previously (on the ARMv4TDMI part) used an RTOS for.
Been there, done that (8051-based microcontroller; getting into 68k assembly and some Mitsubishi 16-bit uC to understand previous products, etc).
1. Price. They are DIRT cheap.
You can get dirt-cheap Cortex-M3 or (even cheaper) Cortex-M0 microcontrollers. If you then still worry about price differences to simpler 8-bit uCs, then you're probably not worried about blowing through a dozen during development, but about two cents difference when you're buying half a million of them per year for manufacturing.
2. Resilience. These old chips are incredibly resilient to noise.
Valid point. However, I usually deal with measuring voltages in the microvolt range, so the correct reaction of the product to harsh environments is to return to normal operation after the interference ends without having suffered lasting damage.
3. Energy consumption. These chips can work on microamps.
Newer chips can do that, too (Cortex-M3 or, if you're really looking at single microamps, Cortex-M0s).
If you've dealt with small 8-bit uCs, have a look at a Cortex-M3 part. It's not just faster, it contains some incredibly convenient features.
I dealt with a switch from ARMv4TDMI to ARMv7-M, which is slightly different from the other ARMv7 architectures, but here are some things I fould really helpful:
Intergration of the interrupt controller in the actual CPU core. In ARMv4TDMI, each chip manufacturer would have to tack their own interrupt controller onto the v4 ARM core, which then fiddled with the cores two interrupt lines ("normal" and "fast" interrupt). On an interrupt, the programmer then first has to figure out what actually caused the interrupt (by asking the tacked-on interrupt controller, usually) and react accordingly. Oh, and interrupt service routines had to follow certain conventions that made them different from normal functions, and nesting interrupts could cause all kinds of headaches. And of course since the interrupt controller is manufacturer-specific, you have to re-learn its workings every time you change chip manufacturers.
In ARMv7-M, not only is the interrupt controller the same for each chip (because it's part of the core and not a peripheral added by the manufacturer), it also uses a nice interrupt vector table that contains pointers to plain C functions (since interrupt functions follow the calling convention). Creating an interrupt service routine is as simple as writing a plain C function and putting its address in the vector table. The nested vectored interrupt controller also takes care of interrupt nesting (or rather, it does correct nesting as its default behavior) and has some nifty features like tail-chaining and correctly handling priorities of late-arriving interrupts.
ARMv7-M also dumped the ARM instruction set completely and only uses THUMB instructions. No more switching back and forth between two instruction sets.
Debug features also became part of the core, instead of each chip manufacturer coming up with their own solution and tacking it onto an ARMv4 core.
Hardware support for semaphores, which is nice for the (RT)OS folks (due to the new interrupt controller, I was able to kick the operating system out of my application, and I haven't been missing it.)
How can you be sure that you "solved" bugs in the closed part of the hardware? Oh, you can't.
All modern GPU have binary blobs.
As I said, a not-so-beefy, but open GPU would be my preference. This way, you can personally experiment with all kinds of creative ways of using, misusing and abusing the computing power in the GPU.
I've personally made the step from an ARMv4TDMI to an ARMv7 core and it was amazing how practically relevant the improvements were. It's not just a few new instructions here and there, but changes that made my work easier.
It's just another example of a well-marketed product beating technically superior products, which appears to happen 99.9% of the time.
ARMv6 is outdated, ARMv7 is the way to go. And I'd rather have a not-so-beefy GPU than one that takes binary firmware blobs.
Zero meters/miles/etc. "You haven't moved yet."