Van itt aki elgondolkodott már azon, hogy a Microchip hány mikrovezérlőt adhat el éves szinten szerte a világban mindenütt? Létezhet bármi forrás, akár csak hozzávetőleges jelleggel, ahol ilyesmi adat publikusan előfordulhat? Bármilyen tippnek örülnék a kérdésben.

Szerintem elég OFF ez ide,de miért is annyira fontos ez neked ha meg szabad kérdezni?

A darabszámot soha nem fogják elárulni, mert az üzleti titok. Viszont kötelesek pénzügyi jelentést közzétenni: ITT.

A 35. oldal környékén látszik, hogy 2015-ben 1,393 milliárd USD értékben adtak el mikrovezérlőket. A 37. oldalon még a földrész szerinti bontást is meg lehet nézni. Ebből már lehet tippelni. Az sincs kizárva, hogy valamelyik prezentációban akadnak részletesebb adatok is, de azok kibogarászása rád vár.

A linkelt doksiban én a vezetők fizetéseit találtam meg, amihez jó lenne tudni, hogy a teljes értékesítés alapján mekkora % prémiumot kapnak. Van arra valami irányérték, ami sacc per kb stimmelni tud? Ebben tuti sokkal jobban képben vagy, mint én

Kértek tőlem pár adatot egy üzleti tervhez - nem tudom, mihez - és környezeti felmérésként abban jó lenne olyat is megemlíteni, hogy mekkora piaca van a pic mikrovezérlőknek. Irányadó értékek elegendőek, épp csak ne legyen teljesen dimenziójában is eltévedett bullshit.

Füvesi Viktor 2008-as írásában szerepel, hogy "120 millió eladás évente".
Bővebben: Link
Bővebben: Link

6 éve PIC-ez(get)ek, de még mindig nem vagyok kibékülve a bankolással. Egyszerűen nem akarom elfogadni azt, hogy az embernek kell foglalkoznia ezzel (persze asm-nél). Vagy az MPLABX-nél már van erre megoldás?
Nem értem, miért nem csinálták már meg azt hogy beszúrjon egy bankváltást a fordító, amikor kell.
Ha már figyeli a fordító, hogy az adott regiszter nem a 0. bankban van, akkor nem tartott volna semmibe, hogy megcsinálják..

A másik 35. oldal. (A pdf-ben 83. Több doksiból áll, ahogy látom. Nem figyeltem az előbb.)
Közel másfél milliárd bevétel az legalább ötszázmilliós darabszámot jelenthet. Erre utal az is, hogy évi 18-20%-ot emelkedik a termelés. Ha 2008-ban 120 millió volt, akkor mostanra vidáman elérhették az 500-at. Mivel manapság minden világító keljfeljancsiban van egy pic, ez nem is nagyon hihetetlen szám. Könnyen lehet, hogy 1-200-al alábecsülöm.
Ezt a grafikont érdemes megnézni: Bővebben: Link

Jól ki is szúrna az olyan utasításokkal mint a btfss, btfsc, stb.
Miért nem lehet megbarátkozni a Bank -olással?.? De ha ennyire fáj, miért nem választasz másik kontroller családot???

Honnan tudja szerinted, hogy mikor kell: honnan ugrottál oda, milyen bankban voltál az ugrás előtt ?! A programot nem érti a fordítóprogram, "csak" szintaktikai hibákat keres és fordít !

Mindegy, zárjuk a témát.

Én sem szeretem azt ha egy eszköz lekorlátoz engem, meg plusz feladatokat ad, ezért én 8-bitesekkel nem foglalkozok, még az egyszerűbb feladatokhoz is PIC24-et használok. Sokkal kényelmesebb és hatékonyabb rajta az Assembly nyelvű programozás, mint bármelyik 8-bites PIC-en.

Pedig azokban is akad egy lis lapozás: 24FJxxxDAyyy EDS.

Én meg azt nem értem, miért nem használtok C-t, ha már nem akartok bankolni. Egy bizonyos szint után az asm önkínzás(pl. USB, TCPIP, stb.). Sokáig én is asm párti voltam, de most csak azért volt jó abban kezdeni, mert megértem, ha valamit nem jól csinál a C. Nem állítom, hogy könnyű váltani, de megéri.

Már korábban is elmondtam hogy én pl. azért szeretem az Assemblyt, mert pontosan azt és úgy csinál, amit és ahogy én akarok. Majd ha rá leszek kényszerülve, akkor használom a C-t. (az Assembly mellett)
Egyébként én MicroBasic-kel kezdtem, de hamar váltottam, mivel egyre több sebességkritikus rutint (assembly betétet) kellett használnom, ill. a fejlesztőkörnyezet eléggé megbízhatatlan volt.

Hp41C:
Ebben igazad van. (Bár én még nem használtam EDS-t.)

Köszönöm, megfelelnek.

Jam, azóta rájöttem, hogy de buta vagyok, mert még a wiki oldalra sem néztem rá (fentebb arról kaptam linket Wezuv-tól). Ott is írják a 2014-es eredményt, 1.9 bil usd, amit ha 8 usd-vel osztok is be, még mindig 240 mil+ eszköz darab, meg pláne, a 8 usd vígan egy átlag fölötti szám, akár dupla annyit is eladhatnak.

Az a doksi szuper! Örök hálám érte, azt a cuccot tuti imádni fogják

Assembly / C ...
Én az azonnali gépi kód íratásnál üres opcode ot is tudok használni saját célra
csak binben ránézek és látom hol mit miért jelzek magamnak
(pld cimkét sorszámozva)
és e technikával bele lehet csempészni függvények utáni leíró magyarázatot
illetve függvények előtt a függvény nevét szövegesen
a lényeg, hogy ide ne ugorjon a vezérlés
és ha tényeg nem kell törekedni a program mérettel.

Ha a programunk teljesen kész
az egész forrást jelszavasan tömörítve is becsempészhetjük
így ha elvész a forrás anyag a Hex ből visszanyerhető majd később is
ha még hozzá kellene írni.

A jelenlegi programozástechnikai problémám:
18F26K22 nél UART1 és UART2 bitre azonos beállításra állítottam be
és az UART1 Received tökéletesen fogad de az Uart2 ről nem tudok fogadni.
A PK2 t le kell csatlakoztatnom a jelszintek miatt.
Az uart1 nél ha ütemesen testelgetem az RC7 et sorra jönnek a 0x00 ák.
De UART2 nél süket. Mit lehet itt még másképp állítani ? pullup van rajta,
PIR1_bit5 öt figylem uart1 nél és PIR3_bit5 uart2 nél.
TXd uart2 nél jó
Kössz

Rengeteget programoztam már C-ben is, az is azt csinálja, csak sokkal gyorsabban lehet haladni. De nem akarok rád erőltetni semmit...

Erre a problémára még mindig nincs ötlet C -ben...

Lehet haladni, csak győzni kell programtárral... Bővebben: Link
Addig, amíg a fejlesztendő program csak a töredékét (maximum a felét) használja a memóriának gyorsan megy a fejlesztés, ha már 80% felett vagy jön a kínszenvedés...

Én ezeket a makrókat csináltam XC8-ban az adat EEPROM-hoz, mert a 8 bájtos verzió nekem sem tetszett:

A használata pedig a következő volt:

Sajnos az EEPROM-beli címeket nem sikerült sehogy sem kinyernem belőle.

Watchdog?

Nem az a problámám, hogy konstans (értsd a makrónak számmal beírt) címre nem tudok tetszőleges mennyiségű adatot letárolni.
A feladat az, hogy egy (vagy többféle) konstans (*.h -ban definiált) adatból kellene kiszámolni az adat címét. Ld. assembly forrásrészlet, ahol az org szimbólumokkal számítja a címet.

Azt írtad korábban, hogy a sorrendet összekeverte, ha több sorba ítad az adatokat. Ezek szerint a fordító önkényesen pakolja le a kezdő címet, ahogy van helye, vagy jónak gondolja. Egy megoldás lehet, amit fel is vetettél, hogy egy sorba írod az összes egymáshoz tartozó adatot.

Általánosítsunk:
Szeretnék egy parancsdekódoló táblázatot csinálni. A parancs kódja konfigurációfüggő, a konfigurációkat egy forrásból szeretném fordítani. Minden konfigurációhoz létrehoznék egy-egy .h állományt, amiben megadom a parancsok kódjait. A parancsok ugyan annyian vannak, ugyan azok a funkciójuk, de egyediek a kódok.
Kijelölök egy területet (esetemben ez pont az adat EEProm) és ott létrehozok egy táblázatot. A táblázat a parancskódokat tartalmazza a parancsok belső kódolásának sorrendjében. Ha egy parancs nem használatos egy egyedi kódú bejegyzést kap (0xFF).
Annak a módját keresem, hogy C nyelven fel tudjam tölteni a táblázatot.
Pl. Legyen a táblázat 16 elemű, de csak 3 parancs legyen végrehajtható. Ekkor a táblázat minden eleme - kivéve azt a hármat, aminak a címét a .h állományban megadtam - 0xFF -nek kell lennie, a három parancsnál pedig a 0x00, 0x01, 0x02 kódok legyenek. Azt, hogy melyik táblázatelem legyen a kódokkal feltöltve, a .h állomány cseréjével lehessen változtatni.

Eddig nem találtam megoldást csm XC8 -ban, sem C18 -ban.

Hello Nekem egy PIC18F2550 re kéne feldobni egy programot Ki lenne olyan kedves, hogy tudna benne segíteni ? Vas megye és környéke ?

Első körben próbálom megérteni a feladatot.
Tehát, ha jól értem, egy h-ban(egyébként mindegynek tűnik, hogy h-ban, vagy a c-ben), létrehozol egy táblázatot EEPROM területen. A táblázat elemei parancskódokat fognak tartalmazni. Egyes parancsokhoz tartozik egy cím, mondjuk 0-tól egyesével. A kiolvasás rutin címkiosztása mindig azonos, de a címen található parancskód a táblázat tartalmától függ. Gondolom ezt az EEPROM területet menet közben is felül szeretnéd írni a feladathoz tartozó parancsokkal? Vagy csak fordításkor a h-ban deklaráltak szerinti kódelosztást szeretnéd megvalósítani?

Nem biztos, hogy ertem a problemadat, de a C (gcc) ezt megengedi:Ebben az esetben a tomb minden eleme 0 lesz, kiveve azt a kettot, amit inicializaltunk.

Még konkrétebban:
A programban belső parancskódokat használok: 0x00, 0x01 stb. A kapott parancskód más kódolású (pl. egy valahonnan származó infra távirányító), amiből többféle is lehet, természetesen eltérő kódokkal.
Ha a program vett egy infra távirányító parancsot, megkeresi a táblázatban és a megtalálás címét tekinti belső parancskódnak.
Természetesen átírható, ezért került az EEProm -ba. Egyébként egy konkrét típusra az "ömlesztett" módszerrel megadom és az átírással testre szabom.

Ez csak egy olyan "gumicsont", amit nem tudok megoldani PIC C -ben, de assembly -ben (abszolut kódban) 10 másodperc....

Köszönöm....
Lehet, hogy más fordítóval meg lehet oldani, de az XC8 illetve a C18 lehetőségein belül lenne igazán érdekes.