Flowcode v4.2 Beta Testing

[Benj]

Hello Wolfgang

C code icons insert the C code into that particluar macro for example into the main or into your sub macro.

The supplementary code window allows code to be placed outside of functions therefore allowing you to define your own C functions or global variables etc.

Strange about your LCD and also that the compile to chip did not work. I guess this is still a configuration problem though we will be able to confirm when we release the updated version of the HITECH compatible v4.2 which will allow the embedded configurations to work correctly.

[saschech@gmx.de]

Re: Flowcode v4.2 Beta Testing
by steve on Fri Oct 09, 2009 1:07 pm

Unfortunately, the value of local variables cannot be viewer in ICD mode. You will need to use a temporary global variable to hold their values.

The programming times you show seem very strange. Are the programming times for the whole compilation process, or just for using PPP to get the code into the chip?Steve Tandy,
Matrix Multimedia Ltd.
steve

Posts: 1590
Joined: Tue Jan 03, 2006 3:59 pm
Location: Matrix Multimedia Ltd.
WebsiteTop
--------------------------------------------------------------------------------

Re: Flowcode v4.2 Beta Testing
by saschech@gmx.de on Fri Oct 09, 2009 1:34 pm

Hello Steve

The time is "just for using PPP to get the code into the chip",
The compiling time is 15 sec (I7 cpu 950) ; *.fcf = 121kb >> *.hex = 31 kb

Hello Steve
You have no answer?

Regards Wolfgang

[Steve]

It is slow, and I will look into improving it at some point.

[saschech@gmx.de]

Hallo Benj

The hi-tech compiler work now ok with out the "dummy-macro" and "supplementary code " .
If i want compile to chip,all compiler and programmer say return = 0 ,but the real hardware do not work.
If i send the same hex-file via MPLAB > PICKit3 ("config set bit in code" is mark) ,the hardware works 100% ok.

I modify my code with a "rb2_int macro".If i put in the macros "anz_clear and "anz_text" the compiler show returncode = 1
I put in the both macros in "Haupt" ( jou can show between The !!!!!! mark) returncode = 0

Use the boostc-compiler both "errors" are not present .

The hex-code , compile with hi-tech is go from 37kb to 25kb , i think is a lot of memory save.
Regards Wolfgang

[saschech@gmx.de]

Hello Benj

Thank jou for the "great response" for my problem !!!!!!!!!

Regards Wolfgang

[Benj]

Hello Wolfgang

Many apologies I think your post must have been missed. I have just tried to replicate your problem and I am also getting the return code of 1 when moving the macro calls into the interrupt macro. Your program is quite large and I don't want to have to start digging through it. Do you have a replicatible means of causing this problem or is it more that this program has a non compilation problem for an unknown reason.

The compiler is stating that the problem is as follows, Is this what you are getting?

C:\Users\Ben\AppData\Local\Temp\s3tc.: 11249: (845) symbol "u9927" defined more than once
...
(908) exit status = 1

I will try and find out why it is generating this message as the u9927 is not declared in C.

[Benj]

Hello Wolfgang

The compiler manual states that this compilation error points to the following type of problem though I can find no occurrence of this in the C code file.

symbol "*" is defined more than once in "*" (Assembler)
This symbol has been defined in more than one place. The assembler will issue this error if a symbol
is defined more than once in the same module, e.g.:
_next:
move r0, #55
move [r1], r0
_next: ; oops -- choose a different name

[Steve]

That symbol name does not look like anything which Flowcode produces, so I think it is an error with the compiler itself.

Wolfgang - can you please confirm which version of HI-TECH you are using?

[saschech@gmx.de]

Hello Steve

I use "HCPIC18-pro-9.63PL3".

Regards Wolfgang

[Benj]

Hello Wolfgang

I have been through the compiled files as well as the precompiled files by playing with the compilation settings and cannot generate a file that even mentions the error reference.

Therefore I think that the problem is internal to the HITECH compiler. Hopefully there should be a fairly simple workaround, though I dont know what this is at the moment.

When you say you compiled with MPLAB was this taking the C code from Flowcode or was it simply programming using MPLAB? EDIT: I see you simply sent the hex file using MPLAB. hmm.

[Benj]

Hello Wolfgang

I have had a dig with your program and can now see why your program is not compiling with HITECH,

Basically the problem is due to non recursive code. You have macros that are called from the main program loop and the interrupt service routine. EG the main program could be halfway through the routine when the interrupt kicks in. This repeats the routine using the same variables and when it leaves the routine and umps back to the main loop the variables are left corrupted by the interrupt.

You must ensure to use different routines in your main and interrupt routines. The best way to do this is to create a buffer that is serviced in the main program loop. Then when it comes to the interrupt you can simply drop data in to the buffer and increase a size counter. This way nothing is corrupted and your program compiles.

The error message from the compiler isn't great but I can now see what it means by "defined more than once"

I went through your example's 'main loop' deleting the calls to the macros used in the interrupt and as soon as I got the last one the program compiled correctly.

[Steve]

Wolfgang,

Interrupts are a common problem for lots of our users. You should look at the following article on our knowledge base:

http://www.matrixmultimedia.com/mmforum ... =26&t=6390

And for emphasis, I will repeat some of it here:

Interrupt service routine tips:
It is essential that the interrupt service routines are kept as short as possible. Most only require a small amount of data to be transferred, or a simple calculation to be carried out.

Complex or potentially time consuming operations should be carried out in the main program. These include:
• Calling most other component or user macros (LCD, ADC, Communications, etc.), except for basic I/O operations
• While loops - unless the escape condition can be guaranteed within an acceptable period.
• Connection points - unless the flow of the program is understood for all possible conditions.
• Delays (other than very quick microsecond delays)

[Benj]

Many hanks for everyones help on this.

Beta testing for Flowcode PIC v4.2 in now closed.