Hi folk,
I’m interesting to implement a system that download different files relying on a mechanism like ''switch case".
But I don’t know if is possibile with Core to download some file, for example from my dropbox account (files in Public folderand with semipermanent link). Someone can show me a code example to get some file from the Internet and store it on Core?
Thanks in advance.
I would say it’s possible, assuming:
to store the file. (20KB of SRAM, or 2MB external flash [no api yet])there are some http examples, which would have to be extended to handle binary data.
How big is your file? what kind of operation do you do on the files?
@Coffee, thanks for your reply.
I don’t know if is possible to access in a unencrypted mode also if you use the public shared file. Anyway, I can store the files on some server and access to them in http mode. I’ll know the size of file in the next few days, but doubt that is bigger than 20KB. Alternatively I will attach some external memory.
I have to download the file and show it one e-paper display.
Please, could you show me above http examples to handle binary data?
murgantia, BDub posted a great microSD library from choosatron that would fit your bill exactly. Check out this topic for more details. 
@peekay123 thanks, I will study this solution but I’m more interested in a solution that permit me to download images as need.
murgantia, the Spark has about 16KB of working RAM after all the stuff used by the firmware. If you are temporarily downloading an image and sending it to the e-paper display and then disposing of the image then you may not need a microSD if the RAM your code takes plus the image memory allocation is less than 16KB. Sounds cool and I look forward to hearing more!
FYI for the SD library, I’m seeing Write speeds of about 60 - 70KB/s and Read speeds of 200+KB/s. I would guess this is faster than the Core (i.e., CC3000) can download a file, but I would love to be wrong about that.
Keep in mind, for an ePaper display you need as much RAM/other storage available as there is pixels available on the screen as a buffer.
If you’re using the re-Paper board, it has built in SPI flash you can use for storage.
Hi guys,
you are all right. Just at this moment I’m knowing that my images will be 48KB. This information means that the possible solutions are:
For the point 1 actually the problem is that both sd shield and e-paper (7.4" kit of Pervasive Display) use SPI. Some hint to overcome this?
For the point 2… bufferized download is needed, but is it possible?
For the point 3: I consider this solution very bad
You can use more than one SPI device at a time, just use different pins for CS lines. What format are the images in?
If your display has a Chip Select (SS/CS) input.. most do, then you can just switch between the two. Even if you had a completely separate SPI bus, you would not likely directly pipe the data from the SD card to the display without some massaging.
Yes, the CC3000 buffers data for you... and it's waiting there until you grab it. I've downloaded 1MB files through the CC3000 and saved them to the SD card.
@timb Damn, you are right. Different CS line…multi-slave solution, not daisy chained. The images are in EDP format, specific raster graphics image file format.
@BDub what do you mean with ‘would not likely directly pipe the data from the SD to the display without some messaging’?
When you read the data from the SD card, it needs to go into RAM somewhere... you may need to reformat the data before you send it to your display, i.e. strip out comma delimiters or something like that.
@BDub: absolutely true! In my case the maximum packet size is 250 bytes (as maximum command size is 255 bytes.)
Hi @murgantia – did you get this running? How did you implement the ePaper? Is there any documentation of your work available?
Thanks in advance!