Mecanique Serial Communicator Software
- Mecanique Serial Communicator Software Windows 7
- Mecanique Serial Communicator Software Download
- Mecanique Serial Communicator Software Free
I'm attempting to use the serial communicator for the first time, and am having no luck. It's probably something silly on my part, but I can't see why my simple prog (below) wouldn't work. The serial communicator claims that the selected port is either 'not available or in use'.
If I select any other port it claims the port is 'not connected'. I'm downloading various programs to the board-under-test, so I know the serial link and board are both good.
Mecanique Serial Communicator Software Windows 7
Mecanique Serial Communicator Software Download
Does the bootloader not relinquish the port after programming the device? Program below: ' Device 18F452 ' Produce code for a 18F452 PIC micro device Declare XTAL 20 ' ' Declare HSERIALBAUD 9600' Declare HSERIALTXSTA $20 '$20 or $24 (32d or 36d) Declare HSERIALRCSTA $80 ' ' Loop: HRSOut 'Hello world',10,13' DelayMS 2000 GoTo Loop End. Mister E OK, there is something fundamental that I am missing.
If, after my program is downloaded into the part, via the IDE, I'm assuming that the IDE resets the PIC, get's 'out of the way', and the hardware USART then becomes available to the on-board PIC program. Is this not true? If it is not true, when is the Serial Communicator useful?
It doesn't appear to be a standalone terminal program because it closes down when I close the IDE. Incidentally, my simple program is not talking to Hyperterminal either, so there is still something wrong with the code as well.
I am having a problem receiving data from a serial port. In fact, the serial port receives MIDI information, it is no problem to set the baud rate to the midi standard of 31,25 KHz. What I need is the following. The sequence of CHR(176) + CHR(44) + CHR(69) should turn a port pin 'on' The sequence of CHR(176) + CHR(44) + CHR(5) should turn a port pin 'off' While this is running, a random combination of characters may appear on the input, but this should not influence the status of the output pin used. The output should only react on 176+44+69 AND 176+44+5 I have made something already, but it seems this is not reliable. Suggestions are highly appreciated!
Code: HSERIN nTest SELECT CASE nTest CASE 'Q'; if Q then send data to PC Goto TermTX CASE 'S'; if S then receive data from PC goto TermRX returnThe TermRX / TermTX subroutines are then used with HSERIN or HSEROUT to receive and send data. As can be seen from the code I use Q and S as the keys to communicate with a PC application which receives variable data and populates text boxes, or if the value are changes in those text boxes and the update button clicked, the PS sends the new values for the variables. Hope that helps.
Sayzer, Sorry, i don't understand what I have done wrong with the OSC settings. I'm using an external 8MHz crystal; maybe I should have mentioned it. I'll give Richard's suggestion (post #10) a try in a little moment and see what it does Hi Roger, I know you are using external 8Mhz crystal, that is why you need to tell the chip about it. In your code, there is no OSC setting. You have it in fuse. Default OSC setting is internal 4Mhz.
You need to manually choose the OSC value for external source by OSCCON.0 = 0 Otherwise, chip will not know you have selected external HS. To make sure you are running on the correct speed, have a flip flop on a pin for say 5000ms. Henrik, for my edification is this the correct answer? Please don't roll your eyes too far if this is too much of a NOOB question.
Don't worry about any eyes rolling, this type of thing comes up quite often and hopefully we all learn from it. All four lines obviously compares the value stored in the variable SWITCH with whatever value is on the right side of the equal sign. But out of the four lines, only the first one would make any difference compared to other ones when put into a program.
Mecanique Serial Communicator Software Free
The other Three would execute exactly the same because they all compare SWTICH to the a value of 49 (while the first line compares SWITCH to a value of 1). 1 is simply the value of 1 '1' however is the ASCII character 1 (which happens to correspond to the value 49 expressed in decimal notation). 49 is the ASCII code, expressed in decimal notation, for ASCII character '1' $30 is the hexadecimal representation of the decimal value 30 which is the ASCII code for character we know as '1'%00110001 is the binary representation of the decimal value 30 which is the ASCII code for the character we know as '1' If, instead of camparing SWITCH to something you'd assign values to it.