Op 14 oktober 2018 13:10:32 schreef hennep:
Ik heb geen idee of de truc met de nop van rew gaat werken met deze processor.

Als de NOP niet opcode 0 is dan moet je wat anders verzinnen. Als de 0 opcode niet voldoende dicht bij "doe niets" zit, moet je even wat anders verzinnen. Dat is echt geen "rocket science". Des noods schrijf je:


for (a = END_OF_ROM;rom[a] != unprogrammed; a--);
a++;
jump_to (rom[a]);

Nu maak je op het einde van de flash een tabel, waar het adres van je "main" instaat. Die groeit naar beneden en als ie je programma code tegenkomt ben je af en moet je een nieuwe 3.5 cent investeren.

De z80 had opcode 0 voor de nop en daarmee werkte dat wel. Toen ik ruim 30 jaar geleden ervaring op deed met assembler programmering op een PC-XT was ik verbaasd dat de nop instructie bij de 8088 niet op 0 zat. De 8088 kon het dus niet maar die had ook geen intern programmeerbaar geheugen dus was er geen noodzaak voor. Een controller in een OTP package is een ander verhaal.
Je kunt als je het definitieve programma in een OTP zet natuurlijk best het ongebruikte deel van van het geheugen initieel al vullen met nop's. Niemand die er dan nog iets bij kan proppen. Maar dit is een neveneffect, daar zijn OTP's toch niet voor bedoeld. Is OTP niet in het leven geroepen om productiekosten laag te kunnen houden, en is flash duur(der)?

Dat vullen met nops zodat ie niet verder geprogrammeerd kan worden is onzin. Je wilt misschien een fuse zetten (die heeft ie genoeg). dat het programma niet uitgelezen mag worden. Maar je moet er van uitgaan dat iemand die je apparaat zit te hacken er een eigen nieuwe OTP van 3.5ct op kan zetten. Dat kan je toch niet voorkomen.

OTP bestond voor EPROM en EEPROM en FLASH. Het is ouder en goedkoper. Of dat als je de kosten meeneemt van "weggegooide chips" nog steeds zo is betwijfel ik. Vaak niet. Vandaar dat veel meer flash chips gemaakt worden tegenwoordig.

Ik stelde de vraag over de productiekosten omdat ik het vermoeden kreeg dat er iets mis moest zijn met deze controller en dat men de hele productie voor een zacht prijsje op de markt dumpte. Het aanbod leek te mooi om waar te kunnen zijn. daarna zag ik pas dat de programmer zo duur was. De winst wordt blijkbaar anders gemaakt.

Die 135 daar zullen ze niet rijk van worden. Dat is niet de bedoeling. Veel fabrikanten sponsoren de "development omgeving" en "demo boards" opdat men uiteindelijk in serie-productie hun iets-duurdere-chips gaat gebruiken. Hier kan je inschatten dat de winst-per-chip zo laag is dat ze geen geld overhouden om hobbyisten te sponsoren die nooit meer dan een paar cpus gaan kopen. Of een rendement van 1% te hebben op die sponsor acties (1% van de gesponsorde personen gaat uiteindelijk grotere aantallen kopen).

Ze bieden het ding gewoon tegen kostprijs aan, en omdat ze er niet zo heel veel verwachten te verkopen zijn de ontwikkelkosten die afgeschreven worden per-exemplaar hoger dan jij fijn vind.

Voor een bedrijf die geen 30ct voor de STM32F030 wil neerleggen maar 3ct voor dit ding en dus 27 cent per CPU bespaart is die 135 dollar peanuts. Die heb je er al dubbel uit als je 1000 exemplaren van je product verkoopt.

In ieder geval is mijn interesse in het ding weggezakt nu ik de prijs van de programmer heb gezien. Als ook grote aantallen wil gaan produceren, wat ik niet verwacht, dan vind ik wel weer een OTP.

Ik ben wel verbaasd over de negatieve reacties over OTP voor hobbydoeleinden. Als je je bestaande AVR/PIC programmer voor deze chip zou kunnen gebruiken, of een andere goedkope programmer, wat maakt het dan uit dat de chips niet geherprogrammeerd kunnen worden. Je kunt al een groot deel van het ontwikkelwerk in de emulator doen en iedere test met een controller kost een paar centen.

Al heel snel zitten je bugs niet in jou programma, maar in de interactie tussen jou programma en jou hardware. Het is een gedoe om dan steeds je CPU los te moeten solderen en na tien keer is je print kapot en moet je weer een nieuwe bouwen...

Op 14 oktober 2018 13:10:32 schreef hennep:
Ik ben wel verbaasd over de negatieve reacties over OTP voor hobbydoeleinden. Als je je bestaande AVR/PIC programmer voor deze chip zou kunnen gebruiken, of een andere goedkope programmer, wat maakt het dan uit dat de chips niet geherprogrammeerd kunnen worden. Je kunt al een groot deel van het ontwikkelwerk in de emulator doen en iedere test met een controller kost een paar centen.

Ik snap wat je bedoelt, en zelfs voor ik dat filmpje van Dave zag heb wel eens zitten te fantaseren over het gebruik die spotgoedkope chips (ik refereer in dit topic reeds aan een chip van $0,085). Dat leek me wel een leuk alleskunnertje, maar toen ik er echt over ging nadenken kwam ik toch tot de conclusie dat het absolute bedrag dat je kan besparen domweg te klein was. Zelfs als een ATTiny85 >$5 gekost zou hebben, was dat nog steeds te weinig om van een serieuze impact op mijn hobbybudget te kunnen spreken. En met dat gegeven in het hoofd begon ik me pas zorgen te maken over de ondersteuning en het programmeren van deze chips. Ik geloof niet dat er echt was mis is met deze chips behalve de documentatie, maar voor €0,30 ga ik me geen regenachtige zondag zitten frustreren aan een slecht gedocumenteerde chip. Ik heb toch nooit meer dan een handvol µCs tegelijk nodig.

Op 14 oktober 2018 11:02:16 schreef rew:
Ik denk dat het z'n plek heeft waar tegenwoordig losse "glue logic" wordt gebruikt. Soms zit je met een super-handige DCDC conversie chip, maar z'n enable is verkeerdom voor waar die op aangesloten moet worden. Normaliter zet je er een 74HC04 in, of een 74HC1G04

Dan moet je eens kijken naar de ATTiny212 (€0,37 p/s bij Digikey) of de PIC16F15313 (€0,56 p/s bij Farnell). Die hebben een soort kleine FPGA ingebouwd. Ik kon de precieze functionaliteit van die ATTiny niet zo snel ontcijferen uit de datasheet, maar die lijkt vergelijkbaar met de PIC16F15313 met meerdere blokken van beide combinationele en sequentiele logica. Het heet verschillend bij beide chips, bij de ATTiny heet het een 'event routing system', en bij de PIC noemen ze het 'configurable logic cells' (CLC). Het zou mogelijk moeten zijn een ingang direct via de combinationele logica weer met een uitgang te verbinden. Geen info over de propagatievertraging, maar gegeven de snelheid van de chips (20/32MHz) zal het wel voldoende snel zijn voor het grootste deel van de toepassingen.

Voor deze bedragen kan je het je veroorloven µCs aan te schaffen alleen voor lijmlogica... Die losse gate-chips geven wel wat meer staffelkorting, dus voor de grotere volumes zal het niet echt meer renderen.

Op 14 oktober 2018 11:02:16 schreef rew:
Je moet je realiseren dat deze CPU is goedkoper dan de 5000 stuks prijs bij farnell voor de 74HC1G04....

Kijk, als het tijdkritisch is, dan gaat zo'n geprogrammeerde oplossing niet werken. Maar veel dingen zijn dat niet en dingen als "pa.1 = ! pa.0" kan iedereen in 1x in een OTP processor programmeren.

en bijkomend kan je direct al een stuk beveiliging inbouwen tegen namaak. ook al heeft die enkel 1 functie om het inverteren van een signaal

Op 14 oktober 2018 11:28:20 schreef Kruimel:
Ik kon ze alleen niet vinden voor minder dan €1,40 p/s, maar die nano's al helemaal niet. Waar had je die voor die prijs vandaan

hangt beetje van de wisselkoers af, nu vind je ze aan 17€ voor 10.
https://www.aliexpress.com/item/Freeshipping-10pcs-lot-Nano-3-0-contro…

de micro's vind je wel nog aan die prijs met de 328p chip erop (met 168P kosten ze 11€ voor 10)
https://www.aliexpress.com/item/10Pcs-Lot-Pro-Mini-Module-Atmega328-5V…

Op 13 oktober 2018 15:49:37 schreef Arco:
Flash is inderdaad wel een stuk handiger...
Bij sommige oudere pics (bijv. de 16C54) moest je een eprom versie gebruiken voor ontwikkelen.
Iedere keer 20min wachten als de uP op zijn gemak ligt te braden is ook niet erg fijn...

[bijlage]
Sommigen maakten het nog bonter: kleine Z8 cpu's van Zilog waren er alleen in OTP. (dus heel goed controleren en een emmer chips bestellen... :) )
(er was wel een emulator, maar werkte niet erg betrouwbaar)

Ik gebruikte zowel de EPROM versie als OTP's van microchip. Code geschreven in assembly en eerst uren lang simuleren in de simulator alvorens te branden.

Mijn ervaring met de simulator was dat deze uitstekend werkte.

Is het misschien een van die chipjes waar wat "added intelligence" :( >:) firmware in zit???

Op 15 oktober 2018 10:47:53 schreef Tidak Ada:
Is het misschien een van die chipjes waar wat "added intelligence" :( >:) firmware in zit???

Was het maar zo'n feest!
Een chip met een ip-stack voor 3.5 ct.

Zoiets zou je wel in een esp32 of iets anders met wifi kunnen verwachten.

Haha, zou wel lekker zijn, dan komt hij zeker in de categorie "leuke speeltjes"!

En wel wis en waarachtig, beetje bij toeval vond ik net een flashgebaseerde µC met 12 bit A/D voor €0,35 bij Mouser. Geen idee hoe goed de chip verder is, maar hier kan je ze dus ook voor een (iets minder) bescheiden bedragje krijgen.

@fcapri: Thanks, daar gaan er een paar van in mijn volgende order.

Blijkbaar is er een open source toolchain ontwikkeld om deze controllertjes te programmeren. Dave is bezig met een reeks van 5 video's hierover:

  • Deel 1 (inleiding en bestellen PCBs en onderdelen);
  • Deel 2 (SMD solderen, Dave zaagt hier veel over layouten).

De volgende 3 delen komen de volgende etmalen uit. Als iemand de nood voelt is het nu mogelijk een programmer te bouwen met het ontwerp op github dat bruikbaar is voor een reeks van hun processors. Ze hebben in de open source community blijkbaar ook een fatsoenlijke C-compiler en een emulator geschreven. Voor hen die dit interessant vonden misschien een optie?

Goedkope microcontrollers zijn altijd interessant.
Bedankt voor de link. Ik kijk regelmatig naar eevblog maar had dit nog niet gezien.

  • Deel 3 (Installeren van de firmware via DFU Bootloader)
  • Deel 4 (Prutsen met de SDCC C Compiler)
  • Deel 5 (Dave krijgt het niet werkend op een breadboard)

Als meer mensen er zo over denken kunnen we natuurlijk een groepsinkoop doen van bordjes/componenten (en natuurlijk een batch van de controllertjes). Voor het geld lijkt het wel een leuk projectje (al houd ik mijn reserveringen voor het nut van een OTP controller voor de hobbyist).

Voor wie geinteresseerd is staan de andere 3 afleveringen ook klaar.

Is het werkelijk handig om hier een inkoopactie voor te organiseren?
Ik vraag het me af of je gezamenlijk goedkoper kunt inkopen dan de BOM opsturen naar https://lcsc.com/
Je betaalt met een paar stuks al invoerrechten (Als je pech hebt en er uit wordt gepikt door de douane).

Het animo is trouwens al flink gezakt na aflevering 5.
Ik wil eerst wel eens zien wat er fout is gegaan.
Dave maakt op deze manier geen reclame voor Padauk.

Ha super, we hebben nu een mooi overzichtje! :)

Op 18 mei 2020 11:43:06 schreef hennep:
Is het werkelijk handig om hier een inkoopactie voor te organiseren?

Nee, een inkoopactie is niet zeer handig, ik zou moeten uitzoeken of het scheelt, maar ik denk dat ik ook bedank voor het extra werk... O-)

Het animo is trouwens al flink gezakt na aflevering 5.
Ik wil eerst wel eens zien wat er fout is gegaan.
Dave maakt op deze manier geen reclame voor Padauk.

Haha, dat had je moeten zien aankomen. Als je één of andere obscure micro aan de praat wil krijgen met een relatief kleine groep 'open source' ontwikkelaars erachter kan je niet verwachten dat het probleemloos 'plug and play' zal zijn. Ik zei al eerder dat het me een éénrichtingsweg naar een week frustratie leek, en Dave bevestigt dat nu wel een beetje. Die week is nu wat korter door de toolchain die is ontwikkeld, maar de paar euro die ik kwijt zou zijn voor een paar van de eerdergenoemde flash microcontrollers zou ik er zo voor over hebben om maar een uur aan frustratie uit te sparen. Fatsoenlijk ondersteunde microcontrollers zijn nu eenmaal ook niet zo duur.

Overigens was het probleem met Dave dat hij de verkeerde controller had gekocht, dat blijkt op 6:28. De nummering is tamelijk onduidelijk en ze stonden blijkbaar ook niet allemaal op de site. Dan wordt het een stuk meer werk om zo'n ding aan de gang te krijgen natuurlijk. Hij zegt zelf ook dat hij bewust een ongeëditeerde versie had gemaakt om te kijken hoe zeer dat beviel bij zijn publiek, en dit is het soort probleem dat je dan te zien zal krijgen.

Ik zie niet veel voordeel in knutselen met lugubere Chinese controllers.
(of 't moet zuiver voor de lol zijn om te proberen het werkend te krijgen.)

Voor iets meer als 2 kwartjes heb je een 'echte' controller... ;)

Het zijn Taiwanese controllers, dus hooguit obscuur maar dat mag de pret niet drukken. We zullen de komende jaren wel weer steeds meer Taiwanese producten tegen gaan komen vermoed ik.

Chinese zou ik trouwens ook niet per definitie luguber noemen, ze worden niet rechtstreeks door de CCP geproduceerd in Oeigoerenkampen meestal.

[Bericht gewijzigd door maartenbakker op (83%)]

Op 18 mei 2020 18:22:03 schreef maartenbakker:
Taiwanese controllers.

Een stuk minder revolutionair!

Dat maakt toch niets uit? Wat mij betreft moet je elk product/merk individueel op waarde schatten, en of die nu uit China of de VS (of Taiwan dus) komen is me om het even. Het geld dat ik met deze 'devices' over mijn hobbyleven kan besparen is me alleen de frustratie van het werken met een half gedocumenteerd platform niet waard. Wat Atmel bijvoorbeeld aan documentatie heeft geschreven voor de Atmega328 ga je als klein Taiwanees bedrijf niet snel inhalen, want dat is best veel werk. Als ik een revolutionair product-idee zou hebben gehad voor 'low-cost commodity type' producten dan was dit anders, maar daar valt met Westerse maandlonen niet snel wat te halen.

Dat goedkope spul van bijv. Holtek en Rohm zie je ook vaak in 'el cheapo' spul...
Bij 250 stuks al voor 28 cent: https://www.tme.eu/en/details/ht46r47-dip18/microcontrollers-others/ho…

Ik heb wel redelijk vertrouwen dat het een DIP18 is... ;)

TME Symbol: HT46R47-DIP18

Er zit ook een Engelse datasheet bij, wat scheelt. Al denk ik dat het eerder in het topic al wel al duidelijk was hoeveel goedkope microcontrollers er zijn, er zijn er best een rij genoemd.

Op 18 mei 2020 18:59:08 schreef Kruimel:
Dat maakt toch niets uit? Wat mij betreft moet je elk product/merk individueel op waarde schatten, en of die nu uit China of de VS (of Taiwan dus) komen is me om het even. Het geld dat ik met deze 'devices' over mijn hobbyleven kan besparen is me alleen de frustratie van het werken met een half gedocumenteerd platform niet waard. Wat Atmel bijvoorbeeld aan documentatie heeft geschreven voor de Atmega328 ga je als klein Taiwanees bedrijd niet snel inhalen, want dat is best veel werk. Als ik een revolutionair product-idee zou hebben gehad voor 'low-cost commodity type' producten dan was dit anders, maar daar valt met Westerse maandlonen niet snel wat te halen.

Het punt is dat je in zulke gevallen de ondersteuning moet zien in te schatten. Niet iedereen heeft de documentatieomvang van een Atmega nodig om iets nuttigs met een controllertje te doen, maar het zou handig zijn als het niet volgend jaar alweer van de markt verdwenen was.

TA vermoedde spyware en Arco had het over lugubere controllers, wat dat ook moge betekenen. Als je dat soort factoren serieus zou nemen en je ook hoopt dat de architectuur wat langer op de markt blijft, en je moet dat aan de hand van het land van herkomst inschatten omdat je de bedrijven totaal niet kent... Dan denk ik dat het wel handig is om te weten of een chip uit China komt of uit Taiwan. In het laatste geval is de kans op spyware, dode oeigoeren of van organen ontdane falungong aanmerkelijk kleiner en met een beetje geluk (maar garantie tot de deur) duurt de ondersteuning ook iets langer.

Blijft natuurlijk dat het gebruik puur voor de hobby toch een afweging blijft. Iedereen en z'n grootmoeder ontwikkelt op Arduino-achtigen en dus Atmels. Als je een simpele ziel bent en gewoon platte C of liever nog assembler wilt gebruiken en zelf je hardwareplatform definieert dan maakt het onder de streep voor de leercurve of bruikbaarheid weinig uit of je nu een attiny of een padauk gebruikt. Dan kan het wel leuk zijn om juist nader kennis te maken met dit soort compacte en extreem betaalbare controllertjes.

Met 'lugubere controllers' bedoel ik controllers die niet goed werken, of na een (half) jaartje al niet meer te koop zijn.
Wel leuk voor een fabriek die in een keer een grote batch maakt van een supergoedkoop 'gizmo' en de controller daarna nooit meer nodig heeft.

Ik snap niet waar die "angst" vandaan komt dat deze controller weer gaat verdwijnen. Als je een productielijn opzet om een hele reeks controllers te maken en je test de markt uit met een goedkoop product dan doe je dat niet om er direct weer mee te stoppen.
Dit product wordt geaccepteerd door een groep gebruikers die er een ontwikkelomgeving voor bouwt, dat betekent dat er geld kan worden verdient. Het enige logische vervolg is dat de prijs omhoog zal gaan.
Toen ik dit topic startte dacht ik dat er misschien een partij werd gedumpt die over was gebleven maar als ik zie hoeveel verschillende types er nu worden aangeboden, dan verwacht ik dat het een blijver is.

[off-topic]
Met "minder revolutionair" doelde ik trouwens op het feit dat Mao nooit op Taiwan is geweest.
Grappig dat daar dan weer een andere discussie uit ontstaat :-)
[/off-topic]

Ah, dus dubieuze duurzaamheid in plaats van gemaakt door mensen met 1 been in het graf ofzo. Ik kon het woord luguber niet helemaal plaatsen.

Ik sluit me aan bij hennep. Er is een gigantische markt voor en de gebruikers doen het om de prijs. De leercurve voor een architectuur valt weg tegen massaproductie en als je er eenmaal klant bent dan blijf je dat wel.

Op 19 mei 2020 11:19:41 schreef hennep:
Dit product wordt geaccepteerd door een groep gebruikers die er een ontwikkelomgeving voor bouwt, dat betekent dat er geld kan worden verdient.

De fabrikant kan het ding uberhaupt niet verkopen als ze er niet een compiler bij regelen. En dat kan best een betaal-compiler zijn.

Dat de open source mensen van SDCC geinteresseerd raken en dit als target toevoegen: Da's mooi maar heeft niets met "dat er geld verdiend kan worden" te maken.

Op 19 mei 2020 15:27:55 schreef rew:
[...]De fabrikant kan het ding uberhaupt niet verkopen als ze er niet een compiler bij regelen. En dat kan best een betaal-compiler zijn.

Een uitgebreider programma (Windows/MAC/Linux), een compiler/assembler (C/C++, ASM, BASIC) Ook handig; eenvoudige uitleg hoe je OTP aansluit en programmeert. (datasheet PMS150C is beknopt).