Hur mycket jag än ogillar MS så måste jag nog anse att PICen är ganska öppen. PICs instruktionsformat är öppet och dokumenterat och MPLAB genererar en standard hexkod.
För mig är vitsen med öppen/fri kod att det är gratis samt att jag slipper låsa mig till en leverantörs produkter, men det gör jag ju ändå om jag skriver för en PIC eller AVR eller annan..
Har du annars kollat på:
http://forum.microchip.com/tt.aspx?forumid=182
Linux och PIC
AndersG: Med ditt resonemang så är alla program öppna. x86-arkitekturen är väldefinerad och "öppen", samt är alla Windows-program i standard EXE-format. 
sodjan: Med öppen källkod kunde hela communityn bidra med förbättringar, samt göra den porterbar för andra miljöer, för att nämna en liten den fördelar.
sodjan: Med öppen källkod kunde hela communityn bidra med förbättringar, samt göra den porterbar för andra miljöer, för att nämna en liten den fördelar.
> PICs instruktionsformat är öppet och dokumenterat och MPLAB genererar en standard hexkod.
Nu var det källkoden till själva MPLAB i sig, som speakman syftade.
Inte den "källkod" till PICs som man skriver m.h.a MPLAB...
Varför någon skulle behöva "pilla i källkoden" till MPLAB förstår jag inte.
Även om man är väldigt nyfiken av sig...
> Vågar jag lita på att Wisp648 fungerar ... Xwisp2...
Tja, det är väl bara att prova själv.
Nu var det källkoden till själva MPLAB i sig, som speakman syftade.
Inte den "källkod" till PICs som man skriver m.h.a MPLAB...
Varför någon skulle behöva "pilla i källkoden" till MPLAB förstår jag inte.
Även om man är väldigt nyfiken av sig...
> Vågar jag lita på att Wisp648 fungerar ... Xwisp2...
Tja, det är väl bara att prova själv.
Du missförstår mig. Om man bortser från rent religiösa argument, sådant som bla FSF sysslar med, så är poängen med öppen mjukvara och standarder att man inte låser in sig till en viss tillverkares lösningar. Vilket du tex gör då du använder Word etc som är slutna format.Med ditt resonemang så är alla program öppna. x86-arkitekturen är väldefinerad och "öppen", samt är alla Windows-program i standard EXE-format
Vilket naturligtvis är alldeles sant. Bäst vore om Microchip gjort MPLAB som en plugin i Eclipse tex.Med öppen källkod kunde hela communityn bidra med förbättringar, samt göra den porterbar för andra miljöer, för att nämna en liten den fördelar.
Till deras processorer, ja, men det har inte med MPLAB att göra. Jag kunde precis lika gärna låsa till AVR eller ARM eller någon annan TLA.Du låser väl ändå ditt MPLAB-projekt till Microchip?
Om jag skriver i assembler så blir det så, man låser sig till en processorfamilj, eller till kompatibla sådana (tex z80 som kan köra 8080/8085-kod). Alternativet är att skriva i något högnivåspråk, men då blir programmen ändå låsta, eftersom IO-arkitektur etc är olika.
I teorin kan man naturligtvis abstrahera hårdvaran, men det är knappast vettigt för denna typ av projekt. För at inte tala om att den resulterande koden inte kommer att rymmas i processorns RAM...
Prsonligen använder jag VisualStudio för C++ på Windows, Eclipse för Java och MPLAB för PIC.
Själv använder jag GPASM/GPUTILS. För bränning använder jag det utmärkta programmet picprog, som hittas på http://www.iki.fi/hyvatti/pic/picprog.html. Fastnade för det direkt eftersom det klarar av att bränna till en PIC16F887.
"Varför någon skulle behöva "pilla i källkoden" till MPLAB förstår jag inte.
Även om man är väldigt nyfiken av sig..."
Man kan vända på frågan: Vad har Microchip för anledning att inte tillhandahålla källkoden?
Min egen anledning att vilja se källkoden är att jag skriver på ett eget EDA-program. I framtiden kanske jag vill ha in en PIC-simulator som plug-in till programmet. Det kan vara svårt om man om man inte har tillgång källkoden.
Jag använder t.ex. för närvarande Gnucap som spicesimulator, och då har det många gånger varit ovärderligt att titta i källoden för att komma vidare. Att kunna mejla författaren är också väldigt bra. Har t.ex. fått hjälp av både Al Davis(Gnucap) och Bill Cheng(Tgif) med flera. Tgif är ett ritprogram som är en förlaga till mitt program.
Jag betvivlar att jag får hjälp av Microchip i sådana ärenden. M$ skulle jag aldrig ens våga kontakta!
Även om man är väldigt nyfiken av sig..."
Man kan vända på frågan: Vad har Microchip för anledning att inte tillhandahålla källkoden?
Min egen anledning att vilja se källkoden är att jag skriver på ett eget EDA-program. I framtiden kanske jag vill ha in en PIC-simulator som plug-in till programmet. Det kan vara svårt om man om man inte har tillgång källkoden.
Jag använder t.ex. för närvarande Gnucap som spicesimulator, och då har det många gånger varit ovärderligt att titta i källoden för att komma vidare. Att kunna mejla författaren är också väldigt bra. Har t.ex. fått hjälp av både Al Davis(Gnucap) och Bill Cheng(Tgif) med flera. Tgif är ett ritprogram som är en förlaga till mitt program.
Jag betvivlar att jag får hjälp av Microchip i sådana ärenden. M$ skulle jag aldrig ens våga kontakta!
Nej, den främsta poängen med öppen mjukvara är att man inte är beroende av att nån annan vill hålla den vid liv. Om den nuvarande utvecklaren överger programvara så finns källkoden fri och om man nödvändigtvis vill ha den programvara så kan man fortsätta utvecklingen själv eller betala nån annan att göra det.AndersG skrev: Du missförstår mig. Om man bortser från rent religiösa argument, sådant som bla FSF sysslar med, så är poängen med öppen mjukvara och standarder att man inte låser in sig till en viss tillverkares lösningar. Vilket du tex gör då du använder Word etc som är slutna format.
Om vi tar Word som ett exempel. Har du försök få MS att göra en skräddarsydd version av Word åt dig? Vad svarade de på det?
Med Open Office så kan du ta källkoden till valfri konsult och be dem snajda till en skräddarsydd version.
Och vad gör de som kör Word den dag MS lägger ner utvecklingen? Visst, om dokumentformatet är standardiserat så kan man byta till annan programvara som tar samma dokumentformat. Men assemblerspråk är tyvärr inte så standardiserade (särskilt inte makrohantering och liknande) så det är inte så lätt att flytta över källkod från en kompilator till en annan. (Använder man ANSI C är det lite lättare.)
Men källfilerna är enkla textfiler som kan flyttas...Även om man kan lyfta ut källfilerna så kan det vara ett enormt jobb att bygga ihop projektet på nån annan platform.
För att den inte är "snygg"? För att de använt komponenter som i sin tur är upphovsrättsskyddade?Man kan vända på frågan: Vad har Microchip för anledning att inte tillhandahålla källkoden?
Visst, men är det ett reellt hot?Nej, den främsta poängen med öppen mjukvara är att man inte är beroende av att nån annan vill hålla den vid liv. Om den nuvarande utvecklaren överger programvara så finns källkoden fri och om man nödvändigtvis vill ha den programvara så kan man fortsätta utvecklingen själv eller betala nån annan att göra det.
Har inte frågat, men de skulle antagligen svara att skall använda VBA..Om vi tar Word som ett exempel. Har du försök få MS att göra en skräddarsydd version av Word åt dig? Vad svarade de på det?
Somjag sedan inte får någon support på, dvs en så kallad okynnesanpassning..Med Open Office så kan du ta källkoden till valfri konsult och be dem snajda till en skräddarsydd version.
Gråter.Och vad gör de som kör Word den dag MS lägger ner utvecklingen?
Missförstå mig inte. Jag har arbetat med mjukvaruutveckling, kommersiellt sedan början av 80-talet. Jag har sett många komma och gå. Jag är inte överdrivet imponerad av Microsoft heller.
Det går naturligtvis att vänta allt hur man vill...
> Nej, den främsta poängen med öppen mjukvara är att man inte är beroende av att nån annan vill hålla den vid liv.
Men det är man ju i alla fall ! Hur många användare av "öppen" programvara
är det som har möjlighet att *själva* ta hela ansvaret för den ?
Nej, öppet eller inte, i princip alla är i alla fall beroende av att någon
annan tar något slags ansvar för den. Problemet med "öppen" programvara
är att det inte finns någon som man kan dra åt tummskruvarna
på när det blir problem.
Den främsta poängen med icke-öppen programvara är att man vet vem som
håller den vid liv och att någon tar ansvar för den.
> Med Open Office så kan du ta källkoden till valfri konsult och be dem snajda till en skräddarsydd version.
Det är är naturligstvis helt hypotetiskt och konstruerat.
Hur stort är OpenOffice ? Jag tror inte att det är något som man bara
"snajdar till" något av så där på en kafferast. Sannolikt skulle ingen
vilja ha resultatet av en sådan "snajdning".
Samma sak gäller med alla anndra populär programvaror, PHP, Apache,
MySQL, whatever. Av alla som använder dessa och liknande programvaror
är det oerhört få som har kunskap och resurser att göra något själv
med den.
> Vad har Microchip för anledning att inte tillhandahålla källkoden?
Det kan vara mycket. IP, så klart. Användning av andras skyddade koder.
Jag hoppas att MC inte tillhandahåller källkoden, så att jag vet
vem som tar ansvar för det och att jag vet att det finns en dokumentation
från samma källa som är korrekt o.s.v.
Jag ser det alltså som en garanti att MPLAB kommer att supportas och
utvecklas att det *INTE* släpps löst hur som helst...
> Nej, den främsta poängen med öppen mjukvara är att man inte är beroende av att nån annan vill hålla den vid liv.
Men det är man ju i alla fall ! Hur många användare av "öppen" programvara
är det som har möjlighet att *själva* ta hela ansvaret för den ?
Nej, öppet eller inte, i princip alla är i alla fall beroende av att någon
annan tar något slags ansvar för den. Problemet med "öppen" programvara
är att det inte finns någon som man kan dra åt tummskruvarna
på när det blir problem.
Den främsta poängen med icke-öppen programvara är att man vet vem som
håller den vid liv och att någon tar ansvar för den.
> Med Open Office så kan du ta källkoden till valfri konsult och be dem snajda till en skräddarsydd version.
Det är är naturligstvis helt hypotetiskt och konstruerat.
Hur stort är OpenOffice ? Jag tror inte att det är något som man bara
"snajdar till" något av så där på en kafferast. Sannolikt skulle ingen
vilja ha resultatet av en sådan "snajdning".
Samma sak gäller med alla anndra populär programvaror, PHP, Apache,
MySQL, whatever. Av alla som använder dessa och liknande programvaror
är det oerhört få som har kunskap och resurser att göra något själv
med den.
> Vad har Microchip för anledning att inte tillhandahålla källkoden?
Det kan vara mycket. IP, så klart. Användning av andras skyddade koder.
Jag hoppas att MC inte tillhandahåller källkoden, så att jag vet
vem som tar ansvar för det och att jag vet att det finns en dokumentation
från samma källa som är korrekt o.s.v.
Jag ser det alltså som en garanti att MPLAB kommer att supportas och
utvecklas att det *INTE* släpps löst hur som helst...
Och allvarligt: att påstå att ett projekt man måste migrera från MPLAB till något annat är "mycket besvärligt"... då har man gjort något fel från början i mitt tycke.
Programfiler i asm till en viss processor ska kunna assembleras av "vilken som helst" assembler, det finns förvisso olika direktiver som skiljer mellan olika assembler men det är det ju mellan olika C-versioner också (fast inte i lika stor utsträckning).
Att källkoden till t.ex. MPLAB skulle vara fri för slutanvändare att "leka" med är INGEN garanti för fortsatt utveckling och stabilitet, största problemet med M$ är ju att de hemlighåller information om systemkall osv. i konkurrenssyfte. Och då de påstår sig göra ett OS skulle de i mitt tycke släppa all information hur man använder det men som yrkesman förstår jag dom, många av de program jag har gjort "i jobbet" har hemliga funktioner som man kan slå på om man vet hur...
Programfiler i asm till en viss processor ska kunna assembleras av "vilken som helst" assembler, det finns förvisso olika direktiver som skiljer mellan olika assembler men det är det ju mellan olika C-versioner också (fast inte i lika stor utsträckning).
Att källkoden till t.ex. MPLAB skulle vara fri för slutanvändare att "leka" med är INGEN garanti för fortsatt utveckling och stabilitet, största problemet med M$ är ju att de hemlighåller information om systemkall osv. i konkurrenssyfte. Och då de påstår sig göra ett OS skulle de i mitt tycke släppa all information hur man använder det men som yrkesman förstår jag dom, många av de program jag har gjort "i jobbet" har hemliga funktioner som man kan slå på om man vet hur...
SNAFU; Citat från slutet av KatB-se:
http://home.swipnet.se/swi/KatB-se.html
Dessutom förutsäger SNAFU-principen att i auktoritära organisationer bildas en gradvis avskärmning mellan beslutsfattare och verkligheten, eftersom mer och mer av input till beslutsfattare tenderar att bli behagliga lögner. Det sätt som detta verkar inom konventionell programmering är lätt att se. Det finns starka incitament för underordnade att gömma, ignorera och förminska problem. När denna process blir till produkt, blir programvaran en katastrof.
SNAFU principle:
http://catb.org/~esr/jargon/html/S/SNAFU-principle.html
http://home.swipnet.se/swi/KatB-se.html
Dessutom förutsäger SNAFU-principen att i auktoritära organisationer bildas en gradvis avskärmning mellan beslutsfattare och verkligheten, eftersom mer och mer av input till beslutsfattare tenderar att bli behagliga lögner. Det sätt som detta verkar inom konventionell programmering är lätt att se. Det finns starka incitament för underordnade att gömma, ignorera och förminska problem. När denna process blir till produkt, blir programvaran en katastrof.
SNAFU principle:
http://catb.org/~esr/jargon/html/S/SNAFU-principle.html
Tillgång till källkod innebär inte att support och utveckling från orginal producenten måste avstanna. Och det går att välja från vem man laddar ner sin version.
Med inlåst källkod frestas ofta organisationer att gömma och ignorera allvarliga fel i mjukvaran utan att det uppdagas i tid.
När företaget som producerar mjukvaran tappat verklighetskontakt så finns det möjlighet att gå vidare utan dessa med källkodstillgång.
Med inlåst källkod frestas ofta organisationer att gömma och ignorera allvarliga fel i mjukvaran utan att det uppdagas i tid.
När företaget som producerar mjukvaran tappat verklighetskontakt så finns det möjlighet att gå vidare utan dessa med källkodstillgång.
