Related
There is a lot of talk about Java serial port libraries like RXTX and JSSC, but what do they really provide? In both linux and windows you can simply open the serial port like a file for reading and writing, can't you? What is the advantage of using the libraries over just reading and writing from the device with file IO?
I understand that the libraries allow you to configure the ports, which would normally need to be done by commandline calls. But assuming the ports are already configured, is there any reason to use the libraries?
In both linux and windows you can simply open the serial port like a file for reading and writing, can't you?
While this is possible to do, it's not really a recommended way to do it. To go to your second point:
But assuming the ports are already configured, is there any reason to use the libraries?
Assuming the ports are configured and configured properly, then it's perfectly possible to simply open up the serial port and read and write it like a normal file. This does come with another caveat though: that if you depend on the control signals at all, you won't be able to get that data from the port. Most serial devices that I have worked with don't do anything with the control lines at all, but that's not something that you can always be sure of.
The point behind using a library is so that you can get and set the exact settings that you need to in order to talk appropriately over the port.
As for JSSC/RXTX not having an InputStream/OutputStream for them, I didn't like that about those libraries either, so I wrote my own.
Serial ports, historically, have been designed for slow communication lines such as modems. They have additional signals for "clear to send", "request to send", "data terminal ready", "hang up", "ring", etc. Some serial equipment still uses those. That stuff still exists in hardware, so a serial library should provide an API to access it.
Another thing are the interrupts. You might not want to poll the connection all the time to see if there is data available. Serial APIs usually provide a callback or an event handler for that.
Opening and closing port is best done in-application. Strictly speaking, it's not neccessary, but it's good practice not to expect a particular port being open at start or leave it locked on exit.
Following is a quick list of why we may consider a library but largely I feel that if we are making a commercial product than ready made libraries may be good choice otherwise as a learner we can write our own.
Uniformity across various operating systems. We have to write code for all supported OS which is a task in itself.
The library authors may have more experience in that particular topic so quality might be better than us.
Time to finish project (time to market) is another factor.
Comprehensive test suite
Beyond simple read/write can be extra features especially in case of GUI driven products like hot plugging and visual indications etc.
Library might implement protocols or specifications means simple read/write may come wrapped in stream where the serial port specific things are hidden and a uniform layer is exposed to app.
Support for wider range of hardware devices esp USB-UART
Take a look at these 2 open source libraries 1st library and 2nd library
Support for both Embedded and Desktop OS
I'm attempting to write a desktop application that connects to bluetooth smart / BLE devices, for example, Polar Heart monitor.
Is there a generally recognised way to do this, Java API or library?
This is for a desktop application not android. Everything I see online is year(s) out of date or specifically android. I would rather try to avoid writing some platform specific JNI shenanigans.
Thanks.
I've used NRJSerial in a desktop application (Linux based) with Java. It has native in it but I didn't have to deal with that directly. There are ways to read from the USB/Serial port in Java but I found this to be portable and easy.
A word of warning though - it's low level. I was dealing with a PulseOximeter that just dumped binary so it wasn't too bad. If you start to get into GATT and so on it will be a decent amount of work to handle that.
If you plan on using a linux based system you can use bluez5.
Bluez5 exposes interfaces in the DBus thus interaction with bluez can be done with the dbus bindings of your choice(C, python, C#Mono.. ). Using the dbus-api you'll be able to scan, connect, pair, notify, read/write, advertise and much more
You can find a description of the dbus api exposed by bluez here (I suggest looking at the adapter-api, device-api and gatt-api) : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc
Before diving into the code you can play around with bluetoothctl (a tool that you can use for pairing, connecting, services discovery, gatt attributes reading & writing etc).
Also, you can find the source code of bluetoothctl here : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/client/main.c
bluetoothctl was built using GLib GDBus (dbus bindings for Glib in C) and you will find code examples for pretty much everything you'd like to do with bluez.
I have a microcontroller that when an event, I want it to send an email. I know how to use email in Java, but how can I put that Java code in the midst of the C code of the microcontroller?
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRB |= 1 << PINB0; // = 0b00000001
DDRB &= ~(1 << PINB1);
PORTB |= 1 << PINB1;
DDRB |= 1 << PINB2;
while(1)
{
PORTB ^= 1 << PINB0;
if(bit_is_clear(PINB, 1)){
PORTB &= ~(1 << PINB2);
_delay_ms(100); //SLOW
}
else{
_delay_ms(10); //FAST
/////I want the Java code in here/////
PORTB ^= 1 << PINB2;
}
}
}
EDIT
I'm using an Atmel Atmega8A microcontroller. I'm making a simple alarm system, that if the wire at pin B1 is disconnected, I want to get an email or text notification.
And I'm just a high schooler novice so please don't go over my head too much...
Oh and if someone could water down multithreading in C for me that would be nice. I come from a Java background since that's what they teach in high school.
Well your "question" is to embed Java to your AVR... but what you actually want to is send email. There are some implementations to run Java bytecode (or at least I think so), but I believe none of these will be able to send email.
You need to understand that an AVR is very limited in functionality. To send email, your setup will need to connect to the Internet, with TCP/IP. Something so complicated that cannot be accomplished with the ATmega8A itself. It may be possible to find a hardware which you can communicate via UART in order to send email, or you can simply hook it to a PC and run a application to listen to the COM port and send email, or... anyway you need extra hardware.
You may want to look into other microcontrollers instead. I believe there are some with networking support, but they will probably be very expensive. Or, you can just use a Raspberry Pi instead.
Java and C are very, very different langauges.
You'll need to find a compiler for your microcontroller that supports Java.
However, if your controller can get C compiled via GCC, then use of GCJ may work with certain memory constraints on the target platform. You'll need to generate an object file of the correct architecture, and link it using microcontroller-compatible gcc.
This is not worth its time. I recommend implementing it in C instead.
Besides, opening files and sockets may not occur since a microcontroller usually does not provide any kernel routines beyond certain aspects of hardware access. libc will also likely be absent or minimal.
You might also not have networking hardware. If you can tell us which microcontroller, we could help.
A more direct answer to the question was given already by Alvin Wong, but I feel your question is so out of focus that it might be good to help you refocus it.
You should start understanding what is really happening when you send a mail from a Java program, then understand what part of it can actually be done by your microcontroller, and how.
So, what happens when you run your mail-sending Java program?
You wrote the program in the Java language, which got compiled into Java bytecode, which gets interpreted by the Java Virtual Machine, which will call some library provided by the Java runtime,
which will (probably indirectly) start a "network communication", which will take advantage of the Operating System network facilities, ...
which will use the network hardware,
to communicate with a mail server using some mail protocol, and send it some specific sequence of bytes that will make it understand that a mail message is being sent to someone.
The (1) part is mediated by all the layers of the Java platform. (Remember: Java is much more than a language).
The (2) is a layer (or couple of them) under the Java platform, and includes all of your Operative System (Windows, Linux, Mac OS X, whatever).
The (3) is a layer comprised of your hardware, and that includes other sublayers like the firmware in your network card, which is still more software that might manage things like the Ethernet / Wifi protocols' details.
The (4) layer is rather bits and bytes being flipped on and off in some communication channel (Ethernet, WiFi, whatever).
Now, what part of it can be done with your microcontroller?
A microcontroller sits in the lower part of (3). In your case, the Atmega doesn't even have any network hardware support, so ... I don't know how you are planning to connect to the network. Anyway, even if you had it, you are so close to (4) that it would rather be madness to try to go up to (1). (1) is say for elephants, (4) can be done by ants, and a microcontroller is about the size of a ladybug, to refer to Atmel's mascot :P.
So: stop thinking like an elephant. As it is you will have to work to get to your goal, but if you take the elephant's way, you'll be probably doing a ton of unneeded work - if it can be done at all, which I doubt.
(And if anyway I had to take the elephant's way, namely use Java in an AVR, I would start by looking at GCJ or LLVM options. I know that some work was done to port minimalist JVMs to 8 bit microcontrollers more than a decade ago, but no idea how that evolved)
Like others said, sending an e-mail this way is really really far from your micro (I assume you primarily want to send the mail, not to run a Java VM in there). To get the mail going, you need to connect to the Internet using TCP/IP, then using for example the SMTP protocol, you may be able to accomplish this.
The problematic part is connecting to the Internet. For this you need to get your device on a "suitable wire", which is typically Ethernet, but radio based solutions may also exist. Then you would have to implement everything necessary to communicate on that wire (the whole network stack until TCP/IP). This can not reasonably be done all yourself. One way is to use a micro which has some built in Ethernet connectivity and use for example lwip or Contiki depending on your preferences to do the magic. The other way is using extra hardware which does the thing for you such as this Moxa product, but you may not be able to implement SMTP over this.
Then you will "only" need to implement a suitable SMTP (Simple Mail Transfer Protocol) layer to properly send your mail (one or another of the solutions I presented above may already have this for you).
Your microcontroller will need to support the JDK or Java ME (maybe Sun SPOT). http://www.inonit.com/cygwin/jni/invocationApi/c.html has an example of using the JNI to start the JVM and invoke your class.
Microcontrollers very very typically are developed in the C environment since in a microcontroller there are limited resources in terms of hardware power. C is used since it allows the most flexibility and allows fine tuning since in the microcontroller environment real-time computer is very essential. That is not to say though, there is java used in the microcontroller world. Very convoluted though, android runs on some java which in the lowest end possible uses a ARM processor (its up to you to decide if you really want to call that a microcontroller). So all in all, yeah I would recommend that you learn C. If you really want to go the java way, I have not personally run into a lot of resources that allows you to use java on a AVR microcontroller. It might be possible, but expect a hit on performance.
If you have no experience in microcontrollers, I would recommend looking into Arduino (arduino.cc).
Best of luck!
Looking for a way to read the unique ID / serial# of a USB thumb drive;
please note that
- I am looking for the value of the manufacturer, not the one Windows allocates for it.
- I need to support multiple OS (Windows, Unix, Mac), thus needs to be a Java solution
The idea is to be able to distinguish between different USB thumb drives.
RXTX is the way to go. In the world of model trains, JMRI (Java Model Railroad Interface) has become very popular. JMRI runs on all platforms (Windows, Linux and Mac) and communicates with a variety of USB based devices (command stations). RXTX is in fact used by JMRI.
You might give a look at the following projects:
javax-usb and jusb. They seem to support Linux and Windows.
Anyway, since USB access in Java requires the use of native libraries, you might not achieve the required portability.
I've never tried using it (it's been on my todo list for a good few months now), but there is the "marge" project on java.net:
http://marge.java.net/
This should let you connect to bluetooth devices (although I don't think it is 100% feature complete, there is demo code on there), and then the ClientDevice class has a "getBluetoothAddress" method which I believe should be unique to that device
http://marge.java.net/javadoc/v06/marge-core/net/java/dev/marge/entity/ClientDevice.html
As I say though, I've never tried it...
I have never investigated this thoroughly, but from memory the RXTX library implementation of the javax.comm packages are supposedly very good and now have USB support.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I need to send and receive data over serial connections (RS-232 and RS-422).
How do I set up and communicate with such a connection? How do I figure out what the configuration settings (e.g. baud rate) should be and how do I set them?
In particular I am looking to do this in Java, C/C++, or one of the major Unix shells but I also have some interest in serial programming using Windows/Hyperterminal.
Build a time machine and go back to 1987? Ho ho.
Ok, no more snarky comments.
How do I figure out what the configuration settings (e.g. baud rate) should be...
Read the datasheet? Ok, ok. Seriously, last one. If you don't know the baud rate of the device you are trying to communicate with, you have two choices. Start guessing, or possibly bust out an o-scope. If you need a good starting point, let me suggest 9600-8-N-1. My suspicion is you can get there with brute force relatively quickly. There's a third option of having an old-school ninja who can tell just by the LOOK of the garbled characters at some standard baud rate what actual baud rate is. An impressive party trick to be sure.
Hopefully though you have access to this information. In unix/linux, you can get ahold of minicom to play with the serial port directly. This should make it fairly quick to get the configuration figured out.
one of the major Unix shells
In Unix the serial port(s) is/are file-mapped into the /dev/ subdir. ttyS0, for example. If you setup the correct baud rate and whatnot using minicom, you can even cat stuff to that file to send stuff out there.
On to the meat of the question, you can access it programmatically through the POSIX headers. termios.h is the big one.
See: http://www.easysw.com/~mike/serial/serial.html#3_1
(NOT AVAILABLE ANYMORE)
but I also have some interest in serial programming using Windows/Hyperterminal.
Hyperterminal and minicom are basically the same program. As for how Windows let's you get access to the serial port, I'll leave that question for someone else. I haven't done that in Windows since the Win95 days.
If you want to code in Java I really recommend SerialIOs SerialPort. It is very easy to use and saves you days of work. I've never found an open source library as good as SerialIO, REALLY!
My advice: do not use Sun's serial IO framework! It is from 1998 and full of bugs. You can use rxtx but serialio is better!
For C/C++ on Windows you have (at least) two choices:
Use the SerialPort class provided by .NET.
Use the Win32 API. There is an extensive MSDN article dating back to 1995, and many free libraries and examples on the web to get you started.
The .NET option will be much easier.
If it needs to be cross platfrom, I would suggest looking at Boost Asio.
Awhile back I wrote a decent sized application to route connections from a farm of modems through to a TCP/IP network address.
Initially I looked for an unencumbered (free) Serial IO library. I tried Sun's, IBM's and RxTx. They were fine for developing the application, and in initial testing, but in production they each proved unstable.
Finally I paid for SerialIO's SerialPort. Converting over was literally an exercise in changing imports, and the library has been absolutely rock solid - I cannot recommend it enough. My application has been running in the field 24/7 for a couple of years now, with not a single problem encountered by multiple customers.
If you start development using SerialPort, they have a better API and I would use it.
If you need cross platform support, Java with SerialPort was the best choice I could find.
Lastly, their licensing is pretty darn reasonable as long as you are not preinstalling software on the equipment for your customer(s).
From the other side, if you want to do it using C#, which will run on both Windows and Linux--with some limitations (EDIT: which may be out of date. I have no way to test it.). Just create a SerialPort object, set its baudrate, port and any other odd settings, call open on it, and write out your byte[]s. After all the setup, the SerialPort object acts very similar to any networked stream, so it should be easy enough to figure out.
And as ibrandy states, you need to know all these settings, like baud rate, before you even start attempting to communicate to any serial device.
At work we use teraterm and realterm for checking serial data is correctly formatted. Also we have a hardware splitter with a switch so we can monitor traffic to our application via a cable back to another port.
Windows allows you access to the serial port via CreateFile. That gives you a handle and from there you can configure access.
Depending on the device You are trying to communicate with, there may be more parameters than the baud rate, number of data bits, type of parity checking and number of stop bits to consider. If I recall correctly, modems use nine lines of the RS-232C interface. Some devices like, for example cash registers, may use hardware handshaking on RTS/CTS lines or on DTR/STR lines.
In general it's good to know how the interface works. You can't communicate if the baud rate doesn't match, but wrong setting of other parameters might kind of work. For example You can easily send data to the device expecting 1 stop bit with 2 stop bits set. Problems start when You try to receive data in such case. You can also use appropriately set parity bit as one of stop bits, etc.
If you are not forced to use a particular compiler I suggest to use Qt and in the new 5.3 version you will find a class dedicated to serial ports:
http://qt-project.org/doc/qt-5/qserialport.html
The code you will write will run on all supprited Qt platforms, at least those that have serial ports.
I have been using purejavacomm:
It is an implementation of javax.comm written in pure java + JNA
Unlike rxtx, you don't need to install a dll. It is written in pure Java + JNA, which solved the problem of portability between Windows and Linux for me. It should be easy to port to other OS-es that JNA supports, such as Solaris and FreeBSD, but I haven't tried it.
You might expect a pure java library to lag behind a native implementation such as rxtx in performance, but with modern CPU's, the bottleneck is very likely to be the bitrate of your serial port, not CPU cycles. Also, it's much easier to debug than a mixed Java/Native library or pure compiled native code.