BL-819 BL-830 Power Requirements

The BL-819/830 data sheet gives the power consumption as 110mA at 5V.

USB 2.0 Port Specification

USB 2.0 sockets provide a maximum 500mA at 5V across pins 1 and 4. So yes a USB 2.0 socket can easily power a BL819/830.

Car Cigarette Lighter

The BL-819/830 power input circuitry is:

So the input is regulated by the LM1117MPX. This helps provide a stable output to the Bluecore chip etc of 3.3 volts despite input voltage variations.

However the Nominally 12V in a car can fluctuate widely. 

See the article in Wikipedia http://en.wikipedia.org/wiki/Cigarette_lighter_receptacle

This states:

"

Design considerations

Since the cigar lighter socket was designed to heat a cigar lighter, using these sockets as power connectors can lead to many problems. In addition to the issues with incompatible sizes, plugs can vibrate out of the socket under normal driving conditions, owing to poor retention. There have been reports of melted plug tips.

A second problem is that nominally "Twelve-Volt" power in cars fluctuates widely. The actual voltage will be approximately 12.5 volts when dormant, (less when cold) approximately 14.5 volts when the engine and the alternator/generator are operating, (more when cold) and may briefly drop as low as 5-6 volts during engine start. DC/DC converters will usually compensate for these small fluctuations.

Rarely, more extreme cases of voltage fluctuation can occur when the car battery is disconnected while the engine is running, or when the car receives a jump start. When the battery is disconnected, a load dump transient can produce very high voltages. A car receiving a jump start from a truck will be subject to its 24 V electrical system. A "double battery jump-start" is performed by some tow truck drivers in cold climates.

Design wise one has to take into account intermittent contact, and voltages outside the nominal 12 V DC like top voltage 9-16 V continuously, top voltage at 20 V during 1 hour, 24 Vduring 1 minute, 40 V during 400 ms. Protection component tolerance example ratings are +50 to -60 V DC Additionally, issues can occur with temperatures varying between-40 till +85 °C such as humidity and condensation. Equipment connected this way must tolerate large variations in electrical- and climate environment.

"

So the voltage is only nominally 12V. the drop outs to 5 or 6V are not a problem for the BL-819

The LM117 has a normal safe operating input limit of 15V and if the Car Cigarette lighter never give sout more than this then it would be ok. The Wikipedia article discusses cases where the 15V can be exceeded. The LM1117 voltage regulator has an absolute maximum rating of 20Volts before it is destroyed.

A way round this would be to purchase a cheap car Cigarette lighter to USB lead (about £3.00 ~ $5) and use that as a means of ensuring no out of limits voltages goes to the BL-819/830

• Connection Agnostic Interface, software must work the same no matter what the underlying connection
• So hardware vendors must deliver on these market demands

Device Driver Development

• Serial device manufacturers like Brainboxes base their Device Drivers upon code and recommendations in the Microsoft Device Driver Kit-the DDK.
• How complete an implementation a device Driver is and how compatibly it works varies from one manufacturer to another.
• With over 20 years experience of designing, manufacturing and supplying serial port products Brainboxes have developed an extensive set of test cases which we continuously run on device driver code as it being written, so ensuring we have the highest quality code possible.
• Brainboxes always submit our driver code to Microsoft WHQL – the Windows Hardware Quality Labs and obtain the coveted Windows Logo Approval. Brainboxes have done so since the earliest days of the HCL – Hardware Compatibly List-instigated with Windows NT in the late 1990s.

Layers Between Application and Physical Serial Port

Device Driver Compatibility

• Depending on the physical serial port interface and the actual serial hardware the amount of work needed to implement a device driver varies.
• For ISA serial ports based upon standard 16550 UART chips all that is required is to pass two parameters to Microsoft’s own serial port device driver code. This gives the highest level of compatibility since there is no non Microsoft code involved.
• With PCI and PCI Express products a similar process will work.
• However UARTs have had many features added to them to help the CPU cope with the increasing burden of a PC running a pre emptive multi tasking Windows OS. The icrosoft DDK code does not support these features and so serial port manufacturers like Brainboxes must provide their own Device Driver code to implement the now necessary serial port UART features like Automatic handshaking and deeper than 16 byte FIFOs.
• How well these Device Drivers are written is a clear differentiator for Serial port companies.
• There is a clear one to one correspondence on Windows API calls when using ISA or PCI Express interfaces even when using highly advanced UARTs. When implementing a Device Driver for Serial Ports that are attached on the other side of a transport link like USB or Ethernet involves dealing with many issues. Achieving compatibility on the Windows PC is a non trivial task since it not only demands an in-depth understanding of the Windows DDK structure but also involves judgement calls in what course of action to follow when status or data is not immediately available and has of necessity to come across a link some distance away in time and space.
• This brings up two main areas of incompatibility that causes applications to fail or work inconsistently:

2. Wrong return values passed back to Windows and the application due to misunderstanding the serial API
3. Hidden assumptions in the code regarding response times etc

• Hidden assumptions prove hardest to debug

Hidden Assumptions

Much of the programming model of original ISA interface has been unconsciously carried forward into later written Windows application code.

• Assumption 1: That the serial device is the exclusive use of the Program on the Host PC. 
  • True: PCI, USB 
  • False: Ethernet
• Assumption 2: Latency The serial interface is immediately able to provide back to the PC application status information regarding eg the CTS/DCD/DSR/RI handshake inputs of the serial port 
  • True: PCI 
  • False: USB, Ethernet
• Assumption 3: Latency Data transmitted and handshake output line status can effected instantaneously 
  • True: PCI
  • False: USB, Ethernet
• Assumption 4: Latency Instructions to change the Baud rate etc or to flush tx/rx data buffers are effected instantaneously 
  • True: PCI 
  • False: USB, Ethernet
• Assumption 5+ Programs tweaked to work with particular devices in typical setups will work even with PC platform changes, versions of Windows, different serial device revisions and external end user equipment.
  • It depends ??!!

Installation and Configuration

• In the past how a port was installed and  configured was highly dependant on the  interface bus used and the preferences of the  device manufacturer.
• As the Windows UI has matured it is  increasingly likely that a common unified  method based upon underlying Microsoft  APIs will be used.
• So today installation is often provoked by a  plug and play discovery event based on the  familiar USB style device discovery.
• So the COM ports added into the PC system  and accessed in a standard way.
• Configuration via the Control Panel or  increasingly by a web interface.  

Traditional COM Port Interface

• Our software gives your applications a true COM port interface and handles all the issues about transport layers, latency and connection protocols.  
• Allows you to keep making  a return on your proven existing software  investment.  
• Upgrade to a new connection topology without any fuss.

Latency

• Each layer has its own standardised way of communicating configuration information, serial port data and status information.
• As the data passes up and down the layers from the Application to the physical serial port these processes can add delays:
  
  • Packetising of data to improve throughput
  • Data decoded from one standard and re-encoded in the next standard.
  • The actual transfer of data across an interface
  • The serialising of the data as it is transmitted or received
• This total delay is called the latency.
• Typically the larger the packet of data being transferred the less import the latency becomes when expressed as a % of the total transfer time.

This is part 3 of a 3 part series:

Part 1: Brief History of Serial Communications

Part 2: Latency and Response Times

Download the complete presentation below:

What is Latency?

• Latency is a measure of time delay experienced in a system. In the man’s journey the latency is between 10 mins and 1hr 10mins. His wife will happily wait 1hr 10mins for him but after this his time is out.  

Latency Variations

• Latency is not a fixed quantity, it varies, in our example it has a two values that are a factor of 7 in range, 10mins or 1hr 10mins.
• Often other external influences also effect the latency. Imagine that there is a lot of traffic on the road and the bus journey may no longer take 10 minutes.
• Bus systems such as USB and Ethernet share the interface with other connected devices just as the workman’s bus shares the road withother traffic. The quoted latency for USB and Ethernet assume no delays due to external traffic on their buses due to other devices.
• User serial programs have to be written to take account of real world latency

This is part 2 of a 3 part series:

Part 1: Brief History of Serial Communications

Part 3: The Software Challenge

Download the complete presentation below:

• In The early 1980s when the IBM PC was first introduced IBM and other companies quickly made RS232 serial communications addon boards available to allow the connection of the PC to external devices.
• The PC was generally running the MS DOS operating system and programs were coded so that the program talked directly to whatever hardware resources they needed. Standard Serial ports were always expected to be at fixed i/o addresses and wired to certain interrupts.
• COM1: ADDRESS=03F8 hex IRQ=04
• COM2: ADDRESS=02F8 hex IRQ=03
• MSDOS could only run one application program at a time and an unwritten assumptions of all these programs was that they had exclusive use of and immediate unrestricted access to all PC system resources

ISA Cards

• ISA Cards 1981-1997
• Serial Port Resources are set by the user using DIP switches and jumpers
• ISA no plug and play- the add in card had no mechanism for automatically informing the PC system what resources it needed.
• The PC had no mechanism for allocating resources to add in cards, everything was down to the user knowing exactly what was in the PC and being able to personally ensure that one device in the PC does not clash with any other.

Windows 3.1

• With the tremendous success of Windows 3.1 in early 1990s programmers started to become familiar with writing code so that application programs talked to system Device Drivers that presented a standard API to the outside world. This Windows Device Driver then managed the actual communications to the serial ports hardware.
• Windows 3.1 was a system that implemented cooperative multitasking and so was capable of running multiple well behaved application programs at the same time provided they accessed the system resources strictly via the system Device Drivers through the Microsoft provided Application Programming Interfaces- Device Driver APIs
• It was necessary for the user to tell Windows what hardware resources serial port add in cards needed by entering data using the System in Control Panel.
• Though the Device Drivers in principle allowed serial ports at any otherwise unused i/o address and interrupt in practice COM1: and COM2: used exactly the same values assumed by MSDOS programs. This greatly eased the transition from MSDOS to Windows serial applications

ISA To PCI Transition

• ISA to PCI Change
• In the late 1990s the slots on new PC motherboards underwent a gradual change from being ISA only through a mix of ISA and PCI to being completely PCI slots.
• PCI cards were configured electronically as the PC booted up. The card requests resources from the PC which responds by allocating it i/o address and interrupt. Typically the resources allocated do not correspond to those traditionally used by ISA cards.
• Old MSDOS applications running in a DOS window inside Windows broke mainly because they expected to talk to serial ports at particular i/o addresses and interrupts.
• Huge effort was invested by the industry and customers in migrating their code to work with PCI based PCs. However issues to do with the unwritten assumptions of these programs that they had exclusive use of and immediate unrestricted access to all PC system resources remained hidden in the program code.

Serial Port Improvement

• The burden of implementing the Windows OS on the CPU where the application programs only actually run during small time slices meant that the PC could no longer do real time control of the serial port. To overcome this extra features were added to the serial port chip- the UART- to lower the burden on the PC the first one being 16 byte transmit & receive FIFO buffers. The data sent and received by Windows to the serial port is no longer a character at a time but is now transferred in FIFO size packets. This trend continues to this day with the following features being implemented in stateof the art UARTs.
  
  • FIFO size grows from 16 to 32 to 64 to 128 and 256 bytes
  • Automatic flow control RTS/CTS or DTR/DSR implemented in hardware
  • XON/XOFF flow control in hardware
  • RS485 Half Duplex Autogating
  • DMA transfers of data to and from the serial port.
  • Baud rates higher than 115,200 and non standard baud rates
• Today the way an application communicates to a serial port has become completely uncoupled from the underlying hardware that actually implements the serial interface. Instead the Application talks to the Windows API in a standard manner, the serial port hardware manufacturer provides a device driver that interfaces to Windows OS and repackages the transactions in a manner that is compatible with the actual serial implementation

Validation of Platform

• As in the days of DOS, it has proved that there are often many hidden assumptions in code of Windows application programs about the underlying hardware implementation and performance. This results in programs 'breaking' when being moved from one version of Windows to another or with different firmware versions or due to changes to the external network system.
• Timeouts in programs that allow an application to recover gracefully when the communications system fail often cause errors to be incorrectly reported when the serial port hardware is changed to one with longer inherent latency.
• These issues may be exacerbated by the use of multi core CPUs in the PC since the context change time from one core to another adds its own latency.
• To mitigate against these issues system suppliers often go through along costly period of validating a given solution, characterising its operational performance in a large number of defined test cases.
• Sometimes this merely results in a making a particular system work because of tweaking of parameters to match the quirks of the various devices involved, preventing platform evolution over time.

This is part 1 in a 3 part series.

Part 2: 

Latency and Response Times

Part 3:

The Software Challenge

Download the full presentation below:

Key Features

• Glueless interface to PCI bus
• Up to eight UARTs
• UARTs are register and functionally compatible with TL16C550 or TL16C750
• Compatible with existing 16C750/550/450 device drivers
• PCI 2.1, 2.2, 2.3 and 3.0 compliant
• Supports both 5.0V and 3.3V PCI signalling
• Low-power design
• Configuration data is held in a small, cheap serial EEPROM

UART enhancements:

• Clock prescaler allows more baud rate options
• Readable FIFO levels and tuneable trigger levels improve device driver performance
• Programmable "synchronisation factor" allows baud rates up to fclock/4
• Extensions to standard register set are implemented in a safe, easy-to-use way

The UARTs in the BB16PCI958 are register and functionally compatible with the TL16C750 or TL16C550A. The TL16C750 is a backwards-compatible upgrade of the TL16C550A. The TL16C550A is a backwards-compatible upgrade of the TL16C450. The TL16C550A is a widely supported industry-standard UART with 16-deep transmit and receive FIFOs. Device drivers written specially for the BB16PCI958 can make use of added features such as deeper FIFOs, readable FIFO levels, and individually programmable FIFO trigger levels.The UARTs convert between RS232-format serial data on separate transmit and receive lines, and byte-wide I/O writes and reads on the host interface. Malformed incoming serial data is flagged along with the data in the receive FIFO. The state of the UART can be found at anytime by reading status registers, and modem control (handshaking output) lines can be individually controlled.

Although polled-mode operation is possible, the UART will usually be operated on a host interrupt basis. The interrupt system is designed to allow efficient handling of interrupt service requests from the UART, for example by using the prioritised interrupt identification register, readable FIFO levels, and tunable FIFO trigger levels. The internal transmitter and receiver logic runs at a programmable synchronisation factor of 4x, 8x, or 16x the serial baud rate. This internal clock is generated by dividing a reference clock by and integer divisor from 1 to (216 - 1). In this way the UART can accommodate a serial rate of up to 5,500,000 baud (using a 22 MHz input clock).

Ideal for Bluetooth designs:

Working closely with CSR, we have engineered the chip for a glueless interface to BlueCore01 and BlueCore2 chips, with several specific features built in such as power shutdown control, SPI interface for flash programming and auto reset on power up. All of which hold advantages to system designers - maintaining flexibility and minimising power consumption levels in the finished design.
We also provide a Bluetooth CompactFlash reference design based on the BB16CF950+ and CSR's BlueCore 2 chip, which gives fast time to market for manufacturers.

Features

• Low power consumption
• Register and functionally compatible with 16C750 UART
• Compatible with existing 16C450/550/750 drivers
• 128 byte send & receive FIFO buffers
• Glueless interface to CF/PCMCIA bus
• 1.5Mbaud serial interface
• Glueless interface to CSR BlueCore chips

To receive the full databook for the chip we ask you to sign a non-disclosure agreement. Email sales@brainboxes.com for further details.