Getto AVR programmerare

[Mindmapper]

Bra info. Är på gång att starta med 128'an.

[limpan4all]

MEGA128 är bra har använt den i några projekt.
Totalt några tusen st förbrukade...
Men den börjar bli lite ålderstigen nu.
För nykonstruktioner så använder vi LPC2106 och håller på att flytta oss till LPC2368 som är billigare och har mera kraft samt CAN och Ethernet internt.
Mot MEGA128 har vi använt Realtec 8019AS men den suger, så vi har bytt till Davicom DM9000 som funkar mycket bra till sist.
EMC mässigt så har vi inga problem med dom konstruktioner som inte kräver externt RAM. I alla konstruktioner med externt RAM så är adresslatchen den stora störsändaren, vi har provat ett antal typer men det verkar inte spela så stor roll vilken familj man väljer. En bra och genomtänkt ledningsdragning löser iochförsig problemet .
Ett starkt tips: adress och databitar behöver inte komma i "rätt" ordning till ett SRAM vilket gör ledningsdragning väldigt mycket "bättre"/lättare.

Problemen som vi har haft med MEGA128 förutom de EMC relaterade är.
Alla problem har varit EE2PROM relaterade, vi har skickat 4 exemplar till Atmel för analys men inte fått någon respons alls, vilket är dåligt.
Den klarar inte alltid sina specade 16MHz ca 2% fallerar initialt.
Om man går ner till 14,745MHz så fallerar 0,5% initialt.
Om man går på 11.0592MHz, 0% fallerar.
Dom som inte funkar rasar nästan alltid vid EE2PROM accesser.
Några enheter ca 0,2% har "tappat" minnet (rensade EE2PROM) inom 24 månader efter leverans, efter dessa 24 månader så är felutfallet 0% hitintills.

[Mindmapper]

Jag har tänkt använda 8019. Jag har inga större krav på hastighet men vill att det ska funka. Vad som är viktigt för mig är att det är lätt att komma igång. Tillgängligheten är också viktig.
Är det inte stor sannorlikhet att de problem du beskriver med hastigheten beror på ESD? Tycker att Atmel ska ha så bra koll att det inte ska behöva förekomma hastighetsproblem. Om de inte svarar på sånt tappar man förtroendet. I varje fall borde de hört av sig med en ursäkt av något slag.

[limpan4all]

Lägg ned 8019AS den suger, vi har lagt ned mer än 400 timmars programmering på att få den att funka. Den funkar bra ett tag men är inte stabil. Vi lyckades aldrig fullständigt komma fram till varför. Identiska utrustningar kunde gå mellan 1 och 200 timmar utan problem, det fanns aldrig någon systematik i felbilden, ALL timing var väl inom sina specar. Inga kända TCP/IP stackar finns för 8019AS som funkar stabilt i tusentals timmar. Välj DM9000 istället lite svårare att hitta stackar/implementationer men funkar mycket bättre.
Nej, problemen beror definitivt inte på ESD.
Vi ett tillfälle i början när vi hade upptäckt problemen testade jag igenom två kartor (180st) MEGA128´or mot STK500/STK501 med olika klockor (oscillatorer). Då var det uppenbart att några MEGA128´or inte följde sina specar, det var dessa som skickades till Atmel.
Nej, jag har inga ESD problem i min miljö vid denna typer av tester, då skulle allt kunna certifieras om jag så ville...

[Micke_s]

Varför inte ENC28J60 istället. SPI för spara pinnar

[limpan4all]

Använder ENC28J60 mot LPC2106.
Vi väntar fortfarande på det nya kislet som reder ut en del irriterande buggar... Det skulle kommit förra årsskiftet!!!
Såvitt jag vet finns det inte ännu (B7 löste inget av prestandaproblemen eller timingbegränsningarna).
Senaste kiselrevisionen som säljs finns dessutom bara i vissa kapslingar.
Men den kan fås att fungera från och med B4 kisel med "kreativ kodning" som min programerare sa! Men prestanda är/blir rätt dåliga totalt sett.

DM9000 är den bästa "8 bitars" Ethernetcontrollern hitintills men den går inte att implementera runt en LPC2106 och utrymmet räckte inte för MEGA128+RAM så därför vart det EN28J60 mot LPC2106.

[Micke_s]

Bäst är väl annars att ha en processor med inbyggd ethernetdel ?

[limpan4all]

Det är därför det kommer att sitta en LPC2368 i det som konstrueras hädanefter, den är dessutom billigare än MEGA128 eller LPC2106 i kronor för CPU´n ensam, Ethernet PHY´n kostar ju under 20:- så totalkostnaden blir avsevärt lägre än CPU+Ethernetcontroller separat.
Till nackdelarna hör dock att man får vara bland de första att avlusa all SW.

[Mindmapper]

Tack för tipsen. Ska forska mera i ENC28J60 låter trevligt med SPI. Är dock beroende på att det finns TCP/IP-stack, då jag inte fixar en sådan själv.

[limpan4all]

Förståligt, min programerare har lagt ned runt 1000 timmar på att testa ut och förbättrea diverse olika IP-stackar och han tycker att det är en satans djungel

[Micke_s]

Nära 7 månader, usch vilket arbete. hoppas ni säljer många av dessa prylar.

[limpan4all]

Faktiskt inte ännu, bara något hundratal sålda och inte ens i närheten av break even.
Jag har väl lagt ner runt 600 timmar på alla dessa plattformar i HW jobb.
Men vi har andra produkter som kan bära dess utvecklingskostnader.

Ethernet har inte kommit fullt ut inom vårt område ännu, standarden är inte spikad än.

Men kunskap är makt, vilket gör att vi kan påverka standardiseringsarbetet så standarderna blir bra och som vi vill.
Vilket så småningom även ger bra pengar hoppas vi.
Tro mig, det är industrin själva som skriver alla dessa olka standarder som vi alla måste följa och maken till hur mycket tjuvknep och rackarspel som pågår i kulisserna hade jag aldrig kunnat tro

[Micke_s]

Jo, standarder brukar vara lite skumma ibland.

[jesse]

... och jag vill tipsa om att denna tråden är 2 år gammal och jag skulle tro att trådskaparen har löst det...

Jo, det var jag som väckte den igen... med min fråga om varför det inte går lika bra med den enkla lösningen med en parallellport och några motstånd? Vad är skillnaden mot en programmerare som är "avancerad"? Vad går jag miste om? Kan det uppstå problem / begränsningar med motståndsmetoden?

(Jag kan inget om microcontrollers och programmerare än - men jag försöker lära mig)

[Micke_s]

En "avancerad" programmerare har skyddskretsar och är generellt snabbare än vad en dator är eftersom den bitbangar.
På den "avancerad":e skickas längre meddelande samtidigt.

En annan sak är att färre och färre datorer har LPT port nuförtiden.