- Posts: 49
Developing a universal module
- MassiveOverkill
- Offline
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
A7105_SetTxRxMode(mode)
CC2500_SetTxRxMode(mode)
CYRF_SetTxRxMode(mode)
There are 3 legal modes:
TX_EN: setup PA for transmitting (and disable LNA if needed)
RX_EN: setup LNA for transmitting (and disable PA if needed)
TXRX_OFF: enter sleep mode with PA/LNA off
Now we just need to plumb them into the protocols. The cyrf protocols are already done. I did the hubsan protocol and verified it works, flysky never enters Rx mode, so that one is easy. I'll deal with the CC2500 protocols next. None of the nrf24L01 modules have a controllable PA/LNA so this is not needed there.
However, in the next revision of the board, the nrf24l01 CE pin will be programmable via the AVR chip. So we could add a Tx/Rx mode function that uses is if available. I looked through the 24L01 protocols and none of them seem to enter read mode today, so apparently it isn't needed right now?
I found I can't run the SPI any faster than 560kHz (72/128). I can theoretically run at 1.2MHz (72/64) but I need to add delay between sending bytes in that case. The AVR takes ~70us to actually setup everything after the SPI transfer which means that the time to switch a pin on the AVR is currently ~150us. I can reduce that significantly by doing the logic in the STM32 instead (basically having the STM32 compute 'set portA to this value when CSN is high and this other value when CSN is low'), so I'm going to go that route. I'd like to get the timing as fast as possible to optimize the utility.
I'm trying to decide how general purpose to make this. I could add a full control interface to the tx.ini file (specify the CS, CE, Reset, etc for each module) or I could support one board layout (port0 is cyrf, port1 is a7105, ...). The 1st is definitely more flexible but adds quite a bit of code for limited benefit. Hardcoding the switch functionality is easier, but means we can't easily support other implementations. The switch code has already added ~600bytes of code (and it doesn't build on the Devo7e yet, and will likely require more). Adding configurability will likely double that.
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
Hardcoding vs. configurable - hard to tell. As long as it's modular enough and can be easily replaced with other logic, hardcoded is OK.
You probably moved the code for CS_HI/CS_LO from macros to this piece of code as well, didn't you?
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
I found a good middle ground for the configurability of the modules.
there is a single translation function:
int SPI_ProtoGetPinConfig(int module, int state);
CSN_PINS
ENABLED_PINS,
DISABLED_PINS,
RESET_PINS,
...
and returns the mapping based on what was paased into the 'pin' variable.
So for instance, your tx.ini file may look like:
[modules]
enable-cyrf6936 = B12
has_pa-cyrf6936 = 1
enable-switch = A13
enable-a7105 = S1
has_pa-a7105 = 1
enable-nrf24l01 = S0402
; has_pa-nrf24l01 = 1
enable-cc2500 = S3
has_pa-cc2500 = 1
It provides flexibility to encode module parameters without needing a bunch of new ini-handling code.
of course, I'd never expect a regualr user to know what 'S0402' means any more than 'A13'. It is just something they C&P from the manual.
In case you are wondering:
the 'pin' variable is interpreted as a hex number, and treated as 4 4-bit values in this case (code for each module can define it differently). '4' means to use the 4th switch-position as CE (because of how the AVR is wired, the bits are 0=A0, 1=A1, 2=A2, 3=A3, 4=B1, 5=B2, 6=A7) and '2' means to use the 2nd switch position (A2) for CSN
I also rewrote the AVR SPI parser to let the master do all of the logic, and I can now reconfigure the switch in 90us. Maybe playing around with it we can do even better, but it really isn't too bad at the moment.
I still need to work on getting this to build on a 7e, and then I'll commit it.
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
Please Log in or Create an account to join the conversation.
- Pattaya01
- Offline
- Posts: 181
atmelcorporation.wordpress.com/2014/01/1...ttiny-software-hack/
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
The answer is probably not.SeByDocKy wrote: Sorry to ask a stupid question for this thread. Is the main goal of this work to sell somewhere this "universal module" ?
There are a few options:
1) someone else decides to run with this and sell completed modules (A fully populated board probably costs ~$30 in parts for all 3 modules. Cost would certainly be more due to assembly labor. (adding the cyrf module for the X9D would add $25 to the cost)
2) I may sell just the board (a couple bucks plus shipping) and you can buy all the parts from ebay and assemble yourself. Once the boards work, I'll likely have some more printed up from a chinese supplier, which would give me 30 boards for $12 + shipping. The point being the boards aren't expensive.
3) you can have the boards printed yourself (they currently cost $9 for 3 boards shipped anywhere in the world) and buy the rest of the stuff you need from ebay. Having boards printed is as easy as typing in your address, uploading the board file I provide, and paying via paypal.
The only thing you need to assemble the board is:
1 AVRTiny24A chip ~ $2
1 CC2500 + PA ~ $8
1 A7105 + PA ~ $12
1 NRF24L01 + PA ~ $6
+ shipping
and then a pencil soldering iron and a bit of wire (both of which you need regardless to attach the board to your Tx). There is no difficult soldering here. Assembly should be quite straight forward
Lastly, let me stress that I'm not done with the board design yet. I have a prototype working, and I have test boards being manufactured, but there are known issues with those even though I don't even have them yet)
Please Log in or Create an account to join the conversation.
- SeByDocKy
- Offline
- Posts: 1016
PhracturedBlue wrote:
The answer is probably not.SeByDocKy wrote: Sorry to ask a stupid question for this thread. Is the main goal of this work to sell somewhere this "universal module" ?
There are a few options:
1) someone else decides to run with this and sell completed modules (A fully populated board probably costs ~$30 in parts for all 3 modules. Cost would certainly be more due to assembly labor. (adding the cyrf module for the X9D would add $25 to the cost)
2) I may sell just the board (a couple bucks plus shipping) and you can buy all the parts from ebay and assemble yourself. Once the boards work, I'll likely have some more printed up from a chinese supplier, which would give me 30 boards for $12 + shipping. The point being the boards aren't expensive.
3) you can have the boards printed yourself (they currently cost $9 for 3 boards shipped anywhere in the world) and buy the rest of the stuff you need from ebay. Having boards printed is as easy as typing in your address, uploading the board file I provide, and paying via paypal.
The only thing you need to assemble the board is:
1 AVRTiny24A chip ~ $2
1 CC2500 + PA ~ $8
1 A7105 + PA ~ $12
1 NRF24L01 + PA ~ $6
+ shipping
and then a pencil soldering iron and a bit of wire (both of which you need regardless to attach the board to your Tx). There is no difficult soldering here. Assembly should be quite straight forward
Lastly, let me stress that I'm not done with the board design yet. I have a prototype working, and I have test boards being manufactured, but there are known issues with those even though I don't even have them yet)
Since I have already the 3 RF chips, for sure... I am more interested by option 2) and if I am more confident in my capacity for 3). In fact, if this module can be used any devo supported by deviationx and also the X9D, it's just "amazing" ... clap clap ...
Another stupid question... If the CYRF is also installed on this universal module, can the built-in CYRF module can be bypassed ? (avoiding difficult diode mod for example)
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
Yes. The only concern is that I'm not sure the module will fit in a Devo7e with the cyrf attached. If the AWA24S works (I just got one) it is much smaller than the Walkera module and would probably be a better option for the Devo7e.SeByDocKy wrote: Another stupid question... If the CYRF is also installed on this universal module, can the built-in CYRF module can be bypassed ? (avoiding difficult diode mod for example)
Please Log in or Create an account to join the conversation.
- victzh
- Offline
- Posts: 1386
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
So do i remove it to use it with your circuit or can it stay in place? I'm easy either way and I'll plan my layout. Either way I don't plan on using one pcb to mount all modules. I'm thinking pcb to mount attiny/ISP and new power supply from battery. Mount modules on back panel of Tx, I've looked and there more than enough room.
Something to think about most USBasp are 5v (but some are 3.3v too) modules I've used are ok with 5v logic so don't use USBasp to power when programming but maybe add jumper to disconnect modules? And would it be an idea to contact LazyZero and ask him to add this to lazyzero.de/en/modellbau/kkmulticopterflashtool before you release code ? Me I prefer Winavr command line but its not everybody cup of tea.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
I haven't tried yet, but my plan is to create a custom dfu to program the AVR. Then you don't need a programmer. It is a good note on the 5V programmers potentially damaging your transceivers. I've been programming mine with all modules installed and haven't had an issue, but there is no guarantee.
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.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
I have only tested it with my prototype module so far (which has already been fuse set at 8MHz). I think the code is slow enough to run at the default 1MHz, but it is untested. If it doesn't work, I'll need to write a bit-banging SPI driver, since I've already slowed down the SPI as far as it'll go (or maybe I'll play with the core frequency)
Anyhow, you install the custom dfu, copy avr.hex to your fs, and turn on the Tx. It includes the USB stack so you can change the hex file by holding ENT during power-on.
I still need to write the code to set the fuse bits. Since screwing up fuse bits can brick the AVR (at least for ISP), I waited till last for that.
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Please Log in or Create an account to join the conversation.
- vlad_vy
- Offline
- Posts: 3333
Operation Mode Pin14(TXSW) Pin15(RXSW)
Inhibited________0___________0
TX_____________0___________1
RX_____________1___________0
Sleep___________1___________1
amiccom.weebly.com/uploads/3/9/5/9/39593...v0.2_preliminary.pdf
As I can see, both TXEN and RXEN can't be 0.
void A7105_SetTxRxMode(enum TXRX_State mode)
{
if(mode == TX_EN) {
A7105_WriteReg(A7105_0B_GPIO1_PIN1, 0x33); //first to '1'
A7105_WriteReg(A7105_0C_GPIO2_PIN_II, 0x31); //second to '0'
} else if (mode == RX_EN) {
A7105_WriteReg(A7105_0C_GPIO2_PIN_II, 0x33); //first to '1'
A7105_WriteReg(A7105_0B_GPIO1_PIN1, 0x31); //second to '0'
} else {
A7105_WriteReg(A7105_0B_GPIO1_PIN1, 0x33); //both to '1'
A7105_WriteReg(A7105_0C_GPIO2_PIN_II, 0x33); //both to '1'
}
}
void A7105_Reset()
{
A7105_WriteReg(0x00, 0x00);
usleep(1000);
//Set both GPIO as output and high
A7105_SetTxRxMode(TXRX_OFF);
}
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
Or in the case of the hubsan protocol, it looks like there is a typo in the code:
line 396 should be:
if (++txState == 8) { // 3ms + 7*1ms
A7105_SetTxRxMode(TX_EN);
txState = 0;
}
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.
- Home
- Forum
- Development
- Development
- Developing a universal module