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).

In aanvulling op Opgelost: RC522 RFID lezer leest (sommige) kaarten niet. (Deel 1):

Eigenlijk heb ik een groot deel van wat ik van plan was in deel 2 te schrijven, toch al in deel 1 verwerkt. Er zijn echter een paar “losse eindjes”.

Van de blauwe kaartlezers uit deel 1 bestaan vele varianten (ook in andere kleuren, maar ik doel vooral op de pcb-antenne). Er bestaan echter ook kaartlezers met dezelfde chip, die via I2C communiceren (ipv. SPI). Bijvoorbeeld onderstaande groene:

RC522 I2C
Groene mini RC522-I2C RFID lezer

Ik heb daarvoor de bestaande SPI-library aangepast: https://github.com/lukelectro/rfid/tree/I2Csupport . Er zijn meerdere (en andere) I2C RFID library’s voor deze chip, daar kwam ik echter pas later achter. Het blijft een leuke oefening in OO-programmeren (Mede om die reden heb ik overerving gebruikt. Het had eenvoudiger gekund door de bestaande library te slopen en deels opnieuw te schrijven, maar dan voor I2C. Of nog beter: door communicatie met de kaartlezer te scheiden van de rest van de library en mogelijkheden te maken voor I2C, SPI en UART.).

Deze groene kaartlezer werkt erg goed. Uiteraard, geen enkele garantie dat als je er nu een (aantal) besteld, je dezelfde krijgt als waar ik mee getest heb, waarschijnlijk bestaan er ook meerdere varianten van.

Verder was ik ooit van plan nog wat meetgegevens te posten van de “blauwe” kaartlezers, maar daar zie ik denk ik maar van af. (Ik zou dan moeten uitzoeken welke meting ook al weer waar bij hoorde, plus dat er dusdanig veel varianten van deze lezer zijn dat je eigenlijk zelf zou moeten meten als het niet werkt met de condensatorwaarden die ik eerder postte. Bovendien, en dat is wellicht het belangrijkste argument: Ik werkte toen voor het eerst met een VNA en zou dus zomaar eens meetfouten gemaakt kunnen hebben). Mocht het je echter toch interesseren, vraag dan gerust in de reacties.

In “Show Your Projects” op CircuitsOnline.net heb ik dit project al eerder getoond, maar het is ook wel een blogpost waard denk ik. Al is een blog natuurlijk eigenlijk bedoeld om te mekkeren over dingen als een gebroken arm wegens een onoplettende automobilist*, maar ook dàt had ik al op CO geuit. Blijft dus over om hier het schema van de jongleerkubussen te posten, en wellicht te linken naar de software en de files die je nodig hebt om de behuizing te printen. Zodat alles mooi bij elkaar is.

En aangezien al die benodigde informatie al gelinkt is in bovenstaande, blijft de rest van deze blogpost over voor meer foto’s.

Want als u zo ver gelezen heeft als dit vraagt u zich allicht af hoe een “RGB jongleerkubus” er nu uit ziet, wat je er aan hebt, en/of hoe ik op het maffe idee ben gekomen ze te maken. Al weet u dus alvast waarom een verdere jongleerdemonstratie in foto of videovorm wat langer op zich zal laten wachten. [sensuurbliep] automobiprutser*! (bovenstaande jongleerfoto’s zijn uiteraard van eerder datum. Plan was eigenlijk voor m’n blog wat foto’s te maken met de MakerSpace als sfeervolle achtergrond, ipv mijn kast. Ja, die muur is geel, nee, dat ligt niet aan de foto. Ja ik kan met 1 hand tikken :). )

Om te beginnen met waarom: ik wilde een step-up led-driver maken, om iets te doen met RGB leds op een 3,7V lithiumcel waarbij ook blauw en groen fatsoenlijk stroombegrenst zijn. En daarmee gelijk de hardware van de stm32f030 beter leren kennen.

Een simpel serieweerstandje bij een blauwe led gaat het niet redden, als de stroom constant moet zijn: de accu kan variëren tussen de 4,2 V wanneer vol en de 3,0 V wanneer helemaal leeg. De spanningsval over de led is b.v. 3,2 V bij 20 mA. De weerstand zou dan 1 V / 20 mA moeten zijn als de accu vol is, oftewel 50 Ohm. De weerstand bij lege accu zou -0,2 V / 20 mA moeten zijn… Dus negatief 10 Ohm. En dan nog keurig mee variëren met de accuspanning ook… Da’s wel een heel bijzondere weerstand… vandaar de wens voor een step-up leddriver. Met enkele LED’s in serie blijven ze op 4,2V dan gewoon uit omdat de gezamenlijke drempelspanning hoger is, en kunnen ze mooi in stroom geregeld worden met een step-up met terugkoppeling over een serieweerstandje – zie schema.

En RGB leds zijn leuk, maar bewegende RGB leds zijn nog leuker. Verder kan ik een klein beetje jongleren. Dus, vandaar de jongleerbal. Of jongleerkubus. Want dat lijkt makkelijker stevig te printen te zijn, omdat er een boutje in alle 4 de hoeken kan. Een ronde doorzichtige bal uit 2 helften stevig dicht krijgen is een beetje een uitdaging. Die ik uit de weg ben gegaan.

Er zit verder een adxl345 accelerometer in, om het ding te kunnen laten verkleuren op moment dat ‘ie gevangen wordt. Gewoon constant verkleuren kan ook: de “tap” detectie van de adxl wordt gebruikt om van modus te wisselen. Zie software 🙂 En Schema :).

Wat je er aan hebt is dus dat je ermee kunt jongleren. Wat met een lange sluitertijd mooie foto’s oplevert. Al dan niet met 2e-gordijn flits.


Natuurlijk zijn er ook wat uitdagingen, b.v. m.b.t de valbestendigheid. Het blijkt echt nodig de behuizing stevig dicht te schroeven. Als de helften t.o.v. elkaar kunnen schuiven, b.v. omdat in de prototypefase de boel met een elastiekje dicht zit ipv 4 boutjes, schuiven zo de elco’s en spoeltjes van de print af:

Er zijn meer technische uitdagingen geweest in dit project, zoals zwevende ingangen die het stroomverbruik in sleep erg verhogen. Makkelijk te testen op breadboard met weerstandsarrays als externe pull-up:


En zoal wellicht een beetje terug te zien in mijn vorige post: “lol met wireless power transfer” heb ik overwogen de jongleerkubussen inductief te laden. Maar daar omwille van de eenvoud vanaf gezien. Laden via de schroefjes is betrouwbaarder stabiel te krijgen.

Wie geïnteresseerd is in technische details wil ik graag uitnodigen vragen te stellen als comment, dan kan ik daar wellicht weer wat leuks over schrijven. Dit was een meerjarenproject, met allerlei afleiding tussendoor, en om te voorkomen dat de blogpost over het project zelf ook erg lang wordt laat ik het er voor nu even bij.


voetnoot: (armnoot?)
*(die nog minstens zolang ik in het gips zit af en toe op dergelijk humoristische wijze genadeloos te pas en te onpas erbij gesleept zal worden als voorbeeld van hoe het níet moet… Vooral omdat ‘ie is doorgereden vind ik het een [censuurbliep]. Nou kan ík niet door met míjn rijlessen omdat die anonieme prutser er goed aan zou doen er een paar lessen bij te nemen…Ik kan/mag niet eens fietsen! Of jongleren! Neem dan je verantwoordelijkheid en stap uit/oepssorryhulpverleenverzekeringsgegevens… Nouja. dat dus. Kan ik toch nog mekkeren op mijn blog 😛 Ben ik stiekem best goed in.)