QB64 is getting slower?

[david_uwi]

I am transfering data using a serial COM port and the newer versions of qb64 are slow (and cause the data to get corrupted). The new version was downloaded 12 FEB 2018.
My older version QB64 ver0.954 from 2012 is much faster and the data transfer is good (I am working at 9600 baud, but changing this seems to make no difference).

[FellippeHeitor]

Version 0.954 was the last version of QB64 that used SDL before it was migrated to OpenGL. Version 1.000 was probably as slow as you feel the latest version concerning data transfer. I don't know what has changed in that regard but the library has probably been changed in the process too.

The advantage of the switch to OpenGL was mainly to produce standalone binaries (as opposed to having to carry a handful of .DLL files with your program). Of course there have been improvements and fixes to the language since then, but if 0.954 still suits your needs, it may be wise to keep using it for now.

Can you confirm if 1.000 is as slow as you have felt the latest version to be? We have a link at the bottom of the home page to historical versions of QB64 and you can fetch it for testing.

[FellippeHeitor]

BTW, welcome to the forum.

[david_uwi]

It clearly can no longer accept data at speeds of 9600 baud. Here's the code

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(680, 800, 2)
2. font1& = _LOADFONT("c:\windows\fonts\times.ttf", 12)
3. _FONT font1&
4. ON ERROR GOTO handler
5. DIM a AS STRING * 1
6. DIM b AS STRING * 1
7. OPEN "c:\cw1\pressout.txt" FOR OUTPUT AS #2
8. OPEN "com6:9600,N,8,1,CS0,DS0" FOR RANDOM AS #1 'baud rates 115200 19200 9600
9. DO
10.    10 WHILE LOC(1) = 0: WEND
11.     GET #1, , a
12.     IF I = 0 AND ASC(a) = 0 GOTO 10 'strip off dummy byte(s)
13.     WHILE LOC(1) = 0: WEND
14.     GET #1, , b
15.     I = I + 1
16.     xI = ASC(a) + ASC(b) * 256
17.     PRINT xI;
18.     PRINT #2, USING "#####"; xI;
19.     PRINT #2, "  ";
20.     IF I > 1 THEN
21.         IF I MOD 16 = 0 THEN PRINT #2, ""
22.         IF I MOD 16 = 0 THEN PRINT I
23.     END IF
24.     IF I > 5887 THEN EXIT DO 'end of transmission
25. LOOP
26. CLOSE #2
27. CLOSE #1
28. END
29. handler:
30. PRINT "in error handler"
31. SLEEP (1)
32. RESUME

I will have to stick to the older version.
Yes I can try some other versions

[david_uwi]

I've been thinking more about this and it is actually worse than I thought.
I have a microprocessor sending data to a FT201X using I2C at 400 baud ! This is then sending the data via USB to a virtual COM port.
The data is coming through noticeably much slower on new versions of QB64 (it reminds me of teletype kind of speeds).
So it would seem that 400 baud is a bit too fast for the newer versions.
Could I be doing something wrong?

[TerryRitchie]

This would be well worth looking into. It sounds like David is using the older version of QB64 to communicate with Arduino and RasPi devices, something I would love to start doing. Utilizing IoT with QB64 could be huge.

I'm already envisioning an InForm front end to control appliances and IoT devices around the house, much like X10 was used for.

[david_uwi]

oops! I set the I2C speed at 400 it is actually 400,000 baud so that's pretty fast , but it should be buffered and slowed down to 9600 for serial transmission via USB. It may well be that using the newer slower versions of QB64 the buffer on the FT201X is overflowing (there is quite a lot of data to transfer). Yes the FT201X only has a 512 byte buffer.
As for the application:
I am using microchip's 8 bit PIC microprocessors (PIC 16F1789 currently). There is a free QB-like programming language that is fairly easy to use... see
http://gcbasic.sourceforge.net/

Edited to add: I think the I2C should stop before the buffer overflows by not sending an acknowledge until the buffer is freed.

[david_uwi]

I've done a bit more testing today. The old QB64 works fine at 115200 (needed to set the higher speed in the windows control panel) and is, obviously at that speed, very fast and accurate. With the newer versions I end up with lost  and incorrect data and it runs much slower.
Perhaps I should have put this in the "bugs" sub-forum because that's what it is seeming to look like.

Does anybody else use serial COM ports? (Of course this is actually USB pretending to be a COM port, but still should work)

[TerryRitchie]

Does anybody else use serial COM ports? (Of course this is actually USB pretending to be a COM port, but still should work)

A few years back I tried communicating with an Arduino Uno with limited success but really didn't have the time to investigate further. I have plenty of Arduino and RasPi variants that I can use (even some very old Basic stamps). Would you be willing to share the code you have that works perfectly with older versions of QB64? If so I'll dig my microcontrollers out and get them working with version .954 of QB64 and then help investigate the issues with the latest version.