experiments

Post thumbnail

Toen ik Aart vertelde over die ereader waar ik eerder over schreef bleek hij nog een ED060SC7 schermpje te hebben liggen, met daarbij een “inkterface” printje. Het inkterface printje bevat o.a. de voeding voor het e-ink schermpje, en de juiste connector om het op het schermpje aan te sluiten.

Inkterface

De voeding voor dit soort e-paper schermpjes is ietwat ingewikkeld, omdat ze +15 V, -15 V, +22 V en -20 V nodig hebben, naast de 3,3 V voeding voor de logica en een “contrast” spanning die van scherm tot scherm varieert maar vaak ergens tussen de -1 V en -2 V ligt.

Met de voeding in handen, en de juiste connector, moet er een microcontroller aan te hangen zijn. En met de heldere informatie en software van essentialscrap/eink moet er toch beeld op te krijgen zijn? Zeker als ik er b.v. een STM32 tegenaan gooi.

Dat viel ietwat tegen. Ik ben zo eigenwijs geweest het werkend te willen krijgen zonder de uGFX library (die essentialscrap gebruikt), en ook nog op andere hardware dan waar het voor bedoeld is. Grote kans dat ik daar ergens een vauwdtje heb gemaakt.

Ik wilde een snelle proof-of-concept, dus zodoende ben ik na wat zoeken uitgeweken naar de software van Zephray (github), omdat dit zonder uGFX kan werken en toch tekst en afbeeldingen kan tonen. Ik heb de agendafunctie etc. overgeslagen en alleen het deel van Zephray’s project gebruikt dat het scherm aanstuurt. Hiermee had ik al snel beeld. Na ervoor te zorgen dat het in- en uitschakelen van de voeding goed werkte (voedingen moeten op volgorde worden ingeschakeld) zelfs een stuk beter beeld. Maar wel in spiegelbeeld…

Eerste min-of-meer succes om beeld op het schermpje te krijgen
Beter beeld na op correcte volgorde inschakelen van de voedingen

Zephray’s software is echter bedoeld voor een ED060SC4 scherm. De ED060SC7 is anders dan de -sc4, en daardoor staat de tekst in spiegelbeeld. Na de X en Y as om te wisselen (in epd.c, rondom regel 602) staat de tekst wel goed:

Beeld!

Doordat de STM32F103C8T6 die ik gebruik te weinig RAM heeft om het hele scherm te bufferen stuur ik slechts een deel van het scherm aan. (De software van Zephray is bedoeld voor een STM32F207VET6, die is wat vetter qua ram). Maar de niet-aangestuurde rechter 2/3 is net zo wit als de achtergrond van de wel aangestuurde linker 1/3, dus dat valt niet zo op…

Essentialscrap heeft een slimme manier slechts een deel van het scherm te bufferen. Zephray heeft een slimme manier om grijstinten te tonen, waarvoor het nodig is om het hele scherm te bufferen. Voor deze snelle proof of concept heb ik niet geprobeerd beide slimmigheden te combineren, maar gewoon slechts een deel van het scherm gebufferd en slechts dat deel aangestuurd.

Nu weet ik dus dat dit scherm niet defect is, en dat ik de aansturing ervan voor elkaar kan krijgen. Dat bied weer mogelijkheden voor verder geknutsel met e-ink, bijvoorbeeld ook met het ED060XH3 of ED060XG1 scherm uit de ereader(s) waar dit mee begon.

I bought one of those Real Time Clock modules:

I noticed it has a diode and resistor to charge the battery on the back. But I plan on using a non-rechargable CR2032 cell. So these had to be removed:

modified RTC module for non-rechargable battery

I also removed the power LED, since I plan on using it in an alarm clock with a partly translucent enclosure, and I don’t want the light to disturb me at night.

I think these modules mostly get used with primairy (non-recharable) lithium cells, so why was that diode/resistor there in the first place? Charging those cells might lead to leakage (at best), or more spectaculair failure (explosion?) at worst.

If you had battery leakage or other issues with these modules, please let me know in a comment.

If you have one of these DS3231 modules and plan on using it with a standard CR2032 coin cell (non-rechargable), I’d strongly recommend removing the diode and/or resistor, as shown in the pictures above.

EDIT:
I’v measured the 32 kHz output on my 2 modules with a Agilent 34401A. According to the datasheet, this should be 32.768 kHz, typ@3v3. One of my modules outputs 32.763 kHz, the other 32.761 kHz at 3v3. This is 5 resp 7 Hz slow: 153 resp. 213 ppm, way over the specified 3.5ppm over temperature… It would cause me to be late at a rate of about 2 minutes a week. For comparison: my wristwatch does 30 Seconds a Month. So, probably I got out-of-spec or fake modules… Darn!

EDIT2: Those modules get used/sold with rechargeable/secondary cells as well. Makes little sense considering how long a primary cell would last in this application, but at least explains why there is a charger circuit on board.

EDIT3: More about the 32-Khz-out-of-spec problem, in Dutch, here: https://www.circuitsonline.net/forum/view/147354. Also: I’ve bought a known-good chip from Farnell and plan on comparing performance – more later. The chip I bought is a DS3231MZ+ , which has a MEMS-oscillator, not a crystal like the …SN has. So cannot be compared 1-to-1, because its 32 kHz output is not compensated (only the internal 1 Hz is, within 5 ppm.)

Recently I bought an USBasp, or at least that’s what I thought. I bought a clone that was advertised as  “USB ISP USBasp USBisp Programmer for 51 ATMEL AVR download support Win 7 64 (RANDOM COLOR)”, marked on the case as “USB ISP version 2.0” and “MX-USBISP-V5.00” on the PCB.

I intend to use this as a TPI programmer for attiny10, so I need the USBasp firmware that supports this. But it turned out not to be compatible… Unless the hardware is modified 🙂 . (So that’t what I did)

USB isp PCB and case
On the case it is labelled USB ISP version 2.0. On the PCB MX-USBISP-V5.00.

Upgrading the firmware is easy. Connect the 10pin connector to another programmers 10 pin Atmel ISP connector, put a jumper wire on the USBasp “update jumper” (Labelled “UP” in above picture), power the “usbasp-clone”, and load the new firmware using the other programmer. Plenty tutorials for that at various places on the web.

However… Before I updated the firmware, the USBasp was seen by my computer, as an “Atmel Incorporated”. After the update, it did not connect any more. It did not show with “lsusb”, and nothing in “dmesg” either. So, after the update, it does not work any more. I broke it. Let’s see if I can fix it too.

Turns out, the USBisp v2 I bought has a slightly different schematic. Among other differences, there is a 0R resistor on the board that connects one of the USB lines to another MCU pin (PD3). PD3 is unconnected in the original schematic. After removing this resistor, it worked again and connected to my PC as a “Van Ooijen Technische Informatica shared ID for use with libusb”, and it is usable with AVRdude as an USBasp (I tested reading an attiny10’s flash, and it worked).

Before that, I tried other modifications that might be needed also, but that by themselves had no effect. The other differences where that my board had a 1k8 pull-up on the USB D- line (R3 in original schematic), and R1/R2 where 100 Ohms instead of 68. So I replaced those resistors with the original values, just in case, but I think it would have worked with 1k8 / 100R.

Also I cut the trace from PD6 to one of the LED pins, as that connection is also not in the original schematic.  And while I was at it, I added a decoupling cap on a vacant spot on the PCB and soldered the mechanical pins on the USB connector.

After all these modifications, it looks like this:

modified USPisp
Modified USBisp

Zoom in to see the red dots marking changed components and the red line indicating the trace I cut.

So now, I have a TPI programmer for my Attiny10’s. And if you bought the same or a similar enough USBisp or USBasp and ran into the same issue putting USBasp firmware on it, now you know how to fix it 🙂 (See first picture for PCB & case markings).