search

saoudimassi / arduino

Automatically exported from code.google.com/p/arduino
0 stars 0 forks source link

the addition of a serial.end() command #45

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What change would like to see?
the addition of a serial.end() function to turn of the serial port and
return the pins to digital function.
An implementation is shown here
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1232485147/1 which worked
with 0013

Why?
Sometimes you need the extra pins, sometimes you need to control the port
pins for custom handshaking.

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?
Not sure, i doubt it.

Original issue reported on code.google.com by teamcba@hotmail.com on 18 Jun 2009 at 12:43

GoogleCodeExporter commented 9 years ago 
Here's an implementation that works with 0016 and 0017:

//--------------HardwareSerial.h
    void end(void);

//--------------HardwareSerial.cpp
void HardwareSerial::end(void)
{
    //disable interrupts
    uint8_t oldSREG = SREG;
    cli();

    // disable rx and tx
    cbi(*_ucsrb, _rxen);
    cbi(*_ucsrb, _txen);

    // disable interrupt on complete reception of a byte
    cbi(*_ucsrb, _rxcie);

    //flush serial read buffer so no data is available if beginSerial is recalled
    flush();

    //reset sreg to original state (re-enable interrupts)
    SREG = oldSREG;
}

//--------- Usage
    Serial.end()

Original comment by rleylan...@gmail.com on 18 Aug 2009 at 10:43

GoogleCodeExporter commented 9 years ago 
I see stuff like this in the Arduino libraries a lot:
    cbi(*_ucsrb, _rxen);
    cbi(*_ucsrb, _txen);
    cbi(*_ucsrb, _rxcie);

Which is a waste of resources and uses the deprecated sbi and cbi calls... The 
more
modern and efficient way is:
    *_ucsrb |= _BV(_rxen) | _BV(_txen) | _BV(_rxcie);

_ucsrb is volatile, and volatile assignments are guaranteed to not be 
optimized, so
there is no way for a compiler to ever fix this.

Anyhoo, cbi and sbi are deprecated and shouldn't be used anymore.

http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr.html

Original comment by gabebear@gmail.com on 18 Aug 2009 at 11:08

GoogleCodeExporter commented 9 years ago 
oops, I realized as I was hitting submit that I was setting instead of 
clearing...

*_ucsrb &= ~( _BV(_rxen) | _BV(_txen) | _BV(_rxcie) );

Original comment by gabebear@gmail.com on 18 Aug 2009 at 11:15

GoogleCodeExporter commented 9 years ago 
Thanks Gabe,  Yes that is clearly better.  I was modeling my code after the 
code that
already exists in the library.

Original comment by rleylan...@gmail.com on 18 Aug 2009 at 11:28

GoogleCodeExporter commented 9 years ago 
I need end functions in all libraries that take over pins. I need to 
dynamically reassigns pins and start various 
libraries on them  according to messages from USB. Not everyone buys into the 
setup, while(1) loop idea that 
makes people lazy about providing and end().

Original comment by newsfr...@gmail.com on 26 Aug 2009 at 4:23

GoogleCodeExporter commented 9 years ago 
I believe "while(1) loop();" is a vestigial safety mechanism. It would be 
dangerous for a program to continue 
executing the byte code directly after a program, so you need an infinite loop. 
The ".fini0" section now takes 
care that problem. http://www.nongnu.org/avr-libc/user-manual/mem_sections.html

Even if serial setup() isn't run, the USART pins will likely be in USART mode 
because of the Arduino bootloader. 
Swapping functionality of pins on the fly isn't likely going to be put very 
high on the priority list because it would 
require sweeping changes.

Original comment by gabebear@gmail.com on 26 Aug 2009 at 4:45

GoogleCodeExporter commented 9 years ago 
"Swapping functionality of pins on the fly isn't likely going to be put very 
high on the priority list because it 
would  require sweeping changes."

Sweeping changes? Yes, a pin registry would be nice but I am asking for 
something simpler: a function in 
each library that ends that use of the pin, interrupts and specialized hardware 
module. A quick review of most 
of the libraries shows that nobody does it. I should probably file a separate 
case for this.

It is not that much work for each developer - I know because we already do this 
in the uOSC library for pic
which can dynamically assign functions to pins and configure them with OSC 
messages.

Original comment by newsfr...@gmail.com on 26 Aug 2009 at 4:04

GoogleCodeExporter commented 9 years ago

Original comment by dmel...@gmail.com on 24 Oct 2009 at 3:31

GoogleCodeExporter commented 9 years ago

Original comment by dmel...@gmail.com on 23 Dec 2009 at 12:01

GoogleCodeExporter commented 9 years ago 
@ dmellis, Thank you very much, your time and effort are most appreciated.

Original comment by teamcba@hotmail.com on 23 Dec 2009 at 9:36

GoogleCodeExporter commented 9 years ago 
not sure this is the correct place to post this, so please delete if not.

0018 test, windows xp, Diecimila

# Serial.end() - _ends serial communication and frees digital pins 0 and 1 for 
normal input and output._
  * test a: after a call to Serial.end(), can pins 0 and 1 be used for normal input 
and output?
YES
  * test b: after a call to Serial.end(), will Serial.begin() re-enable serial 
communication?
YES

i recomplied all my previous programs that used endSerial(), all which have 
worked 
with Serial.end() without any problems.

Original comment by teamcba@hotmail.com on 25 Jan 2010 at 10:23