Realbasic Serial Communication In Java

REALbasic Infobox Software name = REALbasic logo = caption = The REALbasic IDE running on Windows Vista developer = REAL Software, Inc. Latest_release_version = 2008 Release 4 latest_release_date = September 23 2008 operating_system = Mac OS X, Microsoft Windows, Linux genre = Programming license = website = REALbasic ( RB) is an object-oriented dialect of the BASIC programming language developed and commercially marketed by REAL Software, Inc in Austin, Texas for Mac OS X, Microsoft Windows, and Linux.

History REALbasic was created by Andrew Barry. It was originally called CrossBasic due to its ability to compile the same programming code for Mac OS and (although the integrated development environment was Mac only). In 1997 CrossBasic was purchased by FYI Software which renamed it REALbasic as well as renaming the company REAL Software. At this time they dropped the Java target, later replacing it with a Windows target and database support. The is now available for Microsoft Windows, Mac OS X, and Linux and can compile applications for Windows (Windows 2000 and higher), Mac OS X ( PowerPC, Intel, and Universal Binary) and x86 Linux.

Language features RB is a strongly-typed language with minimal automatic type conversion, which supports single inheritance and, and class properties, automatic memory management via reference counting, and operator overloading. A very important feature is the ability to extend (not just from) existing classes, like Objective-C Categories. This considerably reduces the need for the, which complicates using Application Frameworks in and C++. REALbasic also includes, introspection, and support, which allows modules to contain classes, interfaces and other modules.

When Hyperterm or Teraterm connect to the virtual serial port, the MS driver sends DTR ON to the device (Xmega) in the Set_control_line_state setup packet. When they disconnect, the driver sends DTR OFF to the device.

Brays doesn't do this, but you may be able to tell by other means. When Brays disconnects, the driver sends the DTR off but when Brays connects it usually does not send the DTR on. You may be able to detect a connect by other means. In every case, when any terminal connects, the driver sends a whole bunch of Set_line_coding and Get_line_coding setup packets. Apparently the monkey that wrote the driver was getting a banana for every line he wrote. In every case when the terminal program disconnects only one setup packet is sent. That being the Set_control_line_state with DTR off.

By the way, has anyone found the Win7 driver (usbser) reliable? I've never observed it working right for more than 12 hours and it often goes haywire much sooner. Doing a bunch of connects/disconnects will often get the virtual serial port hosed. Yes it seems Brays doesn't mess with DTR/RTS normally. I think I saw it set DTR once on it's own, but I can't recreate that.

Brays does have a DTR button and a RTS button on the right near the bottom. If the DTR button is toggled ON, the DTR ON is sent to the device when I click on the Connect button, and DTR OFF is sent when I click Disconnect. The RTS button seems to have a mind of it's own. Normally it does nothing but I did get it to send RTS once, but I can't recreate that.

Had no problems with RealBasic/Xojo serial ports (virtual or real) over months time scale. It may be different with Prolific vs FTDI chips in the USB dongle. Serial ports are supported in almost all languages (C, C++, C#, Java, Python etc.) where as HID needs WinUSB or whatever. The biggest down side. Write a program to read those bytes. For this step, you'll need a programming environment that runs on the personal computer itslf, not on the microcontroller. Any environment that can open and close a serial port will do. For example, Java, Processing, Director, RealBASIC, Visual BASIC, and Max/MSP can all access the.

I've got Brays 1.9b. I think that's the latest. I use the OpenFile API. I've never used.Net. I've not used the dongles much. I believe they use their own driver which is probably better than Microsoft's.

I've kept them plugged in unused for a few weeks and they invariably cause a blue screen. My computers often run for 2 or 3 weeks without a restart. They do go to sleep each night and often during the day.

I think sleep, or more properly, waking from sleep that causes much of the trouble. I want my Xmega to be 'embedded' inside the computer case and permanently plugged in and I want to be able to access it by a communications link at any time. I can do that using rs232, but USB CDC with the current Win7 Microsoft driver is a non-starter. Microsoft modified the driver for Win8 and that seems to be reliable.

I had it running for a week and it always worked. We use.NET serialport for a commercial project. I wrote most of the code myself and found some interesting things..NET is really, really slow if you try to read characters.

You need to read small chunks at a time rather than characters or your 3.2GHz quad core PC won't be able to keep up with your 32MHz micro. If you get any errors at all on the port it stops working until you clear them. When opening the port you might as well just call the function, sorry method that clears errors, and check for new ones periodically. Oh, and buy is it a pain in the arse to detect when USB devices are attached or removed. Also if you have a USB serial port you must close it as soon as the USB device is detached, or when you reconnect it the port will appear in Device Manager but you won't be able to open it. Mojo-chan wrote: Also if you have a USB serial port you must close it as soon as the USB device is detached, or when you reconnect it the port will appear in Device Manager but you won't be able to open it.Tell me about it! Why oh why must the device pretend to me something like a modem or mouse or toaster etc.

Why oh why can't there be a simple logical USB protocol that allows the PC to send packets to the device and allows the device to send packets to the PC. With that I could rule the world, launch missiles etc.:). Steve17 wrote: Is there a way? I use the Win32 CreateFile() etc. I suppose I should investigate. I'm so suspicious of the Win7 usbser driver though that I fear it would be hopeless. You have to set up a callback for Windows messages relating to device changes.

Of course if you use WFP you have to first get a handle to the WPF window. Anyway, you get helpful messages like 'something changed but we won't tell you what, haha!' And then have to do another query to figure out what it was.

Then you have to try and match that up to the device you want when opening the COM port by going through all attached devices. Serial ports have their advantages. You can just plug something in, and nobody asks questions.;) I'm wondering if it is possible to do a similar thing with USB. Of course the USB host does ask some questions, and up to a point that makes sense.

But I'm wondering if we can somehow tell the USB host we are a generic device and not specify a manufacturer. And if we do that I'm wondering if we need a.inf file at all. I'm looking at Device Manager. Most devices plugged in have a manufacturer, but some don't. My keyboard manufacturer is shown as (Standard keyboards).

My monitor manufacturer is shown as (Standard monitor types). My computer shows up as (Standard computers).

I understand that Atmel may require we show up as their product when we use their VIDs and PIDs. But if we get our own VID and PID, could we use Microsoft's standard driver without screwing with an.inf etc? Quote: I'm wondering if it is possible to do a similar thing with USB. Of course the USB host does ask some questions, and up to a point that makes sense.

But I'm wondering if we can somehow tell the USB host we are a generic device and not specify a manufacturer. And if we do that I'm wondering if we need a.inf file at all. It certainly is possible. Just create a HID device with a HID descriptor that contains only manufacturer specific custom data.

Windows/Linux will load the standard HID driver and then ignore it. Your app can talk to it via something like WinUSB or libusb. I almost went down this route, but there are a few disadvantages. You need to write custom software to talk to your device, no simple terminal apps. Serial ports are supported in almost all languages (C, C++, C#, Java, Python etc.) where as HID needs WinUSB or whatever. The biggest down side is that HID is slow. Packets are limited to 64 data bytes maximum.

Latency is a minimum of 10ms. IIRC you are limited to low speed as well, although I think most operating systems won't mind if your device is full speed. Quote: Interesting idea clawson, but wouldn't the microcontroller side implementation be a pain in the arse? Emulating a flash device and filesystem, or are you suggesting having an actual flash memory and filesystem with shared access? Take a look at LUFA.

If I remember rightly the actual MSD interface itself is very 'raw' like writing sectors on a hard drive. In fact I think it's very like that - you just get an LBA number and a block of data for that 'sector'. Of course layers above this 'think' the storage device has a file system of some sort (presumably based on reading the early sectors and seeing what's there) so if you really want to be able to write 'hello' to fred.txt then you are going to have to fake a filing system and the obvious/easy one is FAT16. So I think the LUFA examples join LUFA and FatFs to present what appears to be a FAT structured device.

In fact one of Dean's most 'fun' projects is a bootloader that looks like a FAT MSD - you just copy a file to it and it writes that to app flash and all that happens in the size of a bootloader section. So I'd start with that as an example to see the minimum of what's necessary. EDIT: yup, see virtualFat.c which fakes an absolute minimal file system which appears to have two files called flash.bin and eeprom.bin. You then write to either file and the bootloader code captures the data and actually writes it to the chosen memory. Apparently the whole thing builds to 6K in a chip with 8K bootloader section.

I have to admit I'm impressed by that, it's a nice hack! Unfortunately not flexible enough for what I need (command terminal, complex data logging) but quite a nice way to do a bootloader. MSC would seem to be a fairly safe bet in that Microsoft can't really break it in the future, since no-one supplies signed drivers for their flash drives. Seems like someone has tried the HID-serial method and found it has issues, although they could be related to VUSB: I did some research and for HID the minimum latency is 10ms for low speed and 1ms for full speed, but I have noticed that Windows doesn't always poll this fast. For example with a CDC device if you toggle the DTR line faster than 10ms it is often missed because Windows only polls at ~10ms intervals. Also, for HID on full speed devices only 64kb/sec bandwidth is allocated to them, and that includes all the report overhead data so in reality 10-20k/sec is probably what you will see. Download Game Psp Untuk Emulator Ppsspp. On a good day, with the wind in the right direction.

Slanted And Enchanted Luxe And Reduxe Rar Files. The situation is quite annoying. The problem is trying to do two way comms.

The way LUFA does it the files are block mapped and the blocks map directly to the AVR's flash memory. They are not treated as file streams at all, just raw blocks on the virtual disk.

Trying to extend that to having both the PC and AVR read and write files of ever increasing length is going to be tricky. Many long years ago I wrote a chat program for Netware that used a shared file on a network drive, and it had issues with all clients staying in sync. That was with Netware arbitrating access to the file too. I'm hoping the host program can just read the same file each time. If the device has a packet to send, it will send it. Otherwise the USB hardware just sends the 'nothing to send now' indication. How long the host driver will continue to 'poll' the device before giving up, I don't know.

I suppose I would have to disable any disk caching or the host might not actually reread the file. In my case the device doesn't normally send unsolicited packets anyway. The host sends a command, and the device sends a reply. I won't know how well it will work until I try it. The USB Ethernet could be a better way, but again I won't know until I try it.

Dean seems to send IP (internet packets) as data. That would be an additional complication I could live without. I don't know if the PC driver requires IP packets. Another thing that makes me nervous about the USB Ethernet driver is there are probably a lot fewer Win7 machines that use it than use USB mass storage. The fewer the users, the more likely the driver is buggy.

Quote: but not particularly cheap solution. The PL2303 drivers are terrible and the hardware is flaky. I have not tried the MCP2200 but it looks potentially like it could be quite good. Might try one on the next project. Just for fun I tried cloning the MCP2200 VID/PID on my AVR and the driver installed and operated perfectly, no nasty warnings etc. I was able to identify my device via the serial number, so my code could automatically find and utilize it.

Bit of a dick move but I blame Microsoft:).