Gambas Serial Port Send
Riporto questa discussione apparsa nella M.L. Ufficiale: ' G'day all: Now with Gambas 3 installed, I want to get on with porting my running software from VB6/Windows. It requires processing multiple streams of binary serial data from attached devices.
I would have one function which is the _read of the serial port. [Gambas-user] Serial port control > I think the. As the device can send them and.
The serial control in gambas 3 does not seem up to the job, in so far as the available properties lack the elements I use under VB MScomm. In addition to the basic ones, these are inbuffer.size, outbuffer.size, inbuffer.count, inputMode, input Len(gth), PortOpen and, in particular, R Threshold and S Threshold. The latter R/S Thresholds are very useful in allowing the software to get on with other processing while the buffers are filling - at least that is my understanding. I ask if whoever wrote the gambas serial control has any plans to expand it's functionality to the MScomm level in the foreseeable future or can someone point me to another more comprehensive control I could use with gambas? Carl ' ' As I recall gb serial is steam based and so you would handle buffers via the stream not the serial object. Randall Morgan ' ' Randall: Thanks for responding.
OK, I have looked at the stream functions: My question was, basically, how do I specify how many bytes I want to take in from a given serial port at each instance? For example, on one input I expect a continuous stream of 31 byte packets and I want to take them in for processing 25 (say) packets at a time, i.e. 775 bytes at a time. Now I don't much mind if I get a few bytes more or less because I can check for a remainder part-packet and put it on the front of the next nominal 775 byte intake - that's part of the processing software - but I don't want the CPU tied up with that port or stream between intakes of (about) 775 bytes. There are other input streams and data processing to attend to. I don't see how to do that with the stream functions - but maybe I'm not understanding how the stream works?
Parallel Port To Usb Adapter
I can see that I could (I think!) read a given number of bytes from a stream, but does that relieve the CPU from being tied up with that stream until I read another 775 bytes? Is a stream of indefinite length or does it have some buffer limit?
Carl ' ' It has been a long while since I have used the serial component of GB but I have a project starting in which I will need to re-acquaint myself with it. The stream can be setup as blocking or non-blocking.
The PC uses either polling or interrupt when the port is opened. So trying to manage the serial port at the same level you would in on uC is pointless in most cases. Just set up the stream and read the bytes you need from there. If you're concerned about buffer overflow then you may want to close the port once you have read the bytes you need. Perhaps someone with more recent experience can help you more.
Randall Morgan ' ' Thanks Randall. I guess it's time to try it and play around a little, which I can't do for a few days. At the moment I'm trying to look ahead and see where problems might lie. When push comes to shove, I don't know how these things really work! I follow recipes! Don't really want to close the port as the data come in continuously as fast as the device can send them and I don't want to miss any.
(It's attitude sensor data from an inertial management unit in a light aircraft). Same in principle with another 'continuous' stream of binary GPS data with packets of 124 bytes coming in at a slower rate of, say, 4 Hz. How 'continuous' it is would depend on the baud rate at which the port is operating. The RThreashold property of MScomm handles this issue very well. Doesn't trigger an event until the specified number of bytes is in the serial buffer. Carl ' ' I think the RTheshold of VB simply sets the byte count that must accumulate in the receive buffer before a comm event is triggered.
It doesn't do anything else. In the background VB is still polling the buffer and looking at the byte count.
You can do this in GB but you will have to write it yourself. You would need to simply use the read event on the comm object to test the byte count.
I believe it triggers at 1 byte. Then use that to trigger your own custom event when your 124 bytes have arrived. You might also be able to talk Benoit into adding an RThreshold property. Seems like it might be handy. At the very least 4Hz is very very slow for most computers.
And setting up a 4Hz polling of the port wouldn't be hard at all. Randall Morgan ' ' I have used the serial port for 5+ years with Accelerometer and GPS without fault nor failure on the serial port control.
Some use RTS/CTS, some done. My suggestion is not to think it needs to mimick what MSComm does and how you have used MSComm in the past. Learn what it does and how you can use it for your devices.
I assure you it can certainly do it without fail. My suggestion to reading 124 bytes from a serial stream.
I use this technique mostly because I want to empty the buffer provided by the control as much as possible. I would have one function which is the read of the serial port. The only thing it does is accumulate bytes in an array. I have another function which will ask for 124 bytes from the accumlating array. If there are not enough, it can block, or return an array of zero long which would mean not enough came in. In this case you could also do a small time delay (ie. WAIT 0.1) just to prevent the CPU from running 100% testing for 124 bytes.
Both of these can be a Gambas Class and the second function is the public function. You can use new to instantiate the serial port control. You don't need to create it at design time. I used techniques like this and it works like a charm.Nando ' ' Carl, will you be using the PC end and gambas code as the master or slave, if master then just use the sport read interupt function. Remember you will have to use chr and asc if using binary data streems. The Gambas3 serial example is very good.
If any data is in the input buffer it will trigger the SportRead sub and exit leeving the system free to carry on. Just use the PC as master to request data from the slave of slaves. Private Sport As SerialPort Const None As Integer = 0 Private RxLen As Integer Private Rx As String Public Sub FormOpen Sport = New SerialPort As 'Sport' Sport.PortName = '/dev/ttyACM0' 'Setup for Arduino you may have to change to ttyUSB0 Sport.Speed = '57600' Sport.Parity = 0 Sport.DataBits = '8' Sport.StopBits = '1' Sport.FlowControl = 0 Sport.Open End Public Sub SportRead Try Read #Sport, Rx, Lof(Sport) If Error Then Goto NoRx Endif RxLen = InStr(Rx, Chr(13)) LabelRxlen.Text = RxLen ListBox1.Add(Rx) NoRx: Rx = ' End Best Regards Mike '. ' G'day Guys (Nando, Randall and Mike): Thanks for your helpful replies. It's 5 am here and I woke up an hour ago with this matter running through my head, so your replies are welcome! All good advice. I realized that, first of all, I needed to get a handle on using the stream functions, which are quite new to me.
Secondly, as usual, there are many ways to skin a cat. You are right, I need not be dependent on an RThreshold property. I have been using this for years most successfully with MScomm in VB6. It does exert efficient control, but sometimes my incoming packets vary in byte count. So, early in the piece, I wrote code that would look for any remainder bytes or shortfall on the end of the designated input stream and put them onto the start of the next byte block to get back into synch.
The Windows kernel has a very efficient function called 'MoveMemory' that can be called from VB6. (I presume Linux has something similar). It's very much faster than shifting bytes in Do loops. Anyway, not being dependent on an totally accurate byte count prior to triggering an event suggested an alternate approach: My principal data device is a decade-old Microstrain Inertial Management Unit (IMU).that sends remorselessly at around 2356 bytes (sometimes plus a packet or two) per sec.
At the moment I'm doing all my processing on an old Advantech 9576F single board computer running Win 2K. With about 8 serial ports in action and heaps of other processing to do, I wanted to ease things with some preprocessing of some data streams on one of these little new ARM boards like the Raspberry Pi or Beaglebone Black - the latter with at least 4 UARTS and running at 1 GHz seems very attractive.
They can run fully embedded under Linux with gambas for initial data processing. I have an RPi now with gambas3 and wiring Pi installed to experiment with. Sometimes the IMU traffic is duplex when I change parameters in flight and additional data packets come back in addition to the normal data flow.
So I adjust the RThreshold value dynamically, but that's not vital. All this adds up to the fact that another approach might be to trigger processing events simply with a timer - read the full stream each time and get the byte count approximately right.
With a 'MoveMemory' function I can easily handle some unevenness in byte count. As I said, I'm looking for the least drain on CPU load. I don't really need the system tied up waiting and testing for an exact count. Anyway, I thank you for all your comments. I now know that what I need can be done and the next step is for me to experiment. Yesterday I was having some doubts about choosing gambas.
Nice to talk with you guys. I'll get back to you when I have something more useful to say or ask. Merry Christmas, Carl '. ' Hi Carl, I have a BeagleBone Black up and running with wheezy, LXDE desktop and Gambas 3.5.9 I am able to use all most all of the available GPIO and read the AD's using Gambas, I have not had any uarts up. I see no problem in getting the the uarts to run using standard USB to serial converters (Jaycar) work well with the Rpi.
I also have Rpi series B running with the same OS & desktop as the BBB and using Gambas 3. This is connected to an Arduino Uno via a usb uart on the Rpi used to control 6 signals and 7 point motors on a miniature railway all running at 56000 baud. Using an input from the terminal the Gambas software sends an ASCII message via the uart to the Uno and it will execute the request (change points or signals) and send back an ASCII message the request was executed.
Iar embedded workbench. This is not a very high speed system as changes may be seconds or minutes. I have also used Gambas to communicate with PLC's using Modbus RTU and crc16 at 9600 baud with high volume short interval requests over RS485 networks and up to 20 nodes.
The secret was to use a PC, PLC or RTU as the master and use a timer to set the pole rate from the master. I have also as you used VB6 to implement an extensive SCADA system for small power house control. This was a very high volume data through put and I did not find the need to use any special data handling to free up the PC.
The PC was off doing a lot of other stuff while the SCADA was running. I have implemented a small test SCADA module in Gambas and see no problems with speed compared to commercial SCADA packages even when using the DNP3 protocol. The through put with VB6 or Gambas seemed to be about double compared to commercial solutions. I would say I have had best results using an interrupt driven serial routine to empty the uart buffers and handle the data. VB6 using OnComm function and Gambas using SportRead function.
Variable buffer sizes can be dealt with by checking the length of the input string using CR as the end of line indicator (chr13) as used in most protocols (modbus ASCII & RTU). Try something like, Try Print #Sport, Tx; Chr$(13) in a timer function or from terminal input to send data through the uart. If needed I have the Gambas modbus test program and a Koyo Click PLC (under $100 au PLC software is free) to test and see if the code is still OK, the modbus protocol uses binary data over the comms link. Hope this is of some help.
Best Regards Mike ' ' G'day Mike: hey, that's great. I have an old fashioned model railway - H0 scale - which baseboard plus track stands lonely in my hall. Last used in the 1980's.
Serial Port Purpose
My young son liked to see things crash a little too much for my wanting to trust my precious stock, so I bought him a Scalectrix set instead. Once I got myself an ultralight aircraft in 1997, I have never found time to get back to the railway. Bigger toys for older boys! I built this Advantech-based computer running Win 2K for the a/c in about 2006 and have been programming ever since. I started using an iPAQ PDA h2115 which I still run as a backup control and display on the dash. VB6 and Appforge MobileVB came my way at a good price and have done the job well enough. I have an 8 inch touch screen on the dash for the Win 2K display, which can display a whole range of pages associated with flight planning, navigation and attitude (an electronic artificial horizon).
Game Port
I use OziExplorer to run a moving map display in parallel. (My old eyes can't see very small maps and labels on the PDA too well).
The touch screen cost me $250 - now I have an 8' Android tablet (cost $160) with which I plan to replace the screen one day. Now, the tablet has a 1.5 Ghz dual processor and that can also handle a lot of the computing I need done.
Hence the long term plan of replacing the Advantech with something like a Beaglebone, in which the latter can handle all the serial inputs and pre-processing and should make a better embedded system. (However, as I get more acquainted with Linux, I get increased respect for how easily I could get stuff done in Windows!). I also want to implement a wing-leveller - a one-axis auto pilot. The electronic servo work is largely done - I need to build the mechanical stuff in the aircraft, which has to be done very thoughtfully! On my RaPi series B I used a download of 2012-07-15 wheezy-gambas3-zip from which gave me a gambas 3.2.1. I had the well -documented difficulties with gambas 3.5 when I installed it on the wheezy which I installed from the RPi site. Recently I discovered the FTDI mini-module which will give me four UARTS off one USB port, which will be all I need extra on the RPi.
(I also have the SPI and I2C ports available). I'll start by augmenting some of the serial data processing on the Pi which I presently do on the Advantech. When I try to increase the whole cycle update and display rate beyond about 3 Hz on the present system, I seem to get into trouble. Not sure what it is, but it just doesn't seem to have enough time to do the required processing, display update and attending to all the serial inputs. Palming off much of the late-stage processing and display to a tablet seems a good idea for the future, although I'm stumped at the moment at getting my Pipo S2 tablet to accept a USB to serial converter. I am confident I will eventually be able to do that, though. At least I have got the tablet rooted and able to backup the Android ROM, as of yesterday!
That's enough for now - I have to pack. We have quite a lot of interests in common, it seems, so good to have met you and I hope to keep in touch! Regards Carl '.