Matrix user forums

Hi all,

Anyone know where I can find (or knows) what the above code means when I 'compile the flowchart to HEX', prior to 'compiling to 'chip'?

Curious because an hour or so previously, I compiled an RS232 Tx flowchart and an RS232 Rx flowchart to chips with no problem then the very next time, they both f'ailed' as noted!

They run quite happily in simulation.

There is only one C code item directly after 'BEGIN' (osccom=0x60; to set the internal 16F88 oscillator) but it wasn't a problem first time around and to double check we tried compiling with it removed but it still came up with the same code.

Any info or list of codes would be truly helpful.

Thanks in anticipation,

Chris

Hi Chris

Can you post your flowchart for someone to have a lool at?

christoph wrote: There is only one C code item directly after 'BEGIN' (osccom=0x60; to set the internal 16F88 oscillator)

Is that a typo only in your post or on your flowchart as well?
Should be Not Martin

Hi Martin,

Type error just in the posting - sorry.

While your there, is it possible for you to show me how to increase the 6 off switch/LED arrangement to 12 way (to include the extra 6 ways on Port B - nothing else connected) on the (L)F88's. I have tried a couple of different methods on these two flowcharts (attached) which you posted for me a little while ago but I just can't seem to get it right! These are the two flowcharts which each programmed the chips once and now don't and give the failure code

Chris

Hi John,

Yes please see attachments on the post I have just put 'up'

Chris

Hello,

The return code 1 could relate to a windows 7 permissions problem. Are you using windows 7?

If you are then maybe try saving your Flowcode file into a library such as My documents or your own user created library. Library folders seem to have enhanced permissions in win 7 and should allow you to compile without the return code 1 issue.

I think in other normal directories that windows sometimes restricts write access to files which causes the compiler to bail out and generate the return code 1 error code.

Hi Ben,

No - I am just using Vista - so what could I do in those circumstances?

Hello Chris,

It looks like you are customising the initialise code which is throwing up the illegal definitions, if you revert the initialise code back to default this (almost) fixes it, another error was thrown up, but a simple renaming of the file seemed to help.

I would take a look at your initialise code and maybe renaming the variable so it doesnt start with a number (illegal symbol).

Regards,

David

Hi David,

Thanks for the help but I'm not quite sure what that means in terms of correcting the problem - how do I do that and is this referring to the C item? Is it possible to 'correct' the two flowcharts I posted?

Best regards

Chris

Hello Chris,

All you need to do is right click on the RS232 component, select the Initialization function, click "Edit Code" then click the "Revert to Default" button at the top. Of course this will remove any customised code you have entered so if it was done by yourself you may want to save it in a text file or other storage file.

Then rename your file and it should remove the errors.

OK Dave - many thanks

Cheers

Chris

Hi David,

Done that but whether I highlight 'initialisation or not - the 'EDIT CODE' is greyed out and wont react.

Don't understand the initialisation sequence so don't know if there is a problem there? I havent actually changed or customised anything since the first time when everything was fine and chip was programmed and working correctly. Would appreciate any help - getting a bit desperate now!

Regards,

Chris

Here is an edited file with the changes made.

its probably good practice to avoid naming files with anything other than 1-9, a-z, (space), _ or -

Thanks David - have applied that principle to the other 1/2 of the system and that solved the problem.

Thanks very much,

Cheers Chris

Hi Martin,

If you happen to be looking at this post, would it be possible to enlighten me as to how to add another 6 ways to the two attachments I posted at the begiining of this posting - gotta be simple but I'm just not getting it for some reason.

Thanks in anticipation

Regards, Chris

christoph wrote:Hi Martin,

If you happen to be looking at this post, would it be possible to enlighten me as to how to add another 6 ways to the two attachments I posted at the begiining of this posting - gotta be simple but I'm just not getting it for some reason.
Regards, Chris

Hi Chris,
I believe I have come up with a solution.

It was not that easy for two reasons.
1) Since transmitting in bytes there has to be a way to distinguish from the two sets that TX from port A and B
i.e is the receiving byte from port A or is it from port B

2) Port B2 and B5 are reserved for UART, so they cant be used for anything else.

1) A soultion I thought of was to only read RX and assign data coming in to In_A & In_B when RX of 210 is seen.
So the 210 is being used to sync data.
There maybe a better way?

2)B3 is made redundant by using decision branches: Martin

Hi Martin,

Unfortunately I haven't been able to make them work. I first checked the wireless link with the chips programmed with your original 6-way Tx/Rx and that was perfect so I replaced theem with another pair programmed with the latest flowcharts and got no reaction (and the LED on my transmitter indicating a UART signal - radio part of it; not neccesarily the chip, wasn't flashing). So I then put them onto another breadboard which is just hardwired to eliminate the radio aspect of the system and still no result. I did notice when I ran the simulation - prior to programming the chips - that the Rx didn't function on the simulator i.e. none of the LED's lit up when I entered any numbers BUT I would have expected commas after each number to distinguish between single and double digit numbers? To be honest these are exactly the same problems as I have been having when trying to use the B port even though I had, like you, taken into account the non-viable port 'bits'. That is why I have just the 12 signals.

What might be the cure 'cos your reasoning seems logical to me as far as my inexperience can see!

Regards,

Chris

Hi Chris,
Odd its not working for you as hardware was working fine for me before posting flowcharts
I will check hardware again. And also make sure I have posted correct files later today.

Martin

OK thanks Martin - much appreciated.

Regards,

Chris

Hi Chris,

Could it be that in the configuration R5/MCLR is set for MCLR?

It all may work if you change that one thing?

If so then sorry it was my fault. I did have a preset configuration for 16F88. I have overridden that but missed MCLR.

There will be no need for commas, as there is a sync data function.

The LED's respond only when it sees the sync number of 210.
But since the buffer does not use the same time out on simulation as it does on hardware, then if you send a char 210 in simulator then one digit at a time is used.
On your hardware all three with used at a time.
So simulation is not the same as real life in that case.

At least that's what I believe is whats happening.

The only time on hardware this method will fail is if the switches are pressed so they are also sending 210.

Martin

Edit: Just tried with the files I posted and they are correct.
The difference between my set-up and yours, is I am using 2 EB006 programing boards and they have the necessary pull-up resistor on MCLR line.
That's probably why my set up worked and yours did not with RA5/MCLR set to MCLR

Hi Martin,

This is a bit baffling cos I have been using 10k resistors to positive from RA5/MCLR since you mentioned this in a previous post, so should be OK in that respect. Knowing that it SHOULD work, I will do some more checking today - different F88 and LF88's although - as I say, they all work quite happily with the 6-way set up so I don't think I have a dodgy chip. The only thing I can think of that is different, is that I only have 2 switches and the 2 appropriate LED's connected but I will try a full set.

I will let you know the outcome!

Regards,

Chris

Hi Martin,

No joy, I'm afraid. I can't understand it.

I just have a breadboard at 3.3 volts with the two chips programmed with your flowcharts for the Tx/Rx with 10k pull-downs on the inputs and 10k pull-ups on the MCLR pin which works perfectly, hardwired and via wireless! What else have the e-blocks got that I have missed I wonder?

I have even modified your original flowcharts for 12-ways and they work fine for both Tx and Rx when simulated in Flowcode but don't work in practice!

Regards,

Chris