Do the MIOS OS bundles compile for all you guys?

[Jidis]

I've been trying to learn my way around the app tweaking/assembler thing to suit my hardware and LCD and I've been randomly changing different things to see how they looked.

I've noticed that MIOS 1.8 and 1.7 throw an MPLAB error at me on compile attempts. The minimal error log I've been able to get is a complaint about the expected "END" line in the main file, and they never actually compile. This is with no changes at all to the files, and it errors in 7.2(?) under XP&2K and a version 6.x under 98SE. The precompiled hex file appears to work just fine.

Is there a pref or something I'm missing?

-George

[pilo]

I got the same problem 2 weeks ago, and I can't remember what did I do to make it works :-[

Something really simpe!! let me look again.

[illogik]

hi; just a quick guess; check if the path name/lenght isn't too long

cheers, marcel

[Jidis]

check if the path name/length isn't too long

Yeah, I figured that out after my first few MPASM fights ;)

I usually keep all the stuff I'm playing with in a "MIOSAPPS" folder in the root with nice short names for all the individual folders.

Newsflash! I think I've found it. I took the "END" label all the way past a bunch of empty lines to line 129 (where MPLAB listed the error) and it compiled (at home anyway). I assume that means that the source file needs to be a specific length?? 

                                                     -George

Error[129]   C:\SRC\MAIN.ASM 2 : Expected (END)

[pilo]

it's something else... I really can't remember how I fix it  :-[

[Jidis]

BTW--

Being as the original unmodified source will error like this for both 1.7 & 1.8, is it possible that he's using something other than Microchip's compiler?

When I first got into this stuff, I was wondering if there was something (source editor) which provided direct links from the listed variables, functions, etc., to their original definitions,etc. Like, in a big multiple .h/.inc project, when you see a name being used in the code, is there an easy way to figure out where it was created, so you can see what it actually does? I've now found and used the "find in project files" item, but MPLAB doesn't really know the difference between the creation and the use of the files, and you have to select/copy the text, pull the find dialog, paste it in, go to the output window and look for it. I guess that's as good as it gets.

-George

PS- (Pilo) That last post did indeed fix it, it was in the source file length :)   

[pilo]

I fix it without moving the END function...

the file seems to be the same! lol I can't remember what was the problem...

[Jidis]

the file seems to be the same! lol I can't remember what was the problem...

Oh, the magic of MPASM! :D

I've had places where I change something, it ruins the compile and the error file blows up like a balloon. Then, nothing I do could please MPASM, including an undo of the one or two minor changes which ruined the file. I'd have to revert back to a backup copy. I think I've also had it complain when the processor was specified by the pulldown, but it was already specified in the source.

The pathlength issue is a bit sloppy by itself. You would think a company who developed microprocessors and dealt in assembler, would observe better "error reporting" habits than that, but they've provided us with lots of neat toys, so I guess we shouldn't complain. ;)

-George   

[pilo]

hehe I run MPASM is a dosemu window under linux :) DOS version so. GPASM can't compile MIOS because it doesn't handle MACRO correctly....

But I'm sure I correct this "END expected" error, and it was so dumb that I forget it....  ???

[Synapsys]

Hi all,

Pilo is correct about GPASM not handling some macros correctly. Specifically, the construct of passing an instruction such as "goto someLable" as an argument to the macro is not supported by GPASM. In order to alleviate this problem I decided to expand the macros IFSET, IFCLR, BIFSET, BIFCLR, IFNEQ, IFLEQ and IFGEQ manually throughout all the MIOS source code. This was of course a BIG job since these macros are used everywhere. And, doing it manually was also very prone to mistakes. As a result, I wrote a small C# application that does the job for me. The end result was a set of MIOS V1.8 source code modules that work fine with GPASM. So now I use GPASM for all my PIC work. Here is an example of the output from my program:

;; *** macro fix *** BIFSET MIOS_MPROC_SYXSTATE, MIOS_MPROC_SYXSTATE_MYSYSEX, BANKED, rgoto _MIOS_MPROC_Handler

btfsc MIOS_MPROC_SYXSTATE,MIOS_MPROC_SYXSTATE_MYSYSEX,BANKED

rgoto _MIOS_MPROC_Handler

I left the original line with the macro in the code but commented out so I could be sure that my expansion of the macro was what I expected it to be. I am sure that a perl script could be written to do the same thing but I am not very experienced with perl so I chose to write an application to do the job.

It is too bad that GPASM does not support this type of macro construct as it is, in my opinion, a very useful one. Maybe someone with too much time on thier hands will add this capability to GPASM in the future.

It is nice to use GPASM for the OS as well as for applications since it is required when using SDCC anyway.  :)

Regards,

Synapsys

[pilo]

Hi Synapsys!

I try to mod the gapsm yacc source code... but the yacc source code looks weird to me :) (to much C instr in it). Compiler was one of my courses last years :-[ but to much theory and not enough practice maybe.

[Synapsys]

Hi Pilo,

I can understand that  ::)

I really don't want to try modifying the GPASM source since (even if I was successful) I would have a non-standard version and upgrading would then become a painful thing. So for now I can live with changing the macros in the MIOS sources. I only have to do it once each time a new MIOS release happens. :)

[pilo]

I would have a non-standard version and upgrading would then become a painful thing.

Not if you send your patch to the GPASM group :) then it would be available to everyone.

I don't really understand why this macro feature is not correctly handle by gpasm, and I was quite disappointed by the complexity of their lex/yacc sources.

[Jidis]

Synapsys,

If you don't mind me asking (or changing the subject)-

What exactly is Thorsten's "rgoto" instruction? I couldn't find it in any instruction set listings or web searches.

-George

[raphael]

rgoto   MACRO   label

        bra     label

        ENDM

Where is it defined? Like all macros in macros.h ;D

[Jidis]

Raphael,

Thanks!

I had sort of assumed there was more to it than that, and that it was a standard since it looked like the regular goto.

-George

[Synapsys]

The RGOTO macro is a relative branch that acts exactly like the GOTO instruction except is has a limited range for the target address. Bascially, the BRA instruction says to jump unconditionally to the current address (PC register) plus or minus up to 1024. Actually, the range is -1024 to +1023. Why use this rather than a GOTO instruction? The answer is simple. The BRA instruction takes up only 1 word of memory while the GOTO instruction takes up 2 words. We all know that in the world of micro-controllers code memory is at a premium so anywhere it can be saved is a good thing to do.  ;)

Keep in mind that the BRA instruction is not any faster that the GOTO instruction, they both takes 2 cycles.

Thorsten's definition of the RGOTO macro makes the code clearer to read. It means a Relative GOTO which is more obvious as to what it does  than a Branch to most people.

Regards,

Synapsys

[Jidis]

Synapsys,

Thanks for the additional info! When I ran into them, I had assumed that all the macros and stuff had to show up in the 1st column. Then, to make it more confusing, the web searches for it turned up rgoto's from a bunch of "non-PIC" code. I'm still new to PIC assembler and my only paper book is more or less on an "elementary" level. I run into lots of stuff in TK's programs that it doesn't cover and I have to go looking for.

If any of you have any suggestions on a more thorough current book, which covers a broader range of info, I'm anxious to get one. The one I started with was "Easy Microcontrol'n" by Square One, and then it was straight to source comments and datasheets. ???

-George

[jackchaos]

"The minimal error log I've been able to get is a complaint about the expected "END" line in the main file"

Were you able to find out why you couldn't compile with that error? I get the same thing without any changs to the source.

[Jidis]

Jack,

Yes (I think).

It's way back at the beginning of this thread. I think it was just pushing the "end" line to the line number that MPASM wanted (using blank lines).

-Take Care

[jackchaos]

I was able to get pass "error[129] END". The problem has to do with UNIX and WINDOWS carridge return differences.

I use notepad++ which has a "CONVERT TO WINDOWS" feature.

Now that I got pass the "error[129] END", the asm compiles with a messload of warnings. Is this normal?

My main.ERR file has 2700 lines of errors..

[raphael]

Now that I got pass the "error[129] END", the asm compiles with a messload of warnings. Is this normal?

My main.ERR file has 2700 lines of errors..

You already found the solution ;). Convert all the .h and .inc files to DOS format.

Begin with the p18f452.inc file(this file causes most of the errors)!

Raphael

[jackchaos]

Yes. I went back and went through them after posting this. Only 3 or so files were in unix format, the rest were fine. It looks like TK might have gone in and made a few last minute changes in a different editor with different newline settings.

Back to work!

Thanks!