IDE Bug List: Atom v5.3.0.0 [Nov 28, 2006]

Introduction
This heading list will be heavily moderated. Post and discuss the potential bugs here, and we will compile a concise list in this sticky post. After defining the trouble, the information will be added here, and the original posts will be removed. Please restrict the posts to programming issues concerning the Atom, Atom-Pro 28 modules only.

The main difference in these IDEs is that all arguments are 32-bit instead of 16-bit. There is more information on the Basic Micro website.

Bot Board / Atom 28: IDE version 5.3.0.0

The pin number isn’t being properly handled in the ADIN command. In the mbasicadin.lib file(the directory should be C:\Program Files\BasicMicro Inc\BasicAtom IDE\system\MBasic14) you need to add the three lines of code that are marked in the ADIN_INIT subroutine to fix the problem. There should be a new update to the IDE in a week or so.

[code]_ADIN_INIT
clrf ADCON0 ; Reset ADCON0
bsf ADCON0,0 ; Enable A/D converter
movfw _ADIN_SETUP
_@BANK _WORK,ADCON1 ; Sel ADCON1 bank
movwf ADCON1&0x7f ; Load ADCON1
_@BANK ADCON1,_WORK ; Sel WORK bank

        _@CALL   _GETPIN      ;Add this line
        movfw   _STACK+1      ;Add this line
        movwf   _ADIN_PIN     ;Add this line
        
        clrf   _ADIN_WORK
        _@ADCHANNEL _ADIN0,b'00000000'
        _@ADCHANNEL _ADIN1,b'00001000'
        _@ADCHANNEL _ADIN2,b'00010000'
        _@ADCHANNEL _ADIN3,b'00011000'
        _@ADCHANNEL _ADIN4,b'00100000'
        _@ADCHANNEL _ADIN5,b'00101000'
        _@ADCHANNEL _ADIN6,b'00110000'
        _@ADCHANNEL _ADIN7,b'00111000'
        _@ADCHANNEL _ADIN8,b'00000010'
        _@ADCHANNEL _ADIN9,b'00001010'
        movfw   _ADIN_WORK              ; Get Channel
            iorwf   ADCON0,f            ; IOR ADCON0[/code]

Bot Board / Atom-Pro 28: IDE version 8.0.0.0

None.

When installing both versions of the Atom Pro IDE, one overwrites or somehow breaks the install of the other. This is a problem with the installer of the new IDE I believe.

The PULSOUT command still does not work and causes what is apparently a sort of core dump when my program is linked. it compiles file, but fails at the link stage. I just have a single PULSOUT command in my code where I am trying to read the PING sensor.

The problem seems to be in mbasicpuls.lib and the messages complain about Value of symbol “_pulsoutfinish” differs on second pass. This points to a spot right near the end of the pulsout code at a label called “_pulsoutfinish” where there is not much code.

Could it be real difficult to fix this problem and give us a patch? I would copy and paste the mesasges, but the IDE won’t allow me to do that. Sad Perhaps copy could be enabled for a later version of the IDE?

I wish I could provide more info, but this is the best I can do. I already sent this info off to Acidtech in e-mail as he requested.

8-Dale

I would like to post a feature request.

I would like to see the ability to be able to change font types used and there should also be a “default” button to set all settings back such as color, font type, size etc… Also, a RUN button would be nice, I keep hitting the compile button thinking Im going to run the code!

As for the bug issues, I’m fairly new so I don’t have many to report, excet the following:

1.) better syntax checking such as improper use of variable types. One example is trying to use Byte when WORD should be used. compile time should produce at least a warning.

2.) I am curently having problems with the flow control pin. This is something to look at also. I will post more detail as I find out more.

On the atom pro pulsin returns a value of 0 no matter what. I am using WIN XP and version 8.0.0

It seems to reset the atom if no time out is used and return 0 if one is used. The fix was to use 2 RCTime instuctions.

EDIT: not specific enough

Some of these issues I ran into several months ago so I don’t remember all of the details, but here are a few things that jump to mind:

  1. There is still a problem with the SQR command. I remember having to add an & 0x7fff to some code.

  2. The results of a divide by zero are different. I remember running into this when porting the Hex code.

  3. I believe I ran into problems getting ADIN to work on all 8 pins. I don’t remember now if it were the low pins that worked or the high pins.

  4. The Pulsin command at times reboots the processor. I believe that some have had better luck using RCTIME even though supposedly they are the same code…

  5. Is there a reason that data and read dont work on the Atom Pro 28?, likewise for NAP?

Requests:

  1. Have parameters mean the same thing on both Atom And Pro IDES. For example the sound durations should be the same. Not have one in milisconds and the other in microseconds.

  2. One thing I found frustrating porting code from Atom to Pro is sometimes the code compiles just fine, but the meaning has changed.
    I am trying to remember, but I think that was true with PULSIN.

  3. A little better control on which program is going to compile. If I load one source file and then another, it usually screws up which file is going to compile…

  4. More function parameter support. It would be nice if they were some form of type checking…

  5. Updated documents and examples. It would be nice to have examples showing how to use different interrupts. Likewise it would be nice to know if you can compile the PRO with C and C++ and where to get the tools. Also if you can somehow integrate your own code with the basic. (I am probably dreaming here).

Thats all for now
Kurt

I2C - Support for clock stretching would be really, really nice to have.

The I2C spec allows the slaves to hold SCL low if they need a small delay. This doesn’t happen with EEPROMs as such, but with microprocessor driven slaves, it can be an issue. I’ve seen this behaviour with Devantech I2C devices (SP03, CMPS03).

The current I2CIN implementation does not recognize the stretch and reads in the MSB while the clock is held low, which leads garbled data (and the LSB going AWOL). The Devantech site has some very good bitbashed sample code in C that supports this (for a PIC).

[edit]

For the wishlist: Whilst there is a header file for C projects, personally, I’d love it if there were a small C library for things like I2C, ADC and serial. Just saying…

Problem 5: There is no DATA command on the AtomPro because there is no builtin EEPROM on the AtomPro(eg can’t program an external eeprom from the bootloader. This is unlikely to change anytime soon. The Read/Write commands do work but on the AtomPro24 an eternal eeprom must be added(the Pro28 already has one on board).

Request.

  1. This has already changed some what. Most timing commands are in microseconds on the Atom(5.3.0.0) and on the AtomPro they are in .5 microseconds(8.0.0.0). I’m not going to make them match exactly because then you are defeating the point of the Pro(eg can do things faster).

  2. There will always be differences. AtomPro can do a lot of things better so the command functionality is going to be different. Thats just the way it is.

  3. In the Atom IDE which ever bas file has focus(usually the top file) is the one that will be compiled. In the AtomPro IDE whichever File/Project is in BOLD in the FileView Workspace is the one that will compile. To switch which will compile double click the File/Project in the FileView explorer to change it(the double clicked file/project will become bold).

  4. I added function parameters just because I could in a fairly simple way. Adding type checking to it isn’t going to happen soon and was noted in the documentation.

  5. Yes, we need better documentation. We’re working on it as best we can. As for C/C++ the AtomPro IDE already has C/C++ support built in. Just create a C/C++ project. Note that GCC for H8 does not have any high level libraries so almost everything has to be done from scratch(eg there are no serial commands so you have to bitbang them).

I’m going over the bugs listed above and will be releasing an update for 5.3 and 8.0 soon. The following are the bugs I’ve been notified of. If you(anyone) know of a bug not on this list then please post it. If I don’t know about it it isn’t going to be fixed.

Bugs in 5.3.0.0:
Pulsout command

Bugs in 8.0.0.0:
Pulsin command

Bugs but did not specify which compiler:
Sqr command

I will be updating the installers as well and will make sure they don’t conflict with older versions.

I’ll see how hard it will be to add this. I don’t want to bloat the commands or slow them down too significantly.

  1. I’ll keep it in mind but this is not an error. This is as you later say a warning at best. Type checking going from float to int or back is already implemented because in that case it’s a major conversion. Word to byte conversion should probably also be warned about(eg value being trucated) but I don’t think byte to word(eg small to larger) should need a warning.

  2. If you can give me more a specific example of this and possibly a sample peice of code showing the problem I can fix it but without something mkore concrete I have no idea where to look.

Thanks for the information, cann’t wait for the update!

Ok, that makes sense!

I understand and I do appreciate that the Pro is faster and more functional. That is why I like it. It is just that for me personally I would prefer that the same commands and parameters work the same way. Otherwise it makes it very easy to have problems when you convert your code and not realize why it is not working. That is why on some other platforms that had to add new Ex commands. to allow the new functionality to surface.

Thanks.

Thanks again. I will start to experiment with this. It would be nice if we could all share whatever support libraries we come up with.

This is on the Pro.

I was playing around with the C and C++ compiler and have a couple of suggestions. (All with version 8.0… Pro)

  1. The C/c++ compiler was not configured properly on my machine. The programs were there, but it did not set up the search path properly to find the pieces of the C compiler.

  2. When I close the IDE and come back. The Project I was working on does not reopen. Only the files that are outside of the Project reopen.

  3. If your current project is C/C++ it would be nice if you did a File/Open menu command, if the File type combo box was initiailized to the C/C++ files item.

Thanks again
Kurt

Usually, when you open a project or workspace in an IDE with support for projects/workspaces, all files that were open when you saved the project/workspace should open right where you left off. I don’t think this is the case with the Atom PRO IDE.

8-Dale

I completely agree, going from smaller to larger will not yeild any program errors and should be left alone, but where values can be truncated should produce a warning. In some cases of code development, variables get changed around, and one can easily change something that will cause a small value become a big one that will no longer fit.

type promotion is usually not a problem as long as you consider signed types and promote accordingly. type demotion typically flags a warning, especially if it is assigning a constant to a type of insufficient size.

assigning a signed constant to an unsigned variable frequently also flags a warning but without someway to cast the type I’m not sure this is a good idea to add this warning unless you can disable specific warnings somewhere.

Ok! Nathan has finished the new releases. He’s uploaded them but they still need to update the website with the links. They’ll be removing the 8.0.0.0 and 5.3.0.0 beta links and puting up 8.0.1.0 and 5.3.1.0 release links. 7.2 and 5.2 will remain up for backwards compatibility but they will not be releasing bug fixes for those versions as 8.0 and 5.3 are the bug fixed versions for all intents. I will follow this up with another announcement when the links are added. How’s that for action? :wink:

Brilliant. Chalk me up as a downloader…

No chance of a C library is there? :wink:

Wow! :open_mouth:

Yessssss!

I’ll let you know after I have had a chance to use the new releases for awhile. :slight_smile: I am much more optimistic (albeit cautiously so) now and hope for more rapid problem resolution in the future. :smiley:

8-Dale

No chance of a C library anytime in the near future unless some one wants to volunteer. If so we’ll need to execute an NDA so you can get access to our assembly code library. I started working on a C/C++ compatible library a long time ago but never got a chance to really get going. Basically I was creating a wrapper for the assembly code of the HBasic library. That would reduced the amount of work required significantly and keep the syntax similar across both but I never had enough time to really sink my teeth in.

Also the links may take a little longer to put up. I’m going though the manuals for 5.3 and 8.0 and trying to catch any changes that aren’t in them. For now you can get the new IDEs with these direct links but hold off on any techsupport calls until I’ve had a chance to finish updating the manuals.

www.basicmicro.com/downloads/software/B … p_8010.exe
www.basicmicro.com/downloads/software/B … p_5310.exe

The main updates were the pulsin and pulsout commands and sqr command. The registry keys will also no longer interfere with previous releases. AtomPro40+ support was added to the AtomPro IDE and Atom18(interpreter chip based on the 16F88) has been added to the Atom IDE.

The other primary update was Hservo. Processor usage is now down even more. To calculate the processor usage use the formulas below.

AtomPro24 and 28
50hz refresh, 4 servos/group
worst case
((528groups) + (106servos)) * refresh / 16000000
best case
((424groups) + (106servos)) * refresh / 16000000
AtomPro40+
50hz refresh, 4 servos/group
worst case
((536groups) + (110servos)) * refresh / 20000000
best case
((432groups) + (110servos)) * refresh / 20000000

A group is upto 4 servos so even if you are only using one servo you still have the over head of at least 1 group. The default number of groups is 5 for AtomPro and 8 for AtomPro+ modules. To change the number of groups compiled for add this line to your program:

HSERVO_GROUPS con #

where # = the number of groups you want to support.

Using the calculations above you can see even using 5 groups(eg upto 20 servos) and assuming all 20 servos are actively moving around using the speed argument(worse case) the maximum processor usage is:

(((5285) + (10620)) * 50) / 16000000 = 1.4875%

Assuming you drive 12 servos(eg: a hexapod) and leave the groups default to 5 you get 1.2225%.

If you adjust the groups to match what is required(3 groups for 12 servos) you get 0.8925%

One thing to note is that each group only handles certain pins. If you only use 1 group only P0 through P3 can be used for hservo. If you use 3 groups P0 though P11 can be used and so forth and so on.

Note the command does allocate itself 256bytes of ram. Also the refresh rate is adjustable but I’m not going to go into that right now unless someone really needs to be able to adjust it.

Signalling range for the AtomPro is still ±24000(eg 16mhz1.5ms) and on the Pro40+ it is ±30000(eg 20mhz1.5ms). There is a slight range limit when using 7 or 8 groups but even when using 8 groups the positive range is .995ms. Negative range is still the full 1.5ms evne in these cases

Of course none of that matters until we start shipping the Pro40+. I’m currently the only lucky bastard with his grubby hands on one. :slight_smile: