I'd posted a while back about the subtleties of choosing SMD parts and the voodoo involved in interpreting those packages.. just thought I'd post some links here to some documents I found that might be worth saving and/or referring to in the future.
The SMD Codebook [cached copy]: a good explanation of various packages and many, many tables of codes...
The SMD Code Book: not the same, note that space :) A nice HTML page with some diagrams and codes.
Showing posts with label pcb. Show all posts
Showing posts with label pcb. Show all posts
2012-03-05
2012-03-02
Dealing With Peak I/O
All right, it's been a while.. design blog fail. Mea culpa. But I'm finally getting around to doing some real work on this wireless AVR transceiver thingie and I had to solve a problem which is often encountered, but seldom well-discussed, so I thought it merited a new post.
Some background: I'm designing a wireless transceiver, using a way-cool chip from Nordic Semiconductor. If I get this going, it'll be a much cheaper interface than any of the equivalent devices out there (I'm purposely being a bit coy about the exact application... who knows who's listening on the tubez).
Anyway, I was reading through the datasheet for the above device, and suddenly the doubt crept into my mind. If you've designed boards before, you know what I mean: am I really hooked up to this thing correctly?
I'm using an ATtiny85 for this project -- where I/O pins are at a premium -- so understanding the exact requirements of connectivity is essential.
The nRF24L01+ datasheet has a nice state diagram that suggests that the CE line can be safely left high during operation, but some vague statements elsewhere in the document allude to the need for a low-high edge transition on CE to enter TX or RX mode from standby.
So, with great trepidation I opened a support request to nordicsemi.com's experts and they replied that, yes, sadly, one MUST be able to toggle CE in order to properly transition to active TX or RX state from config or standby mode. Gyarrrrrrr. So what to do, with a measly ATTiny85 and only 5 I/O pins to allocate between CS/, SCK, MISO, MOSI, CE and a UART pin (that's 6 if you're counting along)?
Well, I thunk, and I thunk
And I thunk some more
Then I thunk until my thunker was sore.
I wanted to introduce as little extra hardware and logic as possible, and I'd already verified my split-rate software UART on the tiny 25/45/85 range -- and software UARTs are pretty tricky. I didn't want to do that again just for this project, on a different variety. AVRs vary quite a bit in their exact timer and IRQ configurations going between the tiny/classic/mega/etc. and while they're all capable, the devil is in the details.
In situations like this, one must look at the signals and control-lines one has at one's disposal, and consider if there are mutually-exclusive conditions amongst those that can be taken advantage of. At certain times of operation, some control lines may be quiescent -- for instance, my system only occasionally needs to communicate using SPI, and the slave device will ignore any SPI line activity while the CSN line is de-asserted. The CE line needs to be kept asserted during at least the start of a TX operation and during an entire RX operation.
My first idea was that the nRF24L01+ CSN (chip-select, negative logic) line and the CE (chip-enable, positive) could simply be the same line. The CSN line is only asserted during SPI read/write commands, and the CE is only asserted while one wants to transmit or receive. However, my board needs to be available, if possible, at all times while in receive mode, and that would mean keeping CE asserted at the same time as accessing the received Rx queue via SPI! As well, the nRF24L01+ requires that CE be asserted for some time prior to asserting CSN (2tdStby, around 150us). Darn.
Alternatives that seemed viable:
1. Multiplex SPI MISO/MOSI lines into a single bidir DI/DO using 2 resistors (3-wire to 4-wire SPI)
I considered making my SPI interface half-duplex, by using one of the MISO/MOSI pins of the AVR as GPIO and bit-banging SPI in both directions as two distinct phases; the first, as an output writing SPI command bits, then switching mid-transfer to an input to read the response. The other pin would be re-assigned to a dedicated CE control pin:
I think this would actually work rather well: in regular command transactions the nRF24L01+ STATUS register is returned simultaneously with the SPI master's sending of the command byte, which would not be readable in a single-duplex SPI setup, but the there is a discrete command to read the STATUS register itself as a regular config register.
However, this setup would have the minor drawbacks of doing a separate SPI transaction just to get that status byte, and the major drawback of falling back to bit-banging rather than using the AVR's hardware SPI interface (slower SPI clock rate, more code). Finally, the hardware cost of two high-value resisters to interface the bit-banged half-duplex SPI data line to the nRF24L01+ full-duplex MISO/MOSI pair.
Pros:
- one pin released to be dedicated CE signal;
Cons:
- Loss of hardware SPI, reversion to bit-banging at a lower SPI rate
- Larger codesize due to bit-banged SPI
- Extra SPI transactions to retrieve nRF24L01+ STATUS register
- two extra resistors to convert between 3-wire and 4-wire SPI
OK, perhaps there is something else I could do...
2. Utilize SPI SCK line's IDLE state as CE Assert Signal Using Low-Pass Filter to Ignore SPI Activity
In this scheme, the MISO/MOSI lines are left as-is, full-duplex SPI communication is maintained, and the CE line is controlled by keeping the SCK line high while idle. What about the SCK's frantic activity during actual SPI transfers? Wouldn't that cause the CE line to toggle as well, messing things up? Well, the difference in time scales for the two signals saves my arse here. If one thinks of the SPI activity as a high-frequency, AC-type phenomenon (rapid hi-low transitions of short duration), and the CE signal as a low-frequency, DC-style signal (it's high 99.9% of the time, only requiring a high-low-high transition when changing from power-down to power-up and RX/TX modes, remaining high while RX/TX ops occur), the two signals are 'different' enough that they can be successfully multiplexed on a single line. With a suitably-designed RC lowpass filter, the SCK activity, in short bursts and at a high enough clock rate, will be mostly filtered out of the level seen by the CE pin, so it can be held high even during SPI communication.
Pros:
- no pin need be dedicated to the CE signal;
- Bidirectional, hardware SPI capability preserved;
- no dedicated SPI transfer required to read nRF24L01+ STATUS register
- no codesize increase due to bit-banged SPI operations
Cons:
- two extra components (440ohm resistor + .1uF cap) to implement passive LPF for CE line from SCK
Solution 1. above (single-duplex 3-wire SPI) requires two resistors, so this isn't any worse for board component count or cost; and we retain the faster, full-duplex hardware SPI capability. Win!
Bus Analysis
CE, being a digital input to an IC going through one or more transistors, has very high resistance -- 10Kohm or more, and so does not significantly affect the drain time of the cap, my EEng co-workers promised me. I also ran a sim of the idealized circuit on the CircuitLab online circuit simulator. Highly recommended for checking out cockamamey ideas like this prior to breaking out the parts bin!
For thoroughness, I also simulated the resistor and capacitor being +-10% from spec to ensure the voltage sag during SPI activity didn't change much -- and it didn't, not more than .05V or so over the 32 SCK cycles, so component tolerances shouldn't be a problem.
This hack is nothing much compared to some of the hacks out there that make pins do double-duty (or worse), but I'm proud of my little workaround such as it is. I managed to eke out a critical control signal that otherwise would have been impossible to generate without moving to a 14- or 20-pin AVR part!
Summary
The important lesson here, I think, is that signals in any system can be grouped into at least two major classes:
It is possible to multiplex two signals together on a single control line if they are each from the above two differing classes, as the time-frequency characteristics of each class are different enough to distinguish via a simple high/low pass filter. I know it's possible to multiplex much more than two things in a single physical channel but that's not something I need to know for this project right now :)
Some background: I'm designing a wireless transceiver, using a way-cool chip from Nordic Semiconductor. If I get this going, it'll be a much cheaper interface than any of the equivalent devices out there (I'm purposely being a bit coy about the exact application... who knows who's listening on the tubez).
Anyway, I was reading through the datasheet for the above device, and suddenly the doubt crept into my mind. If you've designed boards before, you know what I mean: am I really hooked up to this thing correctly?
I'm using an ATtiny85 for this project -- where I/O pins are at a premium -- so understanding the exact requirements of connectivity is essential.
The nRF24L01+ datasheet has a nice state diagram that suggests that the CE line can be safely left high during operation, but some vague statements elsewhere in the document allude to the need for a low-high edge transition on CE to enter TX or RX mode from standby.
So, with great trepidation I opened a support request to nordicsemi.com's experts and they replied that, yes, sadly, one MUST be able to toggle CE in order to properly transition to active TX or RX state from config or standby mode. Gyarrrrrrr. So what to do, with a measly ATTiny85 and only 5 I/O pins to allocate between CS/, SCK, MISO, MOSI, CE and a UART pin (that's 6 if you're counting along)?
Well, I thunk, and I thunk
And I thunk some more
Then I thunk until my thunker was sore.
I wanted to introduce as little extra hardware and logic as possible, and I'd already verified my split-rate software UART on the tiny 25/45/85 range -- and software UARTs are pretty tricky. I didn't want to do that again just for this project, on a different variety. AVRs vary quite a bit in their exact timer and IRQ configurations going between the tiny/classic/mega/etc. and while they're all capable, the devil is in the details.
In situations like this, one must look at the signals and control-lines one has at one's disposal, and consider if there are mutually-exclusive conditions amongst those that can be taken advantage of. At certain times of operation, some control lines may be quiescent -- for instance, my system only occasionally needs to communicate using SPI, and the slave device will ignore any SPI line activity while the CSN line is de-asserted. The CE line needs to be kept asserted during at least the start of a TX operation and during an entire RX operation.
My first idea was that the nRF24L01+ CSN (chip-select, negative logic) line and the CE (chip-enable, positive) could simply be the same line. The CSN line is only asserted during SPI read/write commands, and the CE is only asserted while one wants to transmit or receive. However, my board needs to be available, if possible, at all times while in receive mode, and that would mean keeping CE asserted at the same time as accessing the received Rx queue via SPI! As well, the nRF24L01+ requires that CE be asserted for some time prior to asserting CSN (2tdStby, around 150us). Darn.
Alternatives that seemed viable:
1. Multiplex SPI MISO/MOSI lines into a single bidir DI/DO using 2 resistors (3-wire to 4-wire SPI)
I considered making my SPI interface half-duplex, by using one of the MISO/MOSI pins of the AVR as GPIO and bit-banging SPI in both directions as two distinct phases; the first, as an output writing SPI command bits, then switching mid-transfer to an input to read the response. The other pin would be re-assigned to a dedicated CE control pin:
 |
| For theory see Nordic Semi's app note for the older nRF2401 |
I think this would actually work rather well: in regular command transactions the nRF24L01+ STATUS register is returned simultaneously with the SPI master's sending of the command byte, which would not be readable in a single-duplex SPI setup, but the there is a discrete command to read the STATUS register itself as a regular config register.
However, this setup would have the minor drawbacks of doing a separate SPI transaction just to get that status byte, and the major drawback of falling back to bit-banging rather than using the AVR's hardware SPI interface (slower SPI clock rate, more code). Finally, the hardware cost of two high-value resisters to interface the bit-banged half-duplex SPI data line to the nRF24L01+ full-duplex MISO/MOSI pair.
Pros:
- one pin released to be dedicated CE signal;
Cons:
- Loss of hardware SPI, reversion to bit-banging at a lower SPI rate
- Larger codesize due to bit-banged SPI
- Extra SPI transactions to retrieve nRF24L01+ STATUS register
- two extra resistors to convert between 3-wire and 4-wire SPI
OK, perhaps there is something else I could do...
2. Utilize SPI SCK line's IDLE state as CE Assert Signal Using Low-Pass Filter to Ignore SPI Activity
In this scheme, the MISO/MOSI lines are left as-is, full-duplex SPI communication is maintained, and the CE line is controlled by keeping the SCK line high while idle. What about the SCK's frantic activity during actual SPI transfers? Wouldn't that cause the CE line to toggle as well, messing things up? Well, the difference in time scales for the two signals saves my arse here. If one thinks of the SPI activity as a high-frequency, AC-type phenomenon (rapid hi-low transitions of short duration), and the CE signal as a low-frequency, DC-style signal (it's high 99.9% of the time, only requiring a high-low-high transition when changing from power-down to power-up and RX/TX modes, remaining high while RX/TX ops occur), the two signals are 'different' enough that they can be successfully multiplexed on a single line. With a suitably-designed RC lowpass filter, the SCK activity, in short bursts and at a high enough clock rate, will be mostly filtered out of the level seen by the CE pin, so it can be held high even during SPI communication.
Pros:
- no pin need be dedicated to the CE signal;
- Bidirectional, hardware SPI capability preserved;
- no dedicated SPI transfer required to read nRF24L01+ STATUS register
- no codesize increase due to bit-banged SPI operations
Cons:
- two extra components (440ohm resistor + .1uF cap) to implement passive LPF for CE line from SCK
Solution 1. above (single-duplex 3-wire SPI) requires two resistors, so this isn't any worse for board component count or cost; and we retain the faster, full-duplex hardware SPI capability. Win!
Bus Analysis
 |
| Back-of-the-business-card visualization. Patent Pending(tm). |
CE, being a digital input to an IC going through one or more transistors, has very high resistance -- 10Kohm or more, and so does not significantly affect the drain time of the cap, my EEng co-workers promised me. I also ran a sim of the idealized circuit on the CircuitLab online circuit simulator. Highly recommended for checking out cockamamey ideas like this prior to breaking out the parts bin!
 |
| Idealized SCK thru RC filter to generate CE control signal. |
 |
| Simulating SCK sitting high and low for long periods. CircuitLab.com only has a simple function generator, so I just set the frequency down to the KHz range. Note rise/fall time of the CE signal is approx. 125us into logic 1/0 ranges. |
 | |
| Simulating SPI activity at 4MHz for data transfer. Assuming SCK is idle high, the CE signal would sag only slightly during transfers, staying within logic 1 range for well over 32 bit times. So long as SCK idles HIGH the CE signal will return to full Vdd. |
For thoroughness, I also simulated the resistor and capacitor being +-10% from spec to ensure the voltage sag during SPI activity didn't change much -- and it didn't, not more than .05V or so over the 32 SCK cycles, so component tolerances shouldn't be a problem.
This hack is nothing much compared to some of the hacks out there that make pins do double-duty (or worse), but I'm proud of my little workaround such as it is. I managed to eke out a critical control signal that otherwise would have been impossible to generate without moving to a 14- or 20-pin AVR part!
Summary
The important lesson here, I think, is that signals in any system can be grouped into at least two major classes:
- High-frequency, 'AC' type signals communicating data; versus
- Low-frequency, 'DC' type signals managing protocol
It is possible to multiplex two signals together on a single control line if they are each from the above two differing classes, as the time-frequency characteristics of each class are different enough to distinguish via a simple high/low pass filter. I know it's possible to multiplex much more than two things in a single physical channel but that's not something I need to know for this project right now :)
2011-11-23
So Many RF Solutions, So Little Time
Researching parts for a project can be a real time-sink -- you can get bogged down trying to choose just the right part for so long that you don't get anything actually done on your design. It's worse if you have a short attention span like me. However, sometimes you see a part that just looks so much better you've just gotta stop what you're doing and re-design for it. Let's hope my judgement is right on this one..
On a whim I did some searching tonight to see what other RF modules might be out there. I knew of the very cheap and simple 433MHz car-remote style RF modules, which are simple regenerative radio thingies that use Manchester encoding, but their max data rate seems to be about 4KB/s which isn't high enough for my project's intended use (Manchester encoding requires at least twice the data rate of the endpoint due to its balanced 1-0 level requirements -- each 1 and 0 must be transmitted as two bits, either 1-0 or 0-1).
However, my inner geek is now extremely excited to get my hands on these babies: 2.4GHz (same band as Bluetooth) but with:
- raw SPI interface
- 126 RF channels
- 256kbps/1Mbps data rate
- full error detection/correction
- no crazy QFN pads. Simple
8-pin header. - cheap modules available (half the price of HC-05 boards if you shop around)
UPDATE: I saw some pages talking about the TI CC2500, another 2.4GHz transceiver and wondered if it had any clear advantages over the nRF part. Here's a PDF that compares the two (obviously from Nordic Semi, but the advantages seem clear on power saving and data rate.)
These look to be easier to work with for prototyping (.100" header, yay!), easier from a software standpoint (sigh, my dual-rate software UART code may be for naught) and, I hope, lower latency/jitter than Bluetooth devices. I've emailed Nordic Semi to see what they say about that... but if nothing else it'll make for a cheaper board, simpler firmware, and less burned thumbs for me :)
UPDATE: Nordic got back with a reply today, and it sounds like the nRF24L01+ can transmit 32 bytes of data, with an ACK even, in approx. 165us -- crazy fast. I was hoping for 10ms or so latency but with this device I might be able to get <1ms, far exceeding my requirements. The more I read the spec sheet the more I am impressed.
2011-11-20
Using Li-Ion and Li-Po Batteries in Your Own Projects (without getting ripped off or blown up)
Those with whom I've been discussing circuit design lately have, it seems, been surprised to learn that there's a dead-easy way to use Li-Ion and Li-polymer ('Li-po') batteries in your own designs. Lithium-ion batteries give a nice 3.7V supply to any project and are available in a nice range of mAh capacities, ranging from small coin-cells, to AA- and AAA-imposters, to thin square or rectangular packs. The latter are used in all kinds of things like MP3 players, iPods, and little USB keychain picture-frames (if you see those at discount stores for under $2, grab as many as you can -- they're worth it just for the battery! -- but see the end of this post for more on that).
Lithium-ion cells, as I understand it, have some specific charging requirements which sounded scary to me at first, especially with stories of burning laptops, exploding white-hot batteries and the like.. but when handled properly are no worse than using alkaline or Ni-MH cells and they don't suffer from the memory problems for which the latter were infamous (apparently newer ones don't have memory problems -- I haven't really researched it myself).
From what I've read the short-list of Lithium rechargeable safety tips are:
Interestingly, the LIR series of rechargeable coin-cells, in addition to being drop-in replacements for their non-rechargeable brethren, also have the ability to deliver much higher current. The LIR2032 for instance is rated at about 70mAh peak supply current, while regular CR2032s are only able to supply about 0.2mA continuous drain(!?) [anyone know the absolute max rating? specs sheets I've found don't say], making them not really suitable for anything other than where you typically see them -- in blinky-light dollar-store gadgets and for CMOS backup. [Edit: hmm, I just noticed that the standard CR2032 apparently has a higher capacity than the LIR2032 according to the linked specs... I'd guess there's some general tradeoff going on here wrt. long endurance vs. high power...]
Anyway.. to the point -- Dallas-Maxim makes a pair of really convenient single-chip solutions, the MAX1551/1555, to charge any single-cell Lithium-ion or Lithium-polymer battery that is just so easy to use, there's no point in using alkaline or other batteries unless you have good reason to. These ICs take care of the whole charge cycle, and even have dual DC inputs, one for USB and the other for a DC power supply. The IC switches between whichever provides the best power at the moment -- or just ground one input if you're only using the other. Combine this IC with a USB-mini socket on your project, even if you're not using USB comms, and you have a dead-simple way to recharge your device. I personally prefer the MAX1555 variant as its CHG/ output hooked through a resistor tothe battery's positive terminal VBUS gives a handy charge indicator:
[Blatant Plug: the board above uses all SMT parts save for the jumpers, which I wouldn't have attempted myself, but my colleague Chuck Rohs (the world's only lead-free engineer, HAR HAR) has a purely awesome PID controller for a souped-up toaster oven reflow station (that's just one application). Take a look at that board up close, the soldering job is bee-yootiful. You should buy his reflow oven kit :)]
Bargain Tip: search on eBay (or alibaba or other wholesaler if you are doing quantity) and you can find Li-polymer square packs in the 180mAh-600mAh range for $2 USD or under per cell. LIR2032 rechargeable coin-cells are also to be found online, again at prices $2 or less per unit if you shop around. Don't buy from anyone charging significantly more than this, you wouldn't believe the markup some online [US-based, sorry] retailers will charge on these things! Generally, if the website says they "specialize in batteries", they really are specializing in overcharging for batteries (har har, I made a pun). :)
Lithium-ion cells, as I understand it, have some specific charging requirements which sounded scary to me at first, especially with stories of burning laptops, exploding white-hot batteries and the like.. but when handled properly are no worse than using alkaline or Ni-MH cells and they don't suffer from the memory problems for which the latter were infamous (apparently newer ones don't have memory problems -- I haven't really researched it myself).
From what I've read the short-list of Lithium rechargeable safety tips are:
- don't drop them (it breaks the internal short-circuit/overheat protection circuit);
- don't solder to them (search 'spot-welding coin cells' for the right way to attach pins yourself);
- don't charge them using Ni-MH or other types inappropriate for Lithium rechargeables.
Interestingly, the LIR series of rechargeable coin-cells, in addition to being drop-in replacements for their non-rechargeable brethren, also have the ability to deliver much higher current. The LIR2032 for instance is rated at about 70mAh peak supply current, while regular CR2032s are only able to supply about 0.2mA continuous drain(!?) [anyone know the absolute max rating? specs sheets I've found don't say], making them not really suitable for anything other than where you typically see them -- in blinky-light dollar-store gadgets and for CMOS backup. [Edit: hmm, I just noticed that the standard CR2032 apparently has a higher capacity than the LIR2032 according to the linked specs... I'd guess there's some general tradeoff going on here wrt. long endurance vs. high power...]
Anyway.. to the point -- Dallas-Maxim makes a pair of really convenient single-chip solutions, the MAX1551/1555, to charge any single-cell Lithium-ion or Lithium-polymer battery that is just so easy to use, there's no point in using alkaline or other batteries unless you have good reason to. These ICs take care of the whole charge cycle, and even have dual DC inputs, one for USB and the other for a DC power supply. The IC switches between whichever provides the best power at the moment -- or just ground one input if you're only using the other. Combine this IC with a USB-mini socket on your project, even if you're not using USB comms, and you have a dead-simple way to recharge your device. I personally prefer the MAX1555 variant as its CHG/ output hooked through a resistor to
 |
| Example Li-ion/Li-po charger using MAX1555 and USB-mini jack. Heck, leave out the caps if you're really cheap, it still works. |
 |
| Design-in-progress w/MAX1555 and salvaged Li-po from a USB picture-keychain thingie, happily charging |
Bargain Tip: search on eBay (or alibaba or other wholesaler if you are doing quantity) and you can find Li-polymer square packs in the 180mAh-600mAh range for $2 USD or under per cell. LIR2032 rechargeable coin-cells are also to be found online, again at prices $2 or less per unit if you shop around. Don't buy from anyone charging significantly more than this, you wouldn't believe the markup some online [US-based, sorry] retailers will charge on these things! Generally, if the website says they "specialize in batteries", they really are specializing in overcharging for batteries (har har, I made a pun). :)
2011-11-19
A Dual-Rate UART Implemented in Software Using Atmel ATTiny MCUs
I've started designing a wireless interface using Bluetooth that, for technical reasons, requires the endpoints to communicate at a nonstandard baud rate. I found these neat-o Bluetooth-to-serial adapters on the net [look around, this is not the cheapest place, don't pay more than $8 USD or so for them and be sure to verify they have the HC-03 or HC-05 firmware that supports master -and- slave modes] that have a convenient AT-command set interface for configuration, so you can pair them up without any in-depth knowledge of Bluetooth, and a transparent mode that then acts like the modems of old... but they only support the standard rates you see with COM ports on PCs (9600/19200/38400 and so on). Bummer.
So.. it seemed to me that it should be possible to add a controller that, depending on the communication direction (this is a unidirectional link), would do an up- or down-conversion by sitting in between the BT interface and the target endpoint.
No hardware UART I've heard of supports a split data rate on the Tx and Rx lines, so a hardware UART or USART was not in the running. Software UART implementations from Atmel's app notes only do half-duplex while this required something that could shuffle data both ways in order to do the rate conversion.
For full-duplex software UARTs there is a handy library out there which includes one -- the Procyon AVRlib -- but it was written for AVR mega MCUs, and didn't have any facility for asymmetric baud rates. My application only needed a few pins so I wanted to use the ATTiny which has a somewhat different interrupt and timer register set as compared to the ATmega series. Moreover, the ATTiny25/45/85 have two independent hardware timers -- it looked perfectly feasible to implement a software UART that had asymmetric baud rates on the Tx and Rx sides, so why not roll my own software UART. Shouldn't be too hard, right?
Here's the general concept:
[A]----low-rate---->|SW-UART-Rx|---->|SW-UART-Tx|----high-rate---->|BT Master| >>>
and (for the other side)
>>> |BT Slave|----high-rate---->|SW-UART-Rx|---->|SW-UART-Tx|----low-rate---->[B]
As long as your endpoints [A] and [B] use a lower bitrate than whatever the Bluetooth-to-serial modules are configured for while in transparent mode, no special buffering of serial data should be required as [A] and [B] limit the total end-to-end bitrate to that of [A] and [B] themselves.
It took a bit of head-scratching with the oscilloscope attached but I managed to get a full-duplex software UART going on the ATTiny85, with no external hardware required. Symmetric or dual-bitrates are supported. I've tested the symmetric config at 38400 using puTTY and a USB-to-serial interface and all looks good so far. No real reason why the split rate shouldn't work, as each of Tx and Rx use their own unique timer...
I'll post code as soon as I have a spare moment.. gotta eat lunch now :p
[Update] Download source: attinyx5-dual-rate-swuart.zip
So.. it seemed to me that it should be possible to add a controller that, depending on the communication direction (this is a unidirectional link), would do an up- or down-conversion by sitting in between the BT interface and the target endpoint.
No hardware UART I've heard of supports a split data rate on the Tx and Rx lines, so a hardware UART or USART was not in the running. Software UART implementations from Atmel's app notes only do half-duplex while this required something that could shuffle data both ways in order to do the rate conversion.
For full-duplex software UARTs there is a handy library out there which includes one -- the Procyon AVRlib -- but it was written for AVR mega MCUs, and didn't have any facility for asymmetric baud rates. My application only needed a few pins so I wanted to use the ATTiny which has a somewhat different interrupt and timer register set as compared to the ATmega series. Moreover, the ATTiny25/45/85 have two independent hardware timers -- it looked perfectly feasible to implement a software UART that had asymmetric baud rates on the Tx and Rx sides, so why not roll my own software UART. Shouldn't be too hard, right?
Here's the general concept:
[A]----low-rate---->|SW-UART-Rx|---->|SW-UART-Tx|----high-rate---->|BT Master| >>>
and (for the other side)
>>> |BT Slave|----high-rate---->|SW-UART-Rx|---->|SW-UART-Tx|----low-rate---->[B]
As long as your endpoints [A] and [B] use a lower bitrate than whatever the Bluetooth-to-serial modules are configured for while in transparent mode, no special buffering of serial data should be required as [A] and [B] limit the total end-to-end bitrate to that of [A] and [B] themselves.
It took a bit of head-scratching with the oscilloscope attached but I managed to get a full-duplex software UART going on the ATTiny85, with no external hardware required. Symmetric or dual-bitrates are supported. I've tested the symmetric config at 38400 using puTTY and a USB-to-serial interface and all looks good so far. No real reason why the split rate shouldn't work, as each of Tx and Rx use their own unique timer...
I'll post code as soon as I have a spare moment.. gotta eat lunch now :p
[Update] Download source: attinyx5-dual-rate-swuart.zip
Subscribe to:
Posts (Atom)