Atom Pro IDE ver 8.0.1.3 BETA link and BUG LIST

A week from next Monday I will be back from CES and will have time to address any bugs in 8.0.1.3. So far I am only aware of:

  1. DTMFOut being broken
  2. Vista complaining about the IDE not being digitally signed.

I am asking that anyone with a different bug post a discription of the bug and if possible sample code that produces the bug before I get back from CES so when I get back I can take care of them.

Ok, I updated it to run on my brat:

I just changed the assigns for the servos and the number of servos…

[code]’ Servo Configuration
RightHipV con P11
RightHipVOffs con 0

RightKnee con P10
RightKneeOffs con 0

RightAnkle con P5
RightAnkleOffs con 0

LeftHipV con P8
LeftHipVOffs con 0

LeftKnee con P7
LeftKneeOffs con 0

LeftAnkle con P6
LeftAnkleOffs con 0

’ We need two servo groups (P0 - P7)
HSERVO_GROUPS con 4[/code]

It did not fault, but it acted real strange! Most of the servos jerked to some very far point and then moved slowly back to the zero point, where they stayed. Maybe some type of initialization is needed for the first move? It appeared to work like normal if the speed was set to 0. Maybe you need to do that first before you do anything special as it does not know where the servos are… Just a thought

I have seen this behavior also. I just have my servos on the first two groups.

I will have to check this out when I reboot to Windows next.

8-Dale

I get a compile error with nested #ifdef commands. In particular in this segment the code compiles properly if SEETRON is defined and USEHSERIAL is defined. If USEHSERIAL is not defined, the compiler errors on the second #endif

#ifndef SEETRON ; Set the backlight to low #ifdef USEHSERIAL HSerout [0x7C, 0x80] ; 124, 128 - Off #else Serout LCDPIN, LCD_BAUD, [0x7C, 0x80] ; 124, 128 - Off #endif #endif

Kurt

Thanks for pointing this out. I found this the other day and have fixed it. I also made several other fixes in the #conditionals. At this point I think all the #conditional compiling directives work as they should. The fixed version will be available by sometime Monday.

Thanks. Fixed.

The first move with hservo should be with 0 speed(eg instant). If you set a speed other than 0 then the hservo system will try to move the servos from an unknown position to the new position with interpolation. This is only necessary on the first move. I ussually have a hservo command that zeros each of my servos before my main loop because before the first move there is no previous position information.

I’m finishing up the update. I’m not able to fix the Vista message box popup at this time. I still have no idea why it is complaing but doesn’t complain about the Atom IDE. I’m also still waiting for my signature certificate so I can’t sign the exe yet.

I’ve only got DTMF to fix at this point so it looks like a Monday release will be no problem. Look in this thread for the updated link.

Probably a documentation issue:
I tried adding a WaitHServo command to my program and I received compiler errors. I finally tried HServoWait and it then compiled

Here is the link to the new release.

EDIT: use the 8015 on the next page…

www.basicmicro.com/downloads/software/B … p_8014.exe

And yes the HSERVOWAIT command is a documentation errata not a compiler issue. The manual says WAITHSERVO.

Early. :slight_smile: Nice Work.

I donloaded it and so far it appears to work.

There still appears to be a problem with the Swap Command.

[code]iCnT1 var byte
iCnt2 var byte
tb var byte
iOutLast var sword
iOut var sword

LCDConvertNumToString[iOut]
if iOut < 0 then
LCD_String(0) = “-”
iOut = -iOut
iCnt1 = 1
iCnt2 = 1
else
iCnt1 = 0
iCnt2 = 0
endif

do 
	iOutLast = iOut
	LCD_String(iCnt1) = "0" + iOut // 10
	iOut = iOut / 10
	iCnt1 = iCnt1 + 1
while (iOutLast >= 10)

LCD_String(iCnt1) = 0
iCnt1 = iCnt1 - 1
	
while (iCnt1 > iCnt2)
	;swap LCD_String(iCnt1), LCD_String(iCnt2)
	tb = LCD_String(iCnt1)
	LCD_String(iCnt1) = LCD_String(iCnt2)
	LCD_String(iCnt2) = tb
	iCnt1 = iCnt1 - 1
	iCnt2 = iCnt2 + 1
wend
return

[/code]
In the above code if I use the Swap command instead of the three lines below it to do the swap, the processor reboot.

My PWM intercept code with intercepting the six channels using WKP interrupt, TimerA (ASM), now fails to run properly if I enable HSERVO.

On the 8.0.1.3 I had the Rover running around the room, when I intercepted the PWM signals, then generated the coorsponding HSERVO command for the two motors. I made some minor changes and recompiled using 8.0.1.4 and it no longer ran and I noticed the LCD did not initialize properly.

I took the earlier version of the program that simply displayed the pulse widths on the LCD and it compiled and ran fine. When I added the ENABLEHSERVO command to this program the LCD (on P15) did not initialize properly.

I will try to localize more but I have company coming…

It appears like the HSERVO code is broken in the new release. I tried recompiling the TV Brat code and run it on my BRAT. I am not sure if I got all of the servos plugged back into the right locations yet (after trying to debug LinuxGuys problem). But with 8.0.0.0 it compiled and the legs sort of worked (again not sure all plugged back in properly). When I hit buttons on the TV remote it tries to do a move…

Tried recompiling with new release and the servos are not doing anything.

Kurt

Forgot to check the SWAP command though I thought I already fixed it. Sorry.

As for the other, I tested the Brat/IRPD system which uses both WKP and TimerA interrupts and had no problems. Please narrow this down a little and post sample code so I can look at it. Also a little more description of what it should be doing and what it is actually doing along with the sample please.

Note: The above is for Kurte’s first message about 8.0.1.4. I was posting this as he added his second message.

Something is wrong on your end then. I took the Brat code(directly from the Brat/IRPD thread, cut and paste) and programmed the AtomPro without changes and the brat ran as expected. The remote worked. The servos worked. Check your power supply. If you don’t have enough power you will get nothing or you may get jerking because the AtomPro is constantly resetting for lack of power.

I just double checked the SWAP command using this code:

[code]temp1 var long
temp2 var long

temp1 = 3
temp2 = 72
main
swap temp1,temp2
goto main[/code]

I ran this in debug mode and had no problems. No resets and the two values swapped correctly everytime through the loop. I’m going to try taking the stub code you posted and get it to work. In the future please supply a sample that is a whole program by itself to test with. A stub of a program that won’t compile or run properly by itself is basically useless because I have no way of knowing what you are doing before you call this subroutine.

Please check that you actually installed 8.0.1.4. Also did you uninstall the old version(s) first because I’m not seeing your problems at all.

No I did not uninstall. Will try that and see if that resolves things.

Thanks
Kurt

I made this simple program from your subroutine and added some serout statements so we can see what it happening.

[code]LCD_String var byte(10)

serout s_out,i9600,“Starting”,13]
main
gosub LCDConvertNumToString [1234]
goto main

iCnT1 var byte
iCnt2 var byte
tb var byte
iOutLast var sword
iOut var sword

LCDConvertNumToString[iOut]
if iOut < 0 then
LCD_String(0) = “-”
iOut = -iOut
iCnt1 = 1
iCnt2 = 1
else
iCnt1 = 0
iCnt2 = 0
endif

do
iOutLast = iOut
LCD_String(iCnt1) = “0” + iOut // 10
serout s_out,i9600,“Creating:”,str LCD_String\10\0,13]
iOut = iOut / 10
iCnt1 = iCnt1 + 1
while (iOutLast >= 10)

LCD_String(iCnt1) = 0
iCnt1 = iCnt1 - 1

while (iCnt1 > iCnt2)
swap LCD_String(iCnt1), LCD_String(iCnt2)
;tb = LCD_String(iCnt1)
;LCD_String(iCnt1) = LCD_String(iCnt2)
;LCD_String(iCnt2) = tb
iCnt1 = iCnt1 - 1
iCnt2 = iCnt2 + 1
wend

serout s_out,i9600,“Finished:”,13]

return [/code]

If you run this you will see the reset is happening at the return statement. That tells me something is trashing the return address. If I change your code to this:

[code]LCD_String var byte(10)

serout s_out,i9600,“Starting”,13]
main
gosub LCDConvertNumToString [1234]
goto main

iCnT1 var byte
iCnt2 var byte
tb var byte
iOutLast var sword
iOut var sword

temp1 var long
temp2 var long

LCDConvertNumToString[iOut]
if iOut < 0 then
LCD_String(0) = “-”
iOut = -iOut
iCnt1 = 1
iCnt2 = 1
else
iCnt1 = 0
iCnt2 = 0
endif

do
iOutLast = iOut
LCD_String(iCnt1) = “0” + iOut // 10
serout s_out,i9600,“Creating:”,str LCD_String\10\0,13]
iOut = iOut / 10
iCnt1 = iCnt1 + 1
while (iOutLast >= 10)

LCD_String(iCnt1) = 0
iCnt1 = iCnt1 - 1

while (iCnt1 > iCnt2)
temp1 = LCD_String(iCnt1)
temp2 = LCD_String(iCnt2)
swap temp1,temp2
;tb = LCD_String(iCnt1)
;LCD_String(iCnt1) = LCD_String(iCnt2)
;LCD_String(iCnt2) = tb
iCnt1 = iCnt1 - 1
iCnt2 = iCnt2 + 1
wend

serout s_out,i9600,“Finished:”,13]

return [/code]
then the reset goes away. This tells me the problem is not the swap command but arrays being used with the swap command. Now that I have that I can fix the problem and it also explains why I never saw the problem before. Also it points out why getting peice of code that show the problem(and only shows the problem) is so very helpful.

Let me know if that fixes the HSERVO problem. Also what power supply/battery amp rating are you using?