IsoMax syntax errors

[brian]

So I'm about to completely abandon IsoMax/IsoPod for some other controller in which I can use a regular C-compiler and RTOS. I feel like I've given IsoMax a pretty fair amount of effort. I fully admit that I'm an IsoMax/IsoPod newbie, but I am not an inexperienced programmer. It seems to me that the error reporting when trying to develop an IsoMax app is worse than nonexistent. it's actually misleading. I've posted several times with problems that that turned out to be mostly mistakes on my part, but I also feel that the documentation and error reporting are less than stellar. I've had some limited experience with Forth in the past, and understand that it is close to assembly language than a high level language, but an assembler at least provides some decent error reporting.

So, here's a snippet of code that's been frustrating me. As with most programming efforts, I'm sure it's a stupid newbie mistake, but I could sure use some better clues. This is a stripped-down version of a larger app that I was developing incrementally, then broke when I added a piece that seemed nearly identical to working pieces.

Since this posting is going through a moderator, I don't even care if it gets posted. If I'm just not getting it, what am I missing?



DECIMAL

32767 CONSTANT AIEL_PERIOD

AIEL_PERIOD PWMA1 PWM-PERIOD

7504 CONSTANT SERVO_NEUTRAL_PWM

VARIABLE Raw

VARIABLE AielPWM

LOOPINDEX TimeOutCount

: servos_neutral SERVO_NEUTRAL_PWM PWMA0 PWM-OUT
SERVO_NEUTRAL_PWM PWMA1 PWM-OUT ;

MACHINE FBW

ON-MACHINE FBW

APPEND-STATE INIT_STATE

APPEND-STATE CHECK_AIEL_DONE
APPEND-STATE PROCESS

IN-STATE INIT_STATE CONDITION TRUE
CAUSES GRNLED OFF YELLED OFF REDLED ON

servos_neutral

TA0 SET-PWM-IN

0 TimeOutCount START
100 TimeOutCount END
1 TimeOutCount STEP

0 Raw !

0 AielPWM !

IN-STATE CHECK_AIEL_DONE CONDITION TA0 CHK-PWM-IN DUP Raw !
CAUSES GRNLED OFF YELLED ON REDLED OFF
Raw @ DUP AielPWM ! PWMA0 PWM-OUT
TA0 SET-PWM-IN
TimeOutCount RESET

THEN-STATE PROCESS TO-HAPPEN

IN-STATE CHECK_AIEL_DONE CONDITION TimeOutCount COUNT
CAUSES GRNLED OFF YELLED ON REDLED OFF

THEN-STATE PROCESS TO-HAPPEN

IN-STATE PROCESS CONDITION TRUE
CAUSES REDLED ON

THEN-STATE CHECK_AIEL_DONE TO-HAPPEN



The results of pasting this into a freshly reset system.



IsoMax V0.6
OK
OK
DECIMAL OK
OK
32767 CONSTANT AIEL_PERIOD OK
OK
AIEL_PERIOD PWMA1 PWM-PERIOD OK
OK
7504 CONSTANT SERVO_NEUTRAL_PWM OK
OK
VARIABLE Raw OK
OK
VARIABLE AielPWM OK
OK
LOOPINDEX TimeOutCount OK
OK
: servos_neutral SERVO_NEUTRAL_PWM PWMA0 PWM-OUT
SERVO_NEUTRAL_PWM PWMA1 PWM-OUT ; OK
OK
MACHINE FBW OK
OK
ON-MACHINE FBW OK
OK
APPEND-STATE INIT_STATE OK
OK
APPEND-STATE CHECK_AIEL_DONE OK
APPEND-STATE PROCESS OK
OK
IN-STATE INIT_STATE CONDITION TRUE
CAUSES GRNLED OFF YELLED OFF REDLED ON

servos_neutral

TA0 SET-PWM-IN

0 TimeOutCount START
100 TimeOutCount END
1 TimeOutCount STEP

0 Raw !

0 AielPWM !

IN-STATE CHECK_AIEL_DONE CONDITION TA0 CHK-PWM-IN DUP Raw !
CAUSES GRNLED OFF YELLED ON REDLED OFF
CAUSES ? MSG# 19
Raw @ DUP AielPWM ! PWMA0 PWM-OUT OK
TA0 SET-PWM-IN OK
TimeOutCount RESET OK
OK
THEN-STATE PROCESS TO-HAPPEN
THEN-STATE ? MSG# 17
OK
IN-STATE CHECK_AIEL_DONE CONDITION TimeOutCount COUNT
CAUSES GRNLED OFF YELLED ON REDLED OFF

THEN-STATE PROCESS TO-HAPPEN OK
OK
IN-STATE PROCESS CONDITION TRUE
CAUSES REDLED ON

THEN-STATE CHECK_AIEL_DONE TO-HAPPEN OK
OK

[nmitech]

The program ram memory is limited. I would suggest to load it into the program flash memory. Simply add EEWORD for every constant, variable, word, and state-machine. For example,

DECIMAL

32767 CONSTANT AIEL_PERIOD EEWORD

...

...

VARIABLE Raw EEWORD

...

LOOPINDEX TimeOutCount EEWORD

: servos_neutral SERVO_NEUTRAL_PWM PWMA0 PWM-OUT
SERVO_NEUTRAL_PWM PWMA1 PWM-OUT ; EEWORD

MACHINE FBW EEWORD

ON-MACHINE FBW

APPEND-STATE INIT_STATE EEWORD

...
...

IN-STATE INIT_STATE CONDITION TRUE
CAUSES GRNLED OFF YELLED OFF REDLED ON
...
...
THEN-STATE PROCESS TO-HAPPEN IN-EE
...
...


Similar to what you did on your previous post,
http://www.newmicros.com/discussion/showthread.php?t=6895

[brian]

First off, sorry for the whining. The post represents my level of frustration with this. IsoMax and the IsoPod hardware offer a really nice mix of features for my project, but debugging IsoMax is tough due to a lack of meaningful and consistent errors.

As for your suggestion about ram, what's aggravating me is that this program is a stripped down version of one that was at least loading and running. I was originally trying to handle three servo channels. The code would load and run, but I was getting some severe glitching that I assumed was a timing issue with my code. To simplify debug, I at first just commented out two channels, and the code for the remaining channel started giving me this error. To simplify even more, I stripped out all the commented code in case it was causing an issue with the download. The code I posted here is a subset of the original compiling code, that should be in every way identical. Will probably end up fiddling around with it some more to see if I can figure out what's going on. Interestingly I still get the error when I just paste it in in pieces, which is a little different than previous problems like this. The error does at least seem to be very consistently reproducible.

[brian]

After thinking about this some more, your suggestion about RAM does bring up another possibility. Perhaps I just have some flakey RAM. That would certainly explain why identical bits of code fail when the code around it is removed or changed. Perhaps I can come up with a memory test for the program RAM that runs in flash? Does anything like that already exist? If it's bad ram used by the IsoMax kernel, I'm probably hosed unless I can do something in Forth or assembly that runs completely standalone in program flash.

If I do have bad RAM, not sure what I could do about it though, since it's all internal to the CPU chip. To replace the part myself, I suppose I would need a way to flash the IsoMax code via the JTAG interface.

[nmitech]

OK, I looked again into your code and i found that you defined one transition crossed into the other. According to the appnote below, you must end one transition before you can start the other. Please see page 11 & 12 from the appnote below,

http://www.newmicros.com/store/product_manual/AdvancedProgramming.pdf

Your code,

IN-STATE INIT_STATE CONDITION TRUE
CAUSES GRNLED OFF YELLED OFF REDLED ON

servos_neutral

TA0 SET-PWM-IN

0 TimeOutCount START
100 TimeOutCount END
1 TimeOutCount STEP

0 Raw !

0 AielPWM !

/ missing THEN-STATE ???? TO-HAPPEN here

IN-STATE CHECK_AIEL_DONE CONDITION TA0 CHK-PWM-IN DUP Raw !
CAUSES GRNLED OFF YELLED ON REDLED OFF
Raw @ DUP AielPWM ! PWMA0 PWM-OUT
TA0 SET-PWM-IN
TimeOutCount RESET

THEN-STATE PROCESS TO-HAPPEN
...
...

[brian]

Oh. I see there's an enormous difference between the size of User Program RAM and User Flash RAM. I will try putting the code in the flash when I get a chance. Perhaps my code has been bumping up into the Kernel Program Ram, and sometimes I just get lucky that it doesn't completely crash.

[brian]

Note on the memory map says that the Kernel Program Flash is only used for flashing, so I guess my previous post does not explain the problem. I'll try to determine where my code ends anyway, and also try putting it in flash.

[brian]

I compiled the code into flash and didn't get any errors. Code seems to be running (don't have a scope hooked up). Lesson learned. I guess the rule-of-thumb is don't use the program RAM for anything more than testing small chunks of code, and get used to working with minimal error checking.