Hi all.
Is it possible to connect an paper 2.7" display from embedded artist to a spark core? and if so, how to do the pins mapping and which library would be the best to start with?
Sorry if this has already been asked, or obvious, I am a newbie in the field.
regards,
denis
@sharly09, can you provide a link to the embedded artist display? Also, you may want to do a forum search. Here is one item that turned up for example:
Indeed, I saw this thread but could not manage the pin assignment. here is what is available on the display
Display, 14-pin connector
Pin#: Signal
1: GND
2: 3V3
3: SCK
4: MOSI
5: MISO
6: SSEL
7: Busy
8: Border Ctrl
9: SCL
10: SDA
11: CS Flash
12: Reset
13: Pwr
14: Discharge
@peekay123 , here is the link for the display
and the pins assignment I have made
Display, 14-pin connector
Display:Pin# Spark CorePin#
1: GND GND
2: 3V3 3.3V*
3: SCK A3
4: MOSI A5
5: MISO A4
6: SSEL D0?
7: Busy D7
8: Border Ctrl D3
9: SCL A5?
10: SDA A4?
11: CS Flash D1
12: Reset D6
13: Pwr D2
14: Discharge D4
not sure this is correct …
thank you for your help.
regards,
@sharly09, I’ll have to look at the code to verify. I find it odd that the display needs both SPI and I2C but if I recall, the I2C is for an on-board sensor.
Yup, the I2C is used for an onboard LM75 sensor. Here is the revised pin-out
Display
Pin CorePin
--------------------
1: GND GND
2: 3V3 3.3V
3: SCK A3
4: MOSI A5
5: MISO A4
6: SSEL A2
7: Busy D7
8: Border Ctrl D3
9: SCL D1
10: SDA D0
11: CS Flash D5
12: Reset D6
13: Pwr D2
14: Discharge D4
You may or may not need pull-up (4.7K ohm) resistors on the I2C line (D0/D1) if they are not included on the board.
Any update on this? Did you get it working?
I’m actually looking at something a little larger. I’m possibly looking at the 7.4" mPico display (http://www.pervasivedisplays.com/kits/mpicosys740). So if we can at least get the smaller ones working, I have a platform to take off from.
Thanks!
–anthony
Hi Antony.
Yes, thanks to @peekay123, it worked with the 2.7" ePaper. Although it is very limited with the core (not enough memory to managed a bitmap) it does work the photon and the electron. But I did not try to make it work with partial updates.
I am using EPD_V231_G2 driver.
That’s awesome! And reason enough for me to at least start playing around with some things.
My goal is to build something similar to the BADGEr v4 (http://www.seeedstudio.com/depot/BADGErv4-p-1587.html) for use at conferences. But I’m thinking it would be easier to build it with the Photon as the primary driver, so I can grab images from a server, than to add the photon to the existing badge hardware. I could also get a larger display, though memory would still be an issue, even with the Photon.
Of course… I could be horribly, horribly wrong! 
Thanks!
–anthony
@aaltieri, from my own experience at the San Francisco Maker Faire, WiFi in a closed building also polluted with cell phones and a miriad of other WiFi APs made it basically unusable. As for using a bigger display, the BADGE uses a microSD which you can also use with a Photon to download the images to. The display does not require an image buffer since you are pulling them from SD so display size is not an issue besides cost.
@peekay123, Basically, that’s what I’m planning on as well. Essentially, the server would crete the bitmap, then the badge would download it to the (mini)SD Card. The idea is to get information to display in near real time. The server (Raspberry Pi 3) would also serve as the WAP, which I carry on my person at the conferences. So I’m hoping the signal won’t be so bad since it will be a whopping two feet away, max.
But your point is well taken.
So the larger question, would it be better to try to shoe-horn a Photon onto the BADGEr for connectivity, or to build a badge with the Photon as the core MCU? I’d be curious to hear your opinion on that.
Thanks!
–Anthony
@aaltieri, having the RPi3 as WAP is a good idea though there is no guarantee of connectivity in noisy environments. I’m not sure why you need to send images from the RPi to the display since you can pre-store all the images you want on the SD first then have the RPi simply indicate which images to display (direct TCP or via Cloud). Using e-paper will limit your refresh rate, especially with larger displays so “near real time” is fuzzy to me.
If you have the time and resources, I would design a badge around a Photon or P1 instead of bolting one on to an existing badge. Understand that in either case, power consumption will be high since WiFi will always be on. Mind you, if you are wearing an RPi3, power is already an issue!
@Peekay123 , So here’s part of my goal. I do a fair bit of work with xAPI. I’m using the pi as a learning record store that collects data from multiple sources, including this build: https://github.com/aa-altieri/MiFare-xAPI. The idea is that once every minute or so, the Pi would generate the WIF file from the last statement sent to the LRS, the badge would download that file to the SD card, and display it on the ePaper display. I’d also end up using the badge for a few other things later on. But this is the more immediate line of thinking. And why I’m looking at the larger 4.4 or 7.4 inch displays. I need it to be readable from three or so feet away.
I think at this point, power is the least of my worries! There are one or two smallish other problems I need to tend to first.
@peekay123 I’ve actually had GREAT experience using photons at conferences. I’ve not had any problems so far. Of course… now as I’ve said that…
