Whilst everyone here knows what a 'COG' is, and what 'HUB RAM' is, what about the casual browser?
To get the concept across would 'HUB RAM' be better called 'SHARED RAM' and 'COG' not be better called 'PROCESSOR' or 'CPU'?
And '16Kx32x8' is a bit confusing. That would normally reads as 16K instances of RAM each of which is 32 bytes.
Do you always criticize the baker's bread while he's still kneading the dough?????
Fair go, I have hardly started and I am testing the waters. However, understanding how hub RAM is partitioned helps to understand that it can be fast just as we understand why Flash is 128-bits wide in some 32-bit CPUs. Shared may mean a possible "resource busy" to some but hub means something where everything connects to at the same time. A lot of these terms are not for us to determine anyway. This is Chip's baby and for Parallax to produce and market.
The dough is fine. The bun is nearly in the oven, as they say.
I think it's a good point though. Anyone stumbling across such documentation will wonder what on Earth is that? And move on. But if they saw "32 bit core" they might start salivating at the sight of 8 of them and be driven to investigate further.
"HUB RAM" I'm not so worried about. It says "512K" and "RAM", that is good to go.
Strongly suggest you remove the SanDisk and stylized SD logos.
I was going to suggest the same thing, but I wasn't sure if I should wait until the bread is done rising or wait till it's in the oven. Actually, I think the little pictures of the uSD card and the flash chip should be removed entirely. The list under "16K ROM" includes SPI Flash and SD Boot.
The list in the "16K ROM" block were added after the images of the microSD, and I wouldn't want to use another brand when I always recommend SanDisk, would I? But this is mainly playing with possibilities as I have layers on my drawing file so that I can add connecting lines and rings for instance, but they seem to clutter, so I hide that layer. The "images" are on such a layer. An image of a microSD and SPI Flash I would probably show connecting to the "chip" (but spaced out further) in some circumstances, to help one visualize, just as a block diagram does, but in other circumstances, just the basic diagram.
There is a disclaimer that it could be trademarked but nothing seems to have come of that. That said, selling products with a trademarked logo attached will likely attract a lot more attention from the trademark owners than some general information articles.
“What car did you learn to drive stick shift on?” == “What was the make and model of your first car?” -> Password reset!
What's a stick shift???
I learn't on a column shift! Right hand shift, right hand drive in Oz.
Actually, I lied. I learnt on a VW floor shift, then the '52 IH truck.
Testing by copying large video files (1 to 3 GB) initially netted great results. It was writing at a smooth very fast 70 MB/s. But it didn't last. If I kept going without giving it a break then not far over 2 GB, maybe 3 GB, and it was stuttering really badly. It would even come to a halt at times. It would never exceed 20 MB/s and anything over 5 MB/s was only brief. Actually worse than my much older bland Class 10 rated Adata cards. I've tried TRIMming it but that's not supported.
If I give it a break then things are better. The 70 MB/s is very nice when it works.
[/Rant mode]
The only step up is the ExtremePRO. But that's more than twice the price again so I'm not particularly game to try it on the off-chance the sustained write rate might be a lot better.
I note Samsung now have their EVO and PRO branding on uSD cards too. I don't really have a good reason to buy more SD cards though.
Yes, this is a sore point with me, the lack of transparency with any and all Flash, be it USB or SD, USB3 or "USB33" etc. However if you want "sustained" write speeds look for the stylized "V" symbol where V30 means sustained (as long as you can) write speeds of 30MB/s. This is actually much faster than a class 10 card which is only equivalent to a V10.
However, for P2 work the random access latency is more important than the actual sustained write speed. I'm pretty sure you could write all 512K to any card and it wouldn't have any trouble keeping up with what is essentially only 10% of a single 12MP'ish photo.
One thing I'm keen to investigate is how wifi-SD cards (Electric Imp, Eye-fi, other proprietary options) play out with the SD boot. Could be a simple way to achieve IoT with P2
One thing I'm keen to investigate is how wifi-SD cards (Electric Imp, Eye-fi, other proprietary options) play out with the SD boot. Could be a simple way to achieve IoT with P2
Eye-fi sold out to Minolta years ago and are designed to operate through one of their servers which is no longer possible. They were good and I still have some but I also happen to have a IIRC Transcend WiFi card, but that would make a poor IoT. Better off with the cheap ESP chips.
I was listening to a workshop talk during the week about the ULP on the ESP. 4 x 16 bit registers, limited access to slow memory and peripherals. It was interesting kind of like the earlier programmable smart pin idea. State machine kind of stuff.
Wow, I just found a couple of Kingston branded 32 GB uSD cards I bought some years back for my old MP3 player. I must have paid a decent amount for them, I don't know. I don't even remember buying them now.
And the crazy thing is they are good for 36 MB/s sustained writing speed. It's soooo steady! No gaps, it's just wow, I never knew these things could do that. 9 GB over 4 files in quick succession. All four looked the same graph.
I've just done a 10 GB single block copy to that Sandisk. It took 763.5 seconds, so 13.4 MB/s. That's actually better average than I imagined, given how bad the graph looks. But certainly not worth paying a premium for.
Attached is the graph for this one block copy. It's more spiky but less noisy than the earlier file copies. The upper "Read File" line is a darker blue, this is where the block copy has read it's data from. Here's the console text:
evanh@controlled:/media/evanh$ umount /dev/sdk1
evanh@controlled:/media/evanh$ sudo dd if=/dev/sda3 of=/dev/sdk bs=1G count=10
10+0 records in
10+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 763.544 s, 14.1 MB/s
EDIT: One odd piece is at about 2/3rd's the way along the graph it notably bursts for maybe 2 GB or so. Similar to a clear start.
The Kingston SD card, in the same USB3 card reader, produces a solid block of write data. Right to the very end. It doesn't look noisy even. And that was just ordinary file copies.
EDIT: Oh, yeah, I've not got the Prop2 SD adaptor built yet. Got a little side tracked the moment I decided to spend the extra money.
Evan,
Presume that's Windows or *nix. Either way, there's no way to tell if it's the PC delays causing the poor throughput.
Unlikely it is the O/S as Linux definitely doesn't have a problem with throughput, but it could very well indeed be the card reader as they vary widely in quality, even the internal ones.
If it was the reader it would be bad for both cards.
I've actually used another good USB3 reader too. I haven't used it much for the latest tests but I was switching three different USB3 card readers around before deciding it wasn't making any difference.
I'm confident the Sandisk is not performing. It could be a faulty part maybe. I guess I should complain to the shop. That'll probably be a battle, but I guess I won't know unless I try.
If it was the reader it would be bad for both cards.
I've actually used another good USB3 reader too. I haven't used it much for the latest tests but I was switching three different USB3 card readers around before deciding it wasn't making any difference.
I'm confident the Sandisk is not performing. It could be a faulty part maybe. I guess I should complain to the shop. That'll probably be a battle, but I guess I won't know unless I try.
Can you identify the card's internal ID? I wonder if it is a genuine SanDisk or an ebay SanDisk. If you were running TAQOZ it lists this information when mounting it.
Comments
Latest block diagram "artwork"
To get the concept across would 'HUB RAM' be better called 'SHARED RAM' and 'COG' not be better called 'PROCESSOR' or 'CPU'?
And '16Kx32x8' is a bit confusing. That would normally reads as 16K instances of RAM each of which is 32 bytes.
Do you always criticize the baker's bread while he's still kneading the dough?????
Fair go, I have hardly started and I am testing the waters. However, understanding how hub RAM is partitioned helps to understand that it can be fast just as we understand why Flash is 128-bits wide in some 32-bit CPUs. Shared may mean a possible "resource busy" to some but hub means something where everything connects to at the same time. A lot of these terms are not for us to determine anyway. This is Chip's baby and for Parallax to produce and market.
I think it's a good point though. Anyone stumbling across such documentation will wonder what on Earth is that? And move on. But if they saw "32 bit core" they might start salivating at the sight of 8 of them and be driven to investigate further.
"HUB RAM" I'm not so worried about. It says "512K" and "RAM", that is good to go.
Nice looking graphic I must say.
Isn't that what engineers do?
Yeah, but you owe me a beer. That's what engineers do!
Shouldn't the LUT RAM overlap between cogs? Instead of 4 LUTs per two cog, shouldn't it be 3 LUTs per two cogs?
I was going to suggest the same thing, but I wasn't sure if I should wait until the bread is done rising or wait till it's in the oven.
The list in the "16K ROM" block were added after the images of the microSD, and I wouldn't want to use another brand when I always recommend SanDisk, would I?
There is a disclaimer that it could be trademarked but nothing seems to have come of that. That said, selling products with a trademarked logo attached will likely attract a lot more attention from the trademark owners than some general information articles.
What's a stick shift???
I learn't on a column shift! Right hand shift, right hand drive in Oz.
Actually, I lied. I learnt on a VW floor shift, then the '52 IH truck.
I've just purchased a new uSD card with its SD adapter. I figured it was time to try out something rated for video recording, so I paid extra and got a Sandisk Extreme 32 GB uSD card - https://www.sandisk.com/home/memory-cards/microsd-cards/extreme-microsd
Testing by copying large video files (1 to 3 GB) initially netted great results. It was writing at a smooth very fast 70 MB/s. But it didn't last. If I kept going without giving it a break then not far over 2 GB, maybe 3 GB, and it was stuttering really badly. It would even come to a halt at times. It would never exceed 20 MB/s and anything over 5 MB/s was only brief. Actually worse than my much older bland Class 10 rated Adata cards. I've tried TRIMming it but that's not supported.
If I give it a break then things are better. The 70 MB/s is very nice when it works.
[/Rant mode]
I note Samsung now have their EVO and PRO branding on uSD cards too. I don't really have a good reason to buy more SD cards though.
However, for P2 work the random access latency is more important than the actual sustained write speed. I'm pretty sure you could write all 512K to any card and it wouldn't have any trouble keeping up with what is essentially only 10% of a single 12MP'ish photo.
Eye-fi sold out to Minolta years ago and are designed to operate through one of their servers which is no longer possible. They were good and I still have some but I also happen to have a IIRC Transcend WiFi card, but that would make a poor IoT. Better off with the cheap ESP chips.
I was listening to a workshop talk during the week about the ULP on the ESP. 4 x 16 bit registers, limited access to slow memory and peripherals. It was interesting kind of like the earlier programmable smart pin idea. State machine kind of stuff.
And the crazy thing is they are good for 36 MB/s sustained writing speed. It's soooo steady! No gaps, it's just wow, I never knew these things could do that. 9 GB over 4 files in quick succession. All four looked the same graph.
They have the U1 logo.
Attached is the graph for this one block copy. It's more spiky but less noisy than the earlier file copies. The upper "Read File" line is a darker blue, this is where the block copy has read it's data from. Here's the console text:
EDIT: One odd piece is at about 2/3rd's the way along the graph it notably bursts for maybe 2 GB or so. Similar to a clear start.
Presume that's Windows or *nix. Either way, there's no way to tell if it's the PC delays causing the poor throughput.
The Kingston SD card, in the same USB3 card reader, produces a solid block of write data. Right to the very end. It doesn't look noisy even. And that was just ordinary file copies.
EDIT: Oh, yeah, I've not got the Prop2 SD adaptor built yet. Got a little side tracked the moment I decided to spend the extra money.
Unlikely it is the O/S as Linux definitely doesn't have a problem with throughput, but it could very well indeed be the card reader as they vary widely in quality, even the internal ones.
I've actually used another good USB3 reader too. I haven't used it much for the latest tests but I was switching three different USB3 card readers around before deciding it wasn't making any difference.
I'm confident the Sandisk is not performing. It could be a faulty part maybe. I guess I should complain to the shop. That'll probably be a battle, but I guess I won't know unless I try.
Can you identify the card's internal ID? I wonder if it is a genuine SanDisk or an ebay SanDisk. If you were running TAQOZ it lists this information when mounting it.