ARGOMENTO:

stò cercando (inutilmente ) una motherboard o meglio una schedina embedded, tipo quelle dei vecchi cellulari, ma che sia in grado far girare l'MS-DOS (quindi mi basta un (1) mega di RAM) e abbia una porta parallela e una seriale

si lo so potrei usare un vecch(issimo) PC, ma per risparmiare sui consumi ( visto che starebbe acceso parecchie ore e ... senza poter scaccolare! ), sono alla ricerca di un robo x86 da 30 a 200MHz con consumi ( meno di 0,5 watt ? ) e dimensioni ridotte

ah già, le soluzioni ARM in emulazione, tipo raspberry non vanno bene perchè deve essere full real time

avete qualche link please ?

astroale ha scritto:

sono alla ricerca di un robo x86 da 30 a 200MHz con consumi ( meno di 0,5 watt ? ) e dimensioni ridotte

Con potenze così basse, non ricordo nulla.
Ho trovato questo:
CPU-1440 PC/104+ Module with DOS and true ISA compatibility
Arrivano a 4W e sono anche italiani.
Ma con aggeggi così "estremi" non aumenti i costi?

Una piattaforma x86 con consumo inferiore a 0,5W non so se esista, un alimentatore (ATX) a vuoto consuma da solo anche 4-5W (quanto un Raspberry Pi)
Non so se esistano soluzioni industriali che consumino così poco (li ha più importanza l'affidabilità credo), sul nuovo puoi dare un occhio alle mobo con Intel Celeron j1800 o j1900, un po' esagerate come potenza rispetto a quanto richiesto (sarebbero ottime per BOINC secondo me).
Altrimenti, se vuoi spendere un po' meno a fronte di consumi leggermente maggiori, dovresti cercare qualche Thin Client x86 dotato delle connessioni da te richieste e su cui si possa far girare un altro sistema operativo.
(Se ti interessasse io avrei un Thin Client Lex Light System CV860A con VIA Eden ESP 5000 (533Mhz) + 256MB RAM, usabile anche fanless, dotato di connettore CF, IDE 40 pin e IDE 44 pin, 3 porte LAN 100Mbps, 2 porte seriali e 1 parallela, con alimentatore 12V e volendo un HD IDE 44pin 20GB con cavo flat: link manuale , altro link )

Edit: sono troppo lento a rispondere

grazie, ma forse ho trovato qualcosa di interessante, anche se ... niente porta parallela ... però potrei emularne le uscite con i numerosi I/O pins ... mumble

Intel Galileo Gen2

astroale ha scritto:

grazie, ma forse ho trovato qualcosa di interessante, anche se ... niente porta parallela ... però potrei emularne le uscite con i numerosi I/O pins ... mumble

Intel Galileo Gen2

Secondo me la tua richiesta avrebbe più senso se spiegassi chiaramente la funzione per cui ti serve. Se il progetto è semplice, impelagarsi sulla deprecata piattaforma DOS potrebbe rivelarsi solo uno spreco di tempo (tra l'altro l'x86 è stato abbandonato da tempo, nell'automazione industriale). Visto che parli di real time, immagino tu abbia a che fare con qualcosa di non eccessivamente complesso scritto in assembly. Siccome ho già avuto a che fare con problemi simili (vecchi driver per altrettanto vecchie macchine), se entrassi più nello specifico potrei darti un parere preciso.

Eden_H ha scritto:

astroale ha scritto:

grazie, ma forse ho trovato qualcosa di interessante, anche se ... niente porta parallela ... però potrei emularne le uscite con i numerosi I/O pins ... mumble

Intel Galileo Gen2

Secondo me la tua richiesta avrebbe più senso se spiegassi chiaramente la funzione per cui ti serve. Se il progetto è semplice, impelagarsi sulla deprecata piattaforma DOS potrebbe rivelarsi solo uno spreco di tempo (tra l'altro l'x86 è stato abbandonato da tempo, nell'automazione industriale). Visto che parli di real time, immagino tu abbia a che fare con qualcosa di non eccessivamente complesso scritto in assembly. Siccome ho già avuto a che fare con problemi simili (vecchi driver per altrettanto vecchie macchine), se entrassi più nello specifico potrei darti un parere preciso.

TI ringrazio, in realtà si tratta di rimettere su il vecchio e famoso (tra gli astrofili autocostruttori) scope.exe per MS-DOS di Mel Bartels, un programma di puntamento automatico per telescopi (in genere autocostruiti) che nella sua release anni '90 usa gli 8 pin dati della porta parallela per pilotare le 4 fasi di due motori passo-passo, il tutto grazie al real-time dell'MS-DOS. Qui trovi la pagina del progetto con i motori stepper e qui i sorgenti per MS-DOS (credo sia stato sviluppato col Turbo C della Borland o con il Borland C++, anche se contengono solo codice C).
Lo so nel frattempo Mel ha creato prodotti commerciali più evoluti ma dato che avevo assemblato un telescopio con tutto il sistema descritto (inoltre ho conservato tutti i pezzi per replicare l'operazione enne volte su altrettanti telescopi), ho quindi intenzione di renderlo nuovamente operativo in postazione fissa, volevo evitare di attaccarlo ad un vecchio (e quindi poco affidabile PC), ma provare ad usare HW più recente e dal minor consumo, da qui la ricerca di una scheda x86 MS-DOS compatibile ... per ora mi sono orientato più ad un porting del codice verso debian -> raspbian e provare ad usare le uscite della GPIO del raspberry al posto della parallela ... sarà un parto difficile perchè sono 25-30mila linee di codice e anche al buio perchè non ho mai provato come fungono le varie patch real time per raspbian.

Quindi ora il problema si è spostato sulla ricerca di un compilatore o di librerie che consentano di velocizzare il lavoro di porting ... mi ero illuso che Lazarus, l'ultimo erede open del vecchio Borland, fosse in grado di compilare il C, ma sembra di no ...

EDIT
ultima pista che stò seguendo ... Porting Borland Turbo C source code to GNU gcc

Lazarus è un IDE Pascal, sostituisce Borland Delphi e non il C++. Ho dato una lettura veloce al sorgente, che per dirla come va detta fa parecchio schifo, essendo disorganizzato e mal documentato (tipico, in quegli anni).
Un porting, in questo caso è un lavoro a dir poco colossale, è più sensato parlare di riscrittura completa del programma (DOS non prevedeva nulla di simile allo user space di linux), cosa comunque improbabile poiché l'autore non ha avuto premura di fornire la documentazione sull'algoritmo e dedurla dal programma in C sarebbe semplice più o meno come tradurre da zero la stele di Rosetta.
L'unica risposta possibile è virtualizzare. Per quanto le chiamate all'hardware passino attraverso il kernel, la velocità dei processori ARM odierni farà sì che gli interrupt arrivino perfettamente sincronizzati. Il problema principale risiederà nell'impostare la porta parallela sulla scheda ARM e far sì che la macchina virtuale comunichi con essa, cosa per cui da che so non esistono strumenti specifici. Bisognerà crearli.
Per iniziare, si potrebbe virtualizzare dos in una debian, per esempio con Dosbox o Qemu (all'interno del quale girerà il programma scope.exe), dopodiché lo si costringerà a stampare l'output seriale e parallelo quali valori di argomenti di funzioni (qui bisogna vedere la documentazione dell'emulatore, ma immagino sia una cosa facilmente fattibile) in specifiche locazioni temporanee che bisognerà impostare. Infine, si dovrebbe realizzare un software nativo (un piccolo script, per esempio in python) che accetti in ingresso i suddetti argomenti e provveda a pilotare di conseguenza l'hardware ARM.
Mi rendo conto, è cervellotico, ma sempre meglio che riscrivere quel guazzabuglio di sorgente da capo... Sarà ugualmente una cosa lunga.

Alcuni link (sperando che ti siano d'aiuto):
superuser.com/questions/96812/using-a-printer-in-dosbox
www.raspberrypi.org/forums/viewtopic.php?f=78&t=36695
www.raspberrypi.org/forums/viewtopic.php?f=66&t=80233
www.raspberrypi.org/forums/viewtopic.php?f=63&t=38949


Un modo più veloce e comodo comprenderebbe un piccolo portatile (come i netbook, a patto che supporti le estensioni di virtualizzazione) a cui andranno collegati i relativi cavi adattatori usb/seriale e usb/parallela. Poi, con freedos su virtualbox o vmware si andrebbe a pilotare l'hardware direttamente usando il programma originale senza eccessivi sbattimenti. Con la batteria del portatile (magari di quelle a 6 celle) avresti comunque numerose ore di osservazione, direi più o meno fino a far venire l'alba. O no?
forums.virtualbox.org/viewtopic.php?f=4&t=59663
Se ancora i problemi dovessero risultare insormontabili (a causa degli adattatori usb) si potrebbe sempre provare con un notebook (comunque recente) con porte LPT e COM fisiche.

astroale ha scritto:

per ora mi sono orientato più ad un porting del codice verso debian -> raspbian e provare ad usare le uscite della GPIO del raspberry al posto della parallela ...

Ciao a tutti,
qua c'è un video che da alcune preziose info.

youtube.com/watch?v=vw2nTpLFof8
Spero vi sia d'aiuto.

__________________
Servizi di automazioni elettriche ed elettroniche > orlandiniautomazioni.com