Microchip håller på med en uppdaterad version av PIC16 serien.
Mycket av det som upplevs som struligt (page/bank hanteringen)
är annorlunda och förrenklat. Plus nya aritmetiska instruktioner och
en hel del annat. Jag har en PDF som beskriver som beskriver den
nya arkitekturen, men har den inte uppladdad för tillfället. Om någon
har en bra server att lägga den på så kan jag maila över den...
PIC16F1000
Skall bli intressant att se vad som händer, men man skall nog inte övervärdera den som hobbyist. De nya PIC16 har nog mest sitt värde där det behövs mera kraft inom en viss kostnadsram. Den är ett mellanting till PIC18 och skall man byta är det lika bra att gå direkt på 18-serien, tycker jag i varje fall.
Problemet med minnesbanker är inte löst. Där finns ett 9-bit relativt hopp som mestadels löser det i löpande kod, men det kvarstår för subrutiner och därmed anser jag att problemet till stor del är kvar.
Addition/subraktion med carry har kommit till, det är självklara saker som borde funnits från början. Stöds bara vid aritmetik mellan ackumulator och minne, inte immediate data. Fast det är ändå en stor förbättring som tar bort mycket skräpkod.
Vid interupt så sparas/återställs (det senare INTE valbart) ackumulator, status och lite till. Som väl är kan de sparade värdena adresseras, så det går fortfarande att ha flera interruptnivåer, men detta har nog dessvärre blivit lite stökigare. IMHO en klart tveeggad "förbättring". I normala fall hade det varit bäst om detta stackats, men de gör väl inte det med tanke på att det skulle fälla vissa fult skrivna applikationer med specialtrixig kod.
Stacken är 16 steg, det är ett steg i rätt rikting och man slipper nog i de flesta fall att tänka så mycket på att akta så den inte "slår runt". Skulle detta hända finns en valbar fines som resettar processorn.
Det har tillkommit ett andra indesregister, men varför inte totalt tre? Ofta är det ju två strängar av data som skall bli en eller tvärt om och ofta skall indata bevaras. Dessa är 16-bit och bankfria. Det finns även dublettadresser för allt RAM med linjär adressering. Indexen har även funktioner för automatisk stegning, men på annat sätt än PIC18.
Indexregistren kan adressera även programminnet, hur de hanterar att detta är 14-bit hittade jag inte, kanske helt enkelt bara genom att endast läsa 8 bits.
En instruktion som tillåter relativ adressering av tabeller på det gamla sättet har tillkommit för att lösa problemet med placering av dessa vid bankgränser, undrar varför med tanke på indexregistren. Är det bara en extra utökning, eller finns det en hake någonstans eftersom denna anses behövas....
Problemet med minnesbanker är inte löst. Där finns ett 9-bit relativt hopp som mestadels löser det i löpande kod, men det kvarstår för subrutiner och därmed anser jag att problemet till stor del är kvar.
Addition/subraktion med carry har kommit till, det är självklara saker som borde funnits från början. Stöds bara vid aritmetik mellan ackumulator och minne, inte immediate data. Fast det är ändå en stor förbättring som tar bort mycket skräpkod.
Vid interupt så sparas/återställs (det senare INTE valbart) ackumulator, status och lite till. Som väl är kan de sparade värdena adresseras, så det går fortfarande att ha flera interruptnivåer, men detta har nog dessvärre blivit lite stökigare. IMHO en klart tveeggad "förbättring". I normala fall hade det varit bäst om detta stackats, men de gör väl inte det med tanke på att det skulle fälla vissa fult skrivna applikationer med specialtrixig kod.
Stacken är 16 steg, det är ett steg i rätt rikting och man slipper nog i de flesta fall att tänka så mycket på att akta så den inte "slår runt". Skulle detta hända finns en valbar fines som resettar processorn.
Det har tillkommit ett andra indesregister, men varför inte totalt tre? Ofta är det ju två strängar av data som skall bli en eller tvärt om och ofta skall indata bevaras. Dessa är 16-bit och bankfria. Det finns även dublettadresser för allt RAM med linjär adressering. Indexen har även funktioner för automatisk stegning, men på annat sätt än PIC18.
Indexregistren kan adressera även programminnet, hur de hanterar att detta är 14-bit hittade jag inte, kanske helt enkelt bara genom att endast läsa 8 bits.
En instruktion som tillåter relativ adressering av tabeller på det gamla sättet har tillkommit för att lösa problemet med placering av dessa vid bankgränser, undrar varför med tanke på indexregistren. Är det bara en extra utökning, eller finns det en hake någonstans eftersom denna anses behövas....
Är http://www.dalton.ax/pic/pic16f1000.pdf snabbare?Det var därför som jag inte postade den länken, den kändes inte
helt tillförlitlig. Det var dock därifrån jag plockade ner PDF'en...
Vad tror Ni om den nya versionen?
Personligen är jag tveksam till den, ser ingen uppenbar målgrupp. Det finns redan alldeles för många PIC-varianter, tvivlar på att marknaden behöver ett sådant här mellanting. Känns lite grand som PIC-världens motsvarighet till Intel's flopp-processor 80186.
Ändringarna i ett befintligt program är så pass stora att behövs de nya fineserna kan det vara lika braatt gå direkt till PIC18 istället.
En 100% kompatibel processor med "endast" lite nya instruktioner som t.ex. aritmetik med carry, fler index i tomma SFR-platser utökad stack med valbit i config och liknande små men nyttiga saker tror i varje fall jag skulle varit ett starkare alternativ.
Personligen är jag tveksam till den, ser ingen uppenbar målgrupp. Det finns redan alldeles för många PIC-varianter, tvivlar på att marknaden behöver ett sådant här mellanting. Känns lite grand som PIC-världens motsvarighet till Intel's flopp-processor 80186.
Ändringarna i ett befintligt program är så pass stora att behövs de nya fineserna kan det vara lika braatt gå direkt till PIC18 istället.
En 100% kompatibel processor med "endast" lite nya instruktioner som t.ex. aritmetik med carry, fler index i tomma SFR-platser utökad stack med valbit i config och liknande små men nyttiga saker tror i varje fall jag skulle varit ett starkare alternativ.
Det är svårt att utvärdera det innan det finns färdiga produkter.
Det beror ju även lite på vilka kapslingar de kommer i, hur prisbilden
ser ut o.s.v. Notera att det inte finns ett smack om denna arkitektur
på Microchips hemsida, så den kanske aldrig "släpps" alls...
Dessutom så kanske man snart även ska jämföra med "Microchip AVR"...
PDF'en laddade helt OK.
Detta är en PDF från senaste Micrpchip MASTERS, och där var den
sessionen under NDA. Jag har inte en aning om hur det är med det nu.
Vi kanske kan plocka bort den om någon vecka då alla har hunnit
plocka hem en kopia...
Det beror ju även lite på vilka kapslingar de kommer i, hur prisbilden
ser ut o.s.v. Notera att det inte finns ett smack om denna arkitektur
på Microchips hemsida, så den kanske aldrig "släpps" alls...
Dessutom så kanske man snart även ska jämföra med "Microchip AVR"...
PDF'en laddade helt OK.
Detta är en PDF från senaste Micrpchip MASTERS, och där var den
sessionen under NDA. Jag har inte en aning om hur det är med det nu.
Vi kanske kan plocka bort den om någon vecka då alla har hunnit
plocka hem en kopia...
