[JAVA] Come funziona l'accesso all'hardware ?

[das]

Per capire meglio come funziona la JVM stavo cercando informazioni su come è virtualmente collegato l'hardware esterno alla macchina virtuale.
Purtroppo non trovo granchè, solo PDF da milioni di pagine senza esempi pratici.

In poche parole, se volessi inviare sulla seriale rs232 il carattere "A" programmando in bytecodes, come dovrei fare ?

Grazie


(nota a margine : come mai sono sparite dal forum tutte le discussioni ? Al momento vedo solamente 2 pagine :( )

[les2]

userai dei driver per lo scambio (il ponte è il SO),
poi in base a quello che devi fare possono essere nativi o meno.
(sono vago perchè non è il mio terreno)


poi nello specifico trovi sicuramente qualche libreria atta alla tua richiesta

[fano]

Io sto lavorando per fare cose analoghe in C#, ma Java dovrebbe essere simile per operare sulla seriale useresti sta classe: https://docs.oracle.com/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html

Ma cosa veramente accade quando fai Open() o Close()?

Quei metodi (o quelli da essi chiamati) saranno flaggati in qualche modo per indicare che sono nativi in C# sarebbero indicati come extern o FCALL / QCALL (intrisichi del compilatore) in Java questo dovrebbe chiamarsi JNI - Java Native Interface... e quando questo tipo di funzioni "native" il Jitter non farà altro che chiamare la corrispondente funzione della libc, quinid in caso di "Open()" farà qualcosa di simile a questo:


CommPort.Open() --> open(CommPort.Name, CommPort.Flags);

[das]

Diciamo così: normalmente per scrivere sulla porta COM1 scrivo all'indirizzo 0x3F8 il byte che voglio inviare.

Sulla macchina virtuale java mi pare di capire che le periferiche non sono accessibili come aree di memoria, o sbaglio ?

[fano]

Sì, ma appunto perché Java è Managed non scrivi direttamente sulla porta 0x3F8, ma appunto chiami le API C del sistema operativo sottostante che in caso di POSIX vorrebbe dire chiamare la open()!

Il flusso è più o meno questo (facciamo finta di essere su Linux... poveri noi :D):

1. CommPort.Open(PortName); // PortName dovrebbe essere un nome simbolico se ho capito bene...

2. Funzione C che converte PortName in un path in /dev facciamo finta che sia '/dev/ttyS0'
3. Funzione C open("/dev/ttyS0")
[Syscall al kernel]
4. Funzione di kernel che rimappa "/dev/ttyS0" nella porta hardware corrispondente
5. Funzione di kernel che "apre" la porta hardware (se "ti piace" fai finta che sia 0x3F8)
6. Il kernel ritorna OK che viene propagato al C e - infine - a Java
[/LIST]

Su Cosmos (che però è basato su C#) essendo esso stesso il SO ed essendo VIETATO il C i punti 2 e 3 non esisterebbero e sarebbe più vicino a quello che hai immaginato, ma anche Cosmos [B]non permetterà per ovvie questioni di sicurezza di manipolare direttamente a livello utente le porte IO della macchina.

[das]

Sì, ma appunto perché Java è Managed non scrivi direttamente sulla porta 0x3F8, ma appunto chiami le API C del sistema operativo sottostante che in caso di POSIX vorrebbe dire chiamare la open()!

Il flusso è più o meno questo (facciamo finta di essere su Linux... poveri noi :D):

1. CommPort.Open(PortName); // PortName dovrebbe essere un nome simbolico se ho capito bene...

2. Funzione C che converte PortName in un path in /dev facciamo finta che sia '/dev/ttyS0'
3. Funzione C open("/dev/ttyS0")
[Syscall al kernel]
4. Funzione di kernel che rimappa "/dev/ttyS0" nella porta hardware corrispondente
5. Funzione di kernel che "apre" la porta hardware (se "ti piace" fai finta che sia 0x3F8)
6. Il kernel ritorna OK che viene propagato al C e - infine - a Java
[/LIST]

Su Cosmos (che però è basato su C#) essendo esso stesso il SO ed essendo VIETATO il C i punti 2 e 3 non esisterebbero e sarebbe più vicino a quello che hai immaginato, ma anche Cosmos [B]non permetterà per ovvie questioni di sicurezza di manipolare direttamente a livello utente le porte IO della macchina.

Ok, chiaro.


Grazie,
Ciao

[fano]

Nei sistemi operativi moderni non è normalmente possible comunque "scrivere sulla porta 0x38" per scrivere sulla seriale sia perché, ma chi dice che siamo proprio 0x38? E poi perché compito del sistema operativo è anche nascondere questi dettagli di basso livello su Windows il sistema creerà un dispositivo virtuale COM0, mentre su Linux ci sarà "/dev/ttyS0" e anche con linguaggi di più basso livello come C/C++ andrai comunque a scrivere / leggere da quei pseudo-device...