Basic Micro Studio - Changes in Beta from Build to build

[linuxguy]

@kurte

Warning, there appears to be a problem linking any program that uses HSERVO, so you may want to hold off.

Yes, indeed. All it takes is a simple little program that uses HSERVO to reproduce the link errors. This is for the Atom Pro, so I’m not sure if it affects others or not.

8-Dale

[acidtech]

You can get Studio 1.0.0.30 now on Basicmicro’s AtomPro forums now. It fixes the hservo bug I inadvertantly introduced in 29. I need to learn to spell PUSLE as PULSE .

[linuxguy]

Basic Micro Studio #30,

I was editing, and all of a sudden the whole studio window went shaded dim and I have the “processing” cursor, with 60% - 75% CPU time being used by the software. I can’t do anything at all with it. This is under Windows Vista. It seems to have just gone away and I don’t think it’s coming back.

8-Dale

[linuxguy]

Please, please, PLEASE, allow for changing the font and font size for all panes in Basic Micro Studio. I simply can NOT look at the current small text for any reasonable length of time. I need to be able to control the font and text size so I can make it more easily readable. This is a VERY IMPORTANT usability feature for any major software, such as this.

8-Dale

[acidtech]

@linuxguy

Basic Micro Studio #30,

I was editing, and all of a sudden the whole studio window went shaded dim and I have the “processing” cursor, with 60% - 75% CPU time being used by the software. I can’t do anything at all with it. This is under Windows Vista. It seems to have just gone away and I don’t think it’s coming back.

8-Dale

Can you reproduce it? Can you send me a copy of the file your were editing at the time?

[acidtech]

@linuxguy

Please, please, PLEASE, allow for changing the font and font size for all panes in Basic Micro Studio. I simply can NOT look at the current small text for any reasonable length of time. I need to be able to control the font and text size so I can make it more easily readable. This is a VERY IMPORTANT usability feature for any major software, such as this.

8-Dale

I’ll try to do something with it. I can probably make the edit windows fonts seletable. Changing all the other windows(workspace/build/output/terminals etc…) may be very difficult.

[linuxguy]

@Acidtech

Can you reproduce it? Can you send me a copy of the file your were editing at the time?

Unfortunately, I can’t reproduce this now. If it happens again, I will try to get a picture of the screen as well as save an exact copy of what I was editing at the time.

8-Dale

[linuxguy]

@Acidtech

I’ll try to do something with it. I can probably make the edit windows fonts seletable. Changing all the other windows(workspace/build/output/terminals etc…) may be very difficult.

I would GREATLY appreciate it, Nathan. The editing and terminal windows are most important, at least to me. When I’m in the zone and am coding, I hate being interrupted by not being able to see the text of my program and its output.

8-Dale

[kurte]

New version posted last night: downloads.basicmicro.com/downloa … 0-0-31.exe

@Acidtech

Fixed 1-wire commands on AtomPro
Fixed #includes on AtomPro
Fixed nested conditional compiling directives on all processors.

[kurte]

I thought I would post some more information that Nathan posted about build 31…

@Acidtech

As of 1.0.0.31 and up if you ENABLEHSERIAL or ENABLEHSERIAL2 but do NOT do both at the same time you can use either hserial or hserial2 commands(eg hserin,hserout,sethserial will work on ENABLEHSERIAL2 just like hserin2,hserout2 and sethserial2 and vis-versa).

Only when using BOTH ENABLEHSERIAL and ENABLEHSERIAL2 will hserial commands only work with uart1 and hserial2 commands only work with uart2.

Also you can #ifdef the ENABLEHSERIAL and ENABLEHSERIAL2 to the specific processor.

#ifdef BASICATOMPROARC32 ENABLEHSERIAL2 #else ENABLEHSERIAL #endif

EDIT- I was playing with converting the XBee code from HSERIAL to HSERIAL2 calls such that I can more easily combine the two code bases. To be clear you still use ENABLEHSERIAL on BAP28. With this you can use either HSEROUT our HSEROUT2 calls. On the BAP40 or Arc32 if you use ENABLEHSERIAL only, either HSEROUT or HSEROUT2 will go to the first hardware serial port. If you only use ENABLEHSERIAL2 these calls will go to the second hardware serial port.

@Acidtech

The processor defines are added automatically depending on the attached processor(or the selected processor). All the possible defines are:

BASICATOM18NANO BASICATOM28NANO BASICATOM40NANO BASICATOM24 BASICATOM28 BASICATOM40 BASICATOM24D BASICATOM28D BASICATOM40D BASICATOMPROONE BASICATOMPRO24 BASICATOMPRO28 BASICATOMPRO40 BASICATOMPROARC32 BASICATOMPROSS2 BASICATOMPROSE2

The SS2 is the AtomPro 48pin interpreter chip
The SE2 is the AtomPro 64pin interpreter chip

Thanks Nathan

[kurte]

@Acidtech

Minor fix for #includes

downloads.basicmicro.com/downloa … 0-0-32.exe

Another customer pointed out my systrem constants and variables were being processed before the #include so none of the system cons or vars were being set in the #included files.

[kurte]

Build 34 is now available: downloads.basicmicro.com/downloa … 0-0-34.exe

Things that changed in 34:

@Acidtech

Added support for left and right quote marks. This is because our PDFs tend to use left and right quotes instead of normal quotes in the sample code listed. This removes the necessity to “fix” cut and pasted examples from the datasheets.

Added hserinnext and hserin2next functions. These function return the next character available in the hserin buffer without removing the character from the buffer. When I post my SSC-32 compatible firmware for the ARC-32 you will see this being used alot.

syntax:
hserinnext mode

mode - tells hserinnext to wait for a byte to be received if no data is already available(1) or to return -1 if no data is available(0).

example:
if(hserinnext 1=“A”)then
…do something…
endif

In addition:

@Acidtech

The one HSERVO change since 33 is that HSERVO now will ignore the speed argument if the current position is -30000 on the AtomPro40/ARC32 or -24000 on the AtomPro24/28s(eg the servo position isn’t set). This should fix the problem were people forget to initialize the servo positions before using speed control.

For those who don’t know those positions(-30000 and -24000) are the STOP positions. If you set a servo to those positions(on the appropriate processor) HSERVO will stop outputting pulses to that pin. On analog servos this will cause the servos to power down. On most digitals(maybe all) the servo will still hold it’s last known position so this is less useful.

Not sure if I ever mentioned build 33… Changes were:

@Acidtech

Fixes:
Hserin2 timeout
LCDRead on atompro

Updates
LCDInit, LCDRead, LCDWrite updated to new syntax format on Nano and Atom processors to match current AtomPro syntax.
The old formats of the LCD commands on Nano/Atom are still available as LCD2Init, LCD2Read and LCD2Write.

Note for those who wish to keep up to date and know what is happening from build to build. I suggest that create an account on the Basic Micro forums and go to and subscribe to their news forum: forums.basicmicro.net/news-f481/

Kurt

[kurte]

Just as I did the above post, Nathan just released another build.

@Acidtech

This is a minor release. This release will automatically replace left and right quotes with standard quotes. This has been added because code pasted from the datasheets may have left and right quotes instead of normal quotes.

BasicMicro Studio 1.0.0.35

Kurt

[robotdude]

You are a scholar and a gentleman. We really appreciate you Kurt! Thanks!!!

[kurte]

Nathan release another new build yesterday: BasicMicro Studio 2.0.0.0

The current release notes include:

@AcidTech

Fixed the single " causing the editor to freeze up
Fixed the ASM{} syntax error message in the compiler
Fixed some bugs in the debugger. The debugger should be more accurate on line positioning. Also the variables/SFRs/Ram will be updated after each command automatically and if Auto Update is enabled they will be continuously updated.
Added the Library menu. Right now it is pretty barren but we will be adding samples,examples and functions/subroutines to it over the next couple releases. If anyone wants to they can submit their own functions/subroutines for inclusion in future releases. The library system support .bas and .sub files. The .bas files are complete examples and will open as a copy of the basic file included in the library where ever the user wants to put it. This way the master copy will never be changed. The .sub files are basic subroutines that can be added as files to projects or as the code copied into the currently active basic file where the cursor is currently at. We will be adding some examples to the manual to show how this works, but I think most people will get it right away.

Changed the version number to 2.0 because I change the GUID of the installer. This installer will not conflict with older installers (eg 8.0) which caused some problems when users didn’t uninstall the older version using the old uninstallers.

Warning: My Arc32 phoenix code (BASIC) does not currently compile. It is complaining about the HSEROUT2 command. There was a discussion up on Basic Micro forum by Dale that mentioned they wanted to clean up these commands, from something like:

hserout "Output on first hardware port"]
hserout2"2nd hardware serial port"]

to:

hserout 1, "Output on first hardware port"]
hserout 2, "2nd hardware serial port"]

Note: the 1, may be optional and default to 1???

EDIT: Note: The editor tooltips appear to show the new format, so will try editing… This is from the post at Basic Micro under the new syntax manual…

@Dale - Basic Micro

Heres what we landed on. The enable function is gone and the compiler just uses the SETHSERIAL. Syntax is as follows:

sethserial uart, baudrate {,databits, parity, stopbits}

hserin uart, {timeout,tlabel,}{modifiers} InputData,{modifiers} InputData2]

The DataBits, Parity and StopBits are now optional in SETHSERIAL. If you dont define them it will default to 8N1. Uart is only a 1 or 2 for now. If you want to use both UARTS on supported processors you just use SETHSERIAL twice UART 1 and UART 2:

sethserial 1, H9600
sethserial 2, H38400

The HSERIN with the added UART argument, now lets you define what UART you are getting data from:

hserin 1, InputData1
hserin 2, InputData2

We went with this format to fit in large UART capable processors. At some point in the future when a more capable processor comes out we can support all its UARTS without breaking a bunch of stuff. The idea across the board is fixing all the commands one last time but with room to grow.

Kurt

[kurte]

Quick update: new hserial syntax, but not sure of all of it yet.

enablehserial - command goes away…

sethserial - Does not appear to be the command any more not sure what the replacement is…

Kurt

[zenta]

Thanks for the info! Looks like there are some changes to be done on the Archer (Phoenix) code for the ARC-32 then.
Sounds like a good idea planning for eventual future processors.

[kurte]

OK I received some email from Nathan last night.

The new build has the new HSERIAL system as I pretty well knew…

@AcidTech

The new manual will have this documented. But hserial2 no longer exists. ENABLEHSERIAL etc are all gone. Still have SetHSerial2 command. If SetHSerial2 is used then the second UART will be enabled. Also SetHSerial is now SetHSerial1. This was supposed to be documented in the new manual before this release was made but I was pushed to get the release out.

So hserin and hserout have a new optional argument. If only SetHserial1 or SetHSerial2 is used it automatically uses the correct UART. If both are used there is an optional argument to specify uart1 or uart2. hserin 1,[blah,blah] hserin 2,[blah,blah]… Also on hserin the timeout and timeout label are reversed from previous versions. hserin tlabel,timeout. This was done because otherwise the uart argument could not be optional.

With this knowledge I am now able to get the Arc32 version of the phoenix code to compile again. Have not run it yet…

Kurt

[acidtech]

Just so everyone knows the new hserial syntax is all Kurtes fault. He convinced Dale we needed it.

[robotdude]

@Acidtech

Just so everyone knows the new hserial syntax is all Kurtes fault. He convinced Dale we needed it.

Bwwwwaaaa haaaaa haaaaa haaaaaa!