[C] porting e gestione carattere \0

[cdimauro]

64KB di RAM? Magari!

Certi microcontroller hanno a malapena 2,5KB di RAM a disposizione, e 32KB di flash per il codice: puoi immaginare i salti mortali necessari per farci stare tutto lì.

Per cui concordo con !fazz. E aggiungo che certe restrizioni che normalmente impongono i s.o. non mi vanno a genio, perché compromettono la creatività del programmatore, e la capacità di risolvere in maniera semplice ed elegante alcune problematiche.

P.S. In ambito embedded non è comune avere a disposizione un'MMU. Per lo meno una PMMU.

[fano]

Il sistema più "sfigato" su cui ho dovuto lavorare era VxWorks con CPU Motorola 68'000 e 32 MB di RAM! Praticamente un Amiga, ma molto meno divertente

[cdimauro]

Il mio Amiga 2000 aveva un 68000 (a 7Mhz) e 1MB di RAM: praticamente il tuo VxWork era un mostro di sistema.

Ma 32MB francamente non mi tornano, visto che il 68000 aveva 16MB di spazio d'indirizzamento totale (estendibile a 64MB utilizzando i famigerati function code. Fattibile, ma solo sulla carta, visto che il 68000 non aveva istruzioni di spostamento dati fra diversi spazi d'indirizzamento coi function code: serviva almeno un 68010 allo scopo).

Quindi immagino che tu abbia avuto almeno un 68020 per gestire tutta quella memoria (ci sarebbe anche il 68012, che è un 68010 con supporto a 1GB di address space, ma è molto raro e ha avuto poca fortuna), che era tutt'altra cosa.

Comunque credimi: ci sono SoC embedded talmente limitati con le risorse (ma nonostante tutto molto diffusi) che un sistema come il tuo sembra fantascienza.

[fano]

Originariamente inviato da cdimauro

Il mio Amiga 2000 aveva un 68000 (a 7Mhz) e 1MB di RAM: praticamente il tuo VxWork era un mostro di sistema.

Ma 32MB francamente non mi tornano, visto che il 68000 aveva 16MB di spazio d'indirizzamento totale (estendibile a 64MB utilizzando i famigerati function code. Fattibile, ma solo sulla carta, visto che il 68000 non aveva istruzioni di spostamento dati fra diversi spazi d'indirizzamento coi function code: serviva almeno un 68010 allo scopo).

Quindi immagino che tu abbia avuto almeno un 68020 per gestire tutta quella memoria (ci sarebbe anche il 68012, che è un 68010 con supporto a 1GB di address space, ma è molto raro e ha avuto poca fortuna), che era tutt'altra cosa.

Non ricordo di preciso quale 68K fosse, ma ricordo che all'inizio avevano 16 MB, ma poi dovettero portarli a 32 MB non so quale "trusco" usarono per farlo... era una versione di VxWorks "pasticciata" visto che il cliente ce l'aveva così mastodontico che aveva pure i sorgenti del kernel / libc... alcuni driver se li avevano scritti loro con risultati beh ridicoli
(Tipo che la seriale era più veloce della rete!)

Originariamente inviato da cdimauro

Comunque credimi: ci sono SoC embedded talmente limitati con le risorse (ma nonostante tutto molto diffusi) che un sistema come il tuo sembra fantascienza.

Sì noi chiamiamo "embedded" cose che non lo sono propriamente... comunque talvolta è imbarazzante e poco giustificabile vedere praticamente lo stesso software arrancare su un Atom con 1 GB di RAM... c'è qualcosa di sbagliato non so in X86 o in Linux ma è indubbiamente più pesante il tutto

[!fazz]

Originariamente inviato da cdimauro

64KB di RAM? Magari!

Certi microcontroller hanno a malapena 2,5KB di RAM a disposizione, e 32KB di flash per il codice: puoi immaginare i salti mortali necessari per farci stare tutto lì.

Per cui concordo con !fazz. E aggiungo che certe restrizioni che normalmente impongono i s.o. non mi vanno a genio, perché compromettono la creatività del programmatore, e la capacità di risolvere in maniera semplice ed elegante alcune problematiche.

P.S. In ambito embedded non è comune avere a disposizione un'MMU. Per lo meno una PMMU.

ho per le mani ancora qualcosa di più assurdo, giusto oggi sto mettendo le mani su un progetto basato su un PIC12LF1552 con 2048 word di flash e ben 256 byte di ram vi lascio immaginare i numeri da circo xd

[cdimauro]

Originariamente inviato da fano

Non ricordo di preciso quale 68K fosse, ma ricordo che all'inizio avevano 16 MB, ma poi dovettero portarli a 32 MB non so quale "trusco" usarono per farlo... era una versione di VxWorks "pasticciata" visto che il cliente ce l'aveva così mastodontico che aveva pure i sorgenti del kernel / libc... alcuni driver se li avevano scritti loro con risultati beh ridicoli
(Tipo che la seriale era più veloce della rete!)

Sono ragionevolmente sicuro che si trattasse di almeno un 68020. E ti assicuro: è tanta roba. Così comodo, che potrei svilupparci in assembly anche dei progetti anche di una certa dimensione. Nulla a che vedere con schifezze come PIC et similia: l'assembly 680x0 rimane "da urlo" ancora oggi.

Sì noi chiamiamo "embedded" cose che non lo sono propriamente... comunque talvolta è imbarazzante e poco giustificabile vedere praticamente lo stesso software arrancare su un Atom con 1 GB di RAM... c'è qualcosa di sbagliato non so in X86 o in Linux ma è indubbiamente più pesante il tutto

Non credo sia x86 il problema. x86, specialmente in versione 16 bit, è una delle ISA più compatte nonché parca di risorse. Ma anche la versione a 32 bit (80386+) produce codice con una buona densità.

Il problema è... quello che ci devi fare. Ovviamente più il software da sviluppare è complesso, e più risorse richiederà.

Originariamente inviato da !fazz

ho per le mani ancora qualcosa di più assurdo, giusto oggi sto mettendo le mani su un progetto basato su un PIC12LF1552 con 2048 word di flash e ben 256 byte di ram vi lascio immaginare i numeri da circo xd

Ma LOL Perfino il Commodore Vic 20 era messo meglio.

In tutta onestà non t'invidio. Con quelle poche risorse molto probabilmente sarai costretto a scrivere codice in assembly. E l'assembly dei PIC è a dir poco rivoltante. Talmente rivoltante che una ventina d'anni fa mi scrissi un assembler di più alto livello, pur di non usare quello standard di Microchip.

Fosse per me, 68020+ tutta la vita. Seconda scelta: 80386.

[!fazz]

per me una delle microarchietture migliori, una volta capita, è la cortex m4 e la cosa assurda è che è stata rifiutata in quel progetto perchè il micro era troppo costoso (si parla di circa 3€ di differenza su una macchina da minimo 20k€ )

l'm4 ma in generale quasi tutte le archiettture arm based hanno una flessibilità in termini di periferiche e piedinature che semplificano il routing in maniera imbarazzante

[cdimauro]

Originariamente inviato da !fazz

per me una delle microarchietture migliori, una volta capita, è la cortex m4 e la cosa assurda è che è stata rifiutata in quel progetto perchè il micro era troppo costoso (si parla di circa 3€ di differenza su una macchina da minimo 20k€ )

Dipende quanti pezzi ne vendono di quelle macchine.

Fino all'ordine di qualche centinaio ha senso poter usare un microcontroller migliore come l'M4, vista la differenza irrisoria e considerato che potrebbe richiedere meno tempo di sviluppo al programmatore.

Ma già arrivando all'ordine delle migliaia la differenza si fa sensibile, e puoi arrivarci a coprire il costo di un dipendente.

Ricominciando a lavorare un po' in area embedded si capisce il perché si facciano delle scelte che a noi sviluppatori sembrano insensate.
Ad esempio l'adozione di economiche memorie eMMC anziché SSD capaci di maggiori cicli di scrittura nella centralina delle automobili: all'azienda è più conveniente pagare uno sviluppatore per un anno intero a ottimizzare le scritture su eMMC, anziché spendere qualche euro in più per un miglior SSD. Anche un solo euro per 3 milioni di auto l'anno fanno 3 milioni euro (l'anno, appunto), mentre lo sviluppatore costa più di un ordine di grandezza di meno e per un solo anno.

Quindi niente: chi lavora nell'embedded è destinato a soffrire, usando poche risorse da rivoltare come un calzino.

l'm4 ma in generale quasi tutte le archiettture arm based hanno una flessibilità in termini di periferiche e piedinature che semplificano il routing in maniera imbarazzante

Infatti da questo punto di vista non ho nulla da dire. D'altra parte è proprio il dominio di ARM.

Prima riguardo a 68K e 386 parlavo esclusivamente come programmatore: mi trovo più a mio agio a scrivere codice assembly con queste architetture, che con ARM (Thumb 2 nel caso dell'M4).

Originariamente inviato da Antonio23

Armv7-M, l'M4 e' il nome del micro.

[!fazz]

l'ordine è delle migliaia di macchine (non è di certo al livello dei numeri dell'automotive ) il settore è lo stesso ma dall'altra parte della sponda sono macchine da utilizzare nelle linee di assemblaggio di cui un 20% con software customizzato ergo .....

@Antonio23 se proprio vogliamo fare i pignoli arm7E-M è il nome dell'architettura , cortex M4 è il nome del core mentre il nome del micro ERA STM32F4[qualcosa]