Serial Config help.

OK, I`ll do that too

it`ll likely not be until the weekend though, and in the meantime I`m going to throw this problem OPEN and include PIC chip solutions too.

I use 16F877a and 18F4550, I think these could also be capable of such a task, perhaps?

meanwhile, i`m going to get some welding done on MINDI, I need a break from all this software stuff!

I would not know about the PICs but that brings a thought to mind about putting to use additional ICs like a serial to parallel for trouble shooting or solution implementation.  I seem to recall some chips that have the capability to generate more than 8 bits on their serial output pin.  So something with an I2c interface would be an cool option.  Of course the Arduino Uno can and does have the capability but apparently not under the control of SoftwareSerial unless our trick with using type double pays off. 

Wait a second; what software resources are applied when communicating over the I2C wires? Could the I2C packet be configured so that the Univeral receiver (PXP-40) is fooled into printing the desired characters?

N.B. You may want to put a little wait state in the Loop() to give that antique thermal printer enough time to figure out what to do with the bits it is getting.  It is possible that is its problem even now with the 'Hello World' string.

if I were to use other chips, i`d do it from scratch like I did before with a  1200CPS clock, a Binary counter to feed a 74150 and a 10 count RTS for next byte into the 150, the other code would be set with DIP switches.

parity would be parsed with an inverter on on the LSB (as anything Higher will be an even number anyway).

as for I2C I know very little to nothing about it yet, beyond a single temp sensor anyway

Wow. A lot of people have no clue how serial data works.

1 start bit is pretty standard.

"...don't know anything that still uses it..."

rubbish. EVERYTHING uses it. An idling serial stream is sending "mark" (logic 1 -- which will be a negative voltage if RS-232RS-232 or positive if TTL). When a byte is ready to be sent, the data line is commanded to "space" (logic 0 -- positive if RS-232RS-232 or 0v if TTL). This is your start bit. When the receiver detects the logic 0 it knows to begin timing and extracting the bits.

Yes, LSB first is "normal." No worries there either.

Edit: Never mind extra bit I was adding to Salvador's bitstring. He has it right.

Hi CookeMonster,

Yeah, that "previous poster" was me! :-)

I believed that UCSR0C was a byte, why do you have 9 bits? I understand that the bits that specify the word length are 3 bits, but 2 of these are in the UCSR0C and the third (MSB) is in the UCSR0B register.(bit 2). Thanks! Salvador

>Have you tried casting the variable as a double?

>Here is my idea:

>Given an AsciiChar Byte which Serial.read() has provided from the Console:

>NewChar = AsciiChar|0x80;  // set the first bit high so you have the "Start Bit"

A start bit is a 0, not a 1

>DoubleChar = (NewChar * 4) + 3;  // shift the bit pattern left 2 positions and

>// set the two low order bits high for the "Stop bits"

You are putting them at the wrong end. It comes out of the UART LSB first.

>If softwareserial cannot handle the double, then break it into two bytes

>and send them one after the other using myserial.write.

You can't do that. There is a start bit on each byte. And a parity bit. And then a stop bit. Two in this case. (logic 1's).

Reading left to right, if you put a scope on it the bits should come out the wire like this (start "S", 7 data bits "X", even parity "P", 2 stop "SS":

S0123456PSS

0XXXXXXXP11

If another character is ready to be sent, a new start bit is sent (logic 0). If no character is ready, the line remains at logic 1 until one is.

Yes, it should be 8 bits. I counted 7 in your post. Let me put my reading glasses on and look closer. The "1" on the right needs to be 3 bits "in". Back in a flash...

Edit. Yep. I don't know how I counted that wrong. Your string is correct. Original message edited.

Ah, I see another problem.

Salvador's "how to set the 7 bit" thing only will work on the original hardware serial port .

OP is trying to do serial on pins 2 & 3.

If you can not put the printer on a hardware serial port, you probably have to write your own (software) serial library -- I'm not aware of any of the software serial versions that support 7 bits and even parity.

No worries -- it is not that hard -- 90% of what you need is available open source, only the partity and adding a second stop bit are required to be added; reduce the sent bits from 8 to 7, change time delay to what you need for 1200 bps. You don't even need the receive code. That is harder to do reliably anyway. Sending is easy.

Good catch, so setting UCSR0C only works if using pins 0 and 1? Haven't used those in a while, so correct me if these do not correspond to the original hardware serial port. Nevermind - I've got the Arduino in front of me and just checked it. RX and TX are clearly labeled for pins 0 and 1, respectively. Salvador

CM says:  (start "S", 7 data bits "x", even parity "P", 2 stop "SS")

If the data line is held high all the time just to let the device know that it is connected, then okay.  I did not know that was the standard; seems a waste of electrons, IMO.

If the parity bit must be present does that printer even use the parity bit?  or ignore it?

So, we have

newChar = (double((asciiChar * 8) +7)| oxf000);   //  will give  11110xxxxxxxP11

or

newChar = (double((asciiChar * 8) +3)| oxf000);   //  will give  11110xxxxxxxP11

or even

newChar = ((double((asciiChar * 8) +7) *16) + 15);   //  will give  0xxxxxxxP111111

Is one of those going to work?