- Posts: 4402
Developing a universal module
- PhracturedBlue
- Topic Author
- Offline
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.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?
Because I haven't worked with the nrf, and didn't know that. I'll do it in the next revision though.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.
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.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
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.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
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.
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
Please Log in or Create an account to join the conversation.
- blackmoon
- Offline
- Posts: 402
Thank you.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
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.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.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- cstratton
- Offline
- Posts: 46
PhracturedBlue wrote: 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.
There's a really tiny UART bootloader for the ATtiny85 which you might be able to port. That could let you burn the reset fuse but still program the chip.
Perhaps you could even get it so that you could program it from the STM32, by dumping a new file onto the mass storage, or adding a virtual serial passthrough mode.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
This is the code I'm trying to reduce:
ISR(PCINT1_vect) {
//CSN change
if (CSN) {
PORTA |= global_toggleA;
PORTB |= global_toggleB;
} else {
PORTA &= ~global_toggleA;
PORTB &= ~global_toggleB;
}
}
Please Log in or Create an account to join the conversation.
- hexfet
- Away
- Posts: 1876
I'm making some guesses here but have an idea , though it seems slightly fragile (and crazy...stopped by the growler shop on the way home : )PhracturedBlue wrote: This is the code I'm trying to reduce:
If this interrupt happens on both edges of CSN, and you can initialize PORTA and PORTB based on what the value of CSN will be on the first interrupt, I think the code below is equivalent. If you can't predict the first interrupt value, a possibility would be to use the routine you posted first, then replace it with the following for subsequent interrupts. Every CSN interrupt would have to be serviced before the next CSN change for this to work.
ISR(PCINT1_vect) {
//CSN change
PORTA ^= global_toggleA;
PORTB ^= global_toggleB;
}
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
ISR(PCINT1_vect) {
//CSN change
if (CSN) {
PORTA |= global_toggleA;
PORTB |= global_toggleB;
} else {
PORTA &= global_toggleNOTA;
PORTB &= global_toggleNOTB;
}
}
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.
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
A trade-off would be to use a multiplexor to handle the CSN, everything else can be handled by MCU.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
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)
Please Log in or Create an account to join the conversation.
- rbe2012
- Offline
- So much to do, so little time...
- Posts: 1433
As far as I remember from my experiences with coding for ATMega8 and 32 the call of an interrupt routine automatically disables interrupts (no need for "cli") and enables them again when executing the "reti" command.PhracturedBlue wrote: ... (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).
Could you spare some time when using single bit operations (like sbi/cbi - set/clear bit in i/o-register) - should be faster than a read-modify-write.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
1.5-2us may be OK, especially if you can insert a small delay between asserting CS on main MCU and actual SPI transfer. At usual 4MHz SPI clock speed this is comparable with a transfer of one byte, so the penalty is not that bad.
On the other hand, CD4052 multiplexer costs $0.50 in quantities of 1. Design is a little bit more complex, I admit.
Anyway, we have several ways of solving it, so if pure MCU solution works unreliably there is always another option.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
Anyhow, I figured out last night that I don't need to and/or the register. So i ended up with this:
ISR(PCINT1_vect, ISR_NAKED) {
//CSN change
#if 0
if (CSN) {
PORTA = global_A;
//PORTB = global_B;
} else {
PORTA = global_NOTA;
//PORTB = global_NOTB;
}
#else
asm("mov r14, r17");
asm("sbis 0x16, 0");
asm("mov r14, r16");
asm("out 0x1b, r14");
#endif
reti();
}
Please Log in or Create an account to join the conversation.
- rbe2012
- Offline
- So much to do, so little time...
- Posts: 1433
ISR(PCINT0_vect, ISR_NAKED) {
//CSN rising up
asm("out 0x1b, r17");
reti();
}
ISR(PCINT1_vect, ISR_NAKED) {
//CSN falling down
asm("out 0x1b, r16");
reti();
}
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
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.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
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.
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Development
- Developing a universal module