rs232

[ZONK]

The reason why my Pic16F88 on assembling came up with mesage was resolved by updating the h file within C2C folder.
I managed to get the Pic16F628 and the above chip to work with my project by linking the corresponding Screw terminal connectors for port B to the relavent jumper link on the rs232 E-Block.
I may be wrong but unless this is done, you can't communicate to the max3232 chip because of the fact that the other two pic chips that I have used work there uart on port C which I think was stated earlier.
All I have to do now is to figure out how to build my project independant if the pic controller board.
Qustion?
Can the PIC16F88 be programmed using flowcode in such away that when I come to build the project for real that I don't have to use an external Xtal or does the uart part of the chip require the exact 19660800Hz crystal to function corectly.
If so which one of the internal oscillator settings is advisable.
Thanks again for any advice.

[Benj]

The UART is based around the oscillator frequency. The microchip datasheet gives exact data on the speeds and error percentages compared to the clock speed. If an internal oscillator is used instead of a crystal there may be a much higher percentage of errors in the transmission. Also the internal oscilators are effected by temperature and humidity which may mean that under certain conditions the UART will not function as intended. The best oscillator source in my opinion would be a 4MHz, 10MHz or 19.6608MHz. This will eliminate most of the problems you would have using the internal oscillator.

[Steve]

Unfortunately, the current RS232 component within FlowCode has a bug. It assumes that the clock frequency is 19.6608 MHz.

I hope to correct this within the next few weeks, but I don't have the time at the moment.

[Mark]

Steve,

After taking your suggestion to review the RS232 code (re my problem with a retart as posted recently) some thoughts as to modifications for your reworking of the code are :

1) Provide an 'advanced' tab on the control screen to allow for selecting more complex options than the 'get you up and running' set up we have now.

2) Allow for other clock speeds (I suggest you allow users to choose from standards but also use their own speed along with a calculation of percentage accuracy (this is shown in the Microchip seminar slides on USART usage)) If not then a long list of standards please, particularly real time clock friendly frequencies.

3) Allow users to select timeout '0' so as to simply go get data and return so that users can make their own timeout routines in flowcode if they want. Allow timout 255 to stall programme execution until a byte is recieved (the current code implies this but it does not actually seem to work).

4) Give at least the option to remove the 'send back' error messages as unless the sending (eg PC) software is set up to deal with these (which is a programming task in itself) then they simply clog up the input buffer of the PC and hinder debugging (in my humble opinion). Also the OERR and FERR results only occur if the communication is incorrect (buad rate etc) so it seems of limited value to try and send back data on a 'faulty' line, better to set a flag that can be picked up by a flowcode routine?

5) Make some provision for RS432 (polling address bit flag on bit 9(I think)).

Much of what I need can be achieved by learning some C and coding it in, but I prefer to keep within flowcode and I see no shame in having a few flowcode icons/options that simply mimic C to invoke the more complex C commands.

Lastly please (please agian if that helps) document the code (at least from embedded comments in the C code) so that it there are no surprises. (The business of various 'masks' in the coding' took some unravelling, if at all).

Freindly thoughts from a Flowcode fan...

[Benj]

Mark,

Steve is away this week and wont be back until next monday. I will make sure he gets your suggestions about the RS232 in flowcode.

Many thanks for your input,

[Steve]

Fantastic suggestions, Mark - many thanks.

We have already been working towards your 2nd point. I will look at the other points when I get the chance and see what we can to implement them.

[de fre]

hey steve...
I need to do the same for school work
(I need to mike a little shift register for reading parallel signals in and send it seriel out...)

dous your program work in flowcode?
can you send the file pleas?

very thx...

[de fre]

I tryed it 2 but I con't load it in the pic he said that I used a worng c command... (I did it with flowcode)
but I only used the diagrams and the rs232 macro