Developing a universal module

victzh wrote: Do you still use schematics from post #18347? Why did you connect TXEN/RXEN (PA_EN/LNA_EN) to their GPIOs for A7105 and CC2500? Wouldn't it be simpler to use a chip with more IO pins?

The schematic changed slightly, but that is about it. As far as using explicit pins. I think this solution is preferable. This will be my recommended way to wire the modules for folks without a programmable switch. It is just as easy to control with gpio as with the switch, but will work for more people. In the case of the awa24s, I ended up doing exactly that as I didn't have enough GPIO.

Another question - you have at least one pin which could be used for nRF24L01's CE, wouldn't it be wise to connect it? TX to RX and back is much faster with CE than with powerdown/powerup.

Because I haven't worked with the nrf, and didn't know that. I'll do it in the next revision though.
As far as using a larger atmel chip, I'm already out of space for the form-factor I want, so unless I go SMT, it is hard to use a larger chip. However, for the PCB, I ended up putting the AVR on the back which does provide enough space I could probably fit a 20-pin DIP. We'll see how this revision works, and make updates as needed. I still have 3 unused I/O on the ATTiny24. I am not sure the AVR can provide enough current for the PAEN pin an the AWA24S. If not, I'll need to add a FET too. I'm just trying to keep this as simple to build as possible with as few discrete components. I currently only need a single 10k resistor in addition to the board and AVR chip. And even that we don't strictly need.

For those interested, here is the Version 1.0 schematics and gerber for the programmable switch module.

Having used it now, I'm not 100% convinced on KiCad either. I hate how selection, delete and rubberbanding work. The autorouter works well, but is kludgey to use. Having the libraries be in text syntax is a nice benfit though.

While I don't use board-design software at my day job, the EDA tools I do use are so much better designed than tools like Eagle/KiCad that I find it extremely frustrating to work with them.

Well, I already found one bug in my schematic. The CSN pin cannot be overloaded onto !RESET without setting the RESET-DISABLE fuse, which would then render future programming impossible.

Since the pinout on the connector is not fixed, this can be resolved by adding an extra wire between an alternate pin (PB0) and the connector.

That was a pretty rookie mistake, but this is my 1st time really working with an AVR.

I got my ATTiny84A today (ahead of expectations), and I'm about done with the 1st pass coding. Since I'm not really familiar with the AVR, it'll probably take me a little while to figure out how to set the registers properly to make the pins function as I want them to.

SadSack wrote: Give eagle ago, I've got few working library parts done and if anyone posts details of others I could add them. Couldn't get on with kicad but did struggle with Eagle but a lot more how to guides out there.

I've designed several boards with Eagle. This is the 1st time I've used KiCad though. I'll stick with it for this project. I don't know what I'll do next time around.

the board itself is ~ 23x48mm, however, once you add the modules, it comes out closer to 45mmx48mm, and will be quite thick as the modules are layered on top of each other

I've got the code working in the simulator now. I'm not happy with the interrupt handler latency, and may hand-code it. The compiler won't seem to do it in less than 30 cycles. Given the limitations of the AVR instruction set, I'm not sure I can do a lot better, but I'll see what I can manage.

This is the code I'm trying to reduce:There really isn't much to it

I can't take the risk that we miss an edge, so I'd rather have something more robust. I ended up using this:note that toggleA,B, NOTA, and NOTB are all assigned to registers (so I burn 4 registers with these values).

The current code is 21 cycles if I counted correctly. The PortA value is updated within 12cycles (+4 to get to the interrupt handler). I could take
3 instructions off the front and 2 off the end if I hand coded it (and another 2 off the front and 2 off the back if I leave interrupts enabled during the handler, which is probably safe to do given this is the only interrupt handler). But we'll leave it like this for now. It is a lot more readable.

Sure, everything is tradeoff. The benefit of this design is its simplicity. The board + MCU should be obtainable for < $5 and is easy to build. Adding more parts increases the complexity, and reduces the utility. Getting an MCU with a fatser clock would also work.
Anyhow, 12 + 4 cycles means a 2us delay between setting CSN and starting SPI transfer. I don't think that'll be too much. And as I said if I hand-code the interrupt routine, I can reduce that to 1.5us.

If it is still unacceptable, I'll experiment with the Pic MCUs. They run at 32MHz with the internal oscillator. Even though most instructions take 4cycles to execute, I believe the interrupt handler is only 4 cycles, so it is possible the CSN could actually be switched in 0.5us or less.

The board is actually compatible with the PIC MCU with no modification (though it requires an external programmer)

Well, I just measured it on my logic analyzer, and the current code takes 3us to enable the CSN pin. That is too slow for the way the CS pins are programmed today, so I need to do a bit of work. On the plus side the module looks like it is working as intended inside my Devo8 (I can select the pin to toggle and make it do so with CSN). No more tonight, but with a little luck, I'll have this working tomorrow.

yes pic runs at 4clocks per instruction, but my understanding is that interrupts are handled faster.

Anyhow, I figured out last night that I don't need to and/or the register. So i ended up with this:(for some reason gcc was doing an extra copy, and generating illegal code with the 'naked' attribute, so I ended up doing it in asm anyhow. End result: 13 cycles to set CSN (at least according to the simulator). I don't think I can do any better than that.

I think only int0 is capable of single-edge triggered interrupts. On the ATTiny84, I don't see anything that would allow controlling pcint0/1 edge direction.
It looks like even using an external oscillator isn't an option as at 3.3V the ATTiny can only handle 10MHz.
I think we're in the right range.
I've already coded CS_LO and CS_HI functions to add a delay after setting and they seem to be working in most cases. I'll hopefully have everything up and running later today.

Well, I bound to my Hubsan using the module today
Unfortunately I discovered another bug in the board design that is more critical: I used a resistor between MISO and MOSI to convert the A7105 3-wire SPI to 4-wire SPI. I had done this on my RPi (which doesn't really support 3-wire SPI) a while ago. Now I remember why I needed to run the RPi SPI at slower frequency: There is too much cap on the miso pin, and it cannot respond at 4MHz with the resistor in place. You could reduce the resistor size to resolve this, but at the direct cost of overall current. So The resistor needs to be removed, and the MOSI pin needs to be connected to the A7105 SDIO pin. I can do that by cutting the trace and adding a jumper, so it isn't the end of the world. I'll wait for the boards to come back and make sure the design is otherwise good before finalizing the 2nd revision.

Using the A7105 GPIOs to control the PA/LNA enables, seems to work great in my testing so far, but it means I need to go through each protocol and carefully verify I get it coded right each time we switch from Tx to Rx mode.

With the optimized ISR routine, the MCU can handle a CSN change within ~1.75us which is good enough for me, so I think this design is a winner.