Orange Module running MULTI protocol
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
Double check you don't have any shorts between the connections on the module, the pads are rather close together, use a meter to measure between them.
Checking the module, it does look to have a diode in the power input, so could be protected from connecting the power reversed. However, this diode will drop voltage (0.6V), then the regulator will drop some voltage as well.
It looks like you are powering the module from a single LIPO cell. This may not provide enough voltage, you really need at least 5V to be sure of getting 3.3 out of the regulator. I usually use a 4-cell NiMh battery.
Mike.
Checking the module, it does look to have a diode in the power input, so could be protected from connecting the power reversed. However, this diode will drop voltage (0.6V), then the regulator will drop some voltage as well.
It looks like you are powering the module from a single LIPO cell. This may not provide enough voltage, you really need at least 5V to be sure of getting 3.3 out of the regulator. I usually use a 4-cell NiMh battery.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 71
- Joined: Wed Feb 01, 2017 4:38 am
- Country: -
Re: Orange Module running MULTI protocol
I am powering the Module with a fully charged 2s 7.4V 280mAh Li-Po Battery switched my setup to use both cells
Conitinuity between all pads is OL
Resistance (MΩ) a crossed pads on Module board
Grnd-Clk 0.39
Clk-DATA 15.92
Grnd-DATA 11.25
Resistance (MΩ) between Module Bay pins and Module board:
Grnd 0.00 green wire
DATA 0.00 orange wire
Clk 0.00 blue wire
Conitinuity between all pads is OL
Resistance (MΩ) a crossed pads on Module board
Grnd-Clk 0.39
Clk-DATA 15.92
Grnd-DATA 11.25
Resistance (MΩ) between Module Bay pins and Module board:
Grnd 0.00 green wire
DATA 0.00 orange wire
Clk 0.00 blue wire
-
- Posts: 71
- Joined: Wed Feb 01, 2017 4:38 am
- Country: -
Re: Orange Module running MULTI protocol
ok a bit of an update... my LED light on the Module board came back on just now... I am going to see if posssibly even though it says fail maybe it worked any way...
Edited: well the LED light doesn't come on in the Mod Bay... and its not binding to the aircraft at all
Edited: well the LED light doesn't come on in the Mod Bay... and its not binding to the aircraft at all
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
With the module in the bay, what settings are you using in the protocol menu?
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 71
- Joined: Wed Feb 01, 2017 4:38 am
- Country: -
Re: Orange Module running MULTI protocol
Protocol Menu
Trainer Polarity: POS
Internal Module: uncheck
External Module: Check
Proto: DSM2 Chans 6
DSM Type: 9XR-DSM
1st Chan 1
Trainer Polarity: POS
Internal Module: uncheck
External Module: Check
Proto: DSM2 Chans 6
DSM Type: 9XR-DSM
1st Chan 1
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
On my board, one side of the LED goes to +3.3V and the other to resistor R8, you board does look the same.
With the board powered, you might be able to measure the voltage (carefully) from the 'outside' leg of the LED and ground to check if you have 3.3V on the board. It may be easiest to do this with the board not in the module bay and powered from the battery.
Mike.
With the board powered, you might be able to measure the voltage (carefully) from the 'outside' leg of the LED and ground to check if you have 3.3V on the board. It may be easiest to do this with the board not in the module bay and powered from the battery.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
-
- Posts: 71
- Joined: Wed Feb 01, 2017 4:38 am
- Country: -
Re: Orange Module running MULTI protocol
waiting on batteries to charge
-
- Posts: 71
- Joined: Wed Feb 01, 2017 4:38 am
- Country: -
Re: Orange Module running MULTI protocol
this little project is on hold for a couple of days... I need to get some new batteries, make some repairs to the airplane I am trying to bind, and its Friday so I am heading out of town to be with my GF for 4 days.
I am seriously thinking about putting this on permanent hold though and getting a 4 in 1 Multi-protocol board if it can be flashed to work with my Champ S+
I am seriously thinking about putting this on permanent hold though and getting a 4 in 1 Multi-protocol board if it can be flashed to work with my Champ S+
Re: Orange Module running MULTI protocol
Hi Mike
Do you have the stock firmware to ORx module ?
because i don't save it .
Thank you
Do you have the stock firmware to ORx module ?
because i don't save it .
Thank you
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
I've never had a production module from which to read the firmware. The only firmware I have is that sent to me during development, and is under a NDA, so I can't release it.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
ok Mike
it's not possible to return at the original firmware ?
whith the OrangeRX USB Firmware Update Kit it's possible or not ?
it's not possible to return at the original firmware ?
whith the OrangeRX USB Firmware Update Kit it's possible or not ?
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
I'm not sure if the bootloader will still be in the processor flash or not. It does have a specific area, but may be erased when the chip is erased when flashing the Multi firmware.
Just curious, is the Multi firmware not working for you or do you have another reason to go back to the original firmware?
Mike.
Just curious, is the Multi firmware not working for you or do you have another reason to go back to the original firmware?
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
Hi Mike
The reason is
I have flashed Multi firmware to use DSMx Whipit micro DLG.
The stock firmware not Bind with this micro glider.
Works with Multi firmware but the range is not good around 50m.
i have lost several time my DLG.
The reason is
I have flashed Multi firmware to use DSMx Whipit micro DLG.
The stock firmware not Bind with this micro glider.
Works with Multi firmware but the range is not good around 50m.
i have lost several time my DLG.
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
The range should be normal. If it is low then either the module is always giving poor range, or something is not set correctly.
Check you haven't selected "Power Low" in the protocol.
What range do you get in "Range Check" mode?
Mike.
Check you haven't selected "Power Low" in the protocol.
What range do you get in "Range Check" mode?
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
const PPM_Parameters PPM_prot[15]= {
// Dial Protocol Sub protocol RX_Num Power Auto Bind Option
/* 1 */ {MODE_DSM , DSM2_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 2 */ {MODE_DSM , DSMX_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 3 */ {MODE_DSM , DSMX_11 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 4 */ {MODE_DEVO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
/* 5 */ {MODE_J6PRO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
// Dial Protocol Sub protocol RX_Num Power Auto Bind Option
/* 1 */ {MODE_DSM , DSM2_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 2 */ {MODE_DSM , DSMX_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 3 */ {MODE_DSM , DSMX_11 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 4 */ {MODE_DEVO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
/* 5 */ {MODE_J6PRO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
Re: Orange Module running MULTI protocol
"Range Check" mode 10m
const PPM_Parameters PPM_prot[15]= {
// Dial Protocol Sub protocol RX_Num Power Auto Bind Option
/* 1 */ {MODE_DSM , DSM2_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 2 */ {MODE_DSM , DSMX_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 3 */ {MODE_DSM , DSMX_11 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 4 */ {MODE_DEVO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
/* 5 */ {MODE_J6PRO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
const PPM_Parameters PPM_prot[15]= {
// Dial Protocol Sub protocol RX_Num Power Auto Bind Option
/* 1 */ {MODE_DSM , DSM2_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 2 */ {MODE_DSM , DSMX_22 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 3 */ {MODE_DSM , DSMX_11 , 0 , P_HIGH , NO_AUTOBIND , 6 }, //
/* 4 */ {MODE_DEVO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
/* 5 */ {MODE_J6PRO , 0 , 0 , P_HIGH , NO_AUTOBIND , 0 },
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
I suggest checking the antenna connection(s).
What firmware are you using on the radio?
Mike.
What firmware are you using on the radio?
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
Hi Mike,
I tried to compile, the binary for the Orange TX. I just bought an Olimex AVR-ISP-MK2.
Unfortunately I got some errors which I don't understand.
Here is what I've done:
1. I clone the git repository of Pascal. I didn't changed anything yet (telemetry, inverted stuff for my X9D+, etc...).
2. I installed WinAVR.
3. Open a command shell (my laptop is running Win10).
4. Launch the Build_orangetx.cmd makefile.
I got this error:
Any help would be much appreciate.
I tried to compile, the binary for the Orange TX. I just bought an Olimex AVR-ISP-MK2.
Unfortunately I got some errors which I don't understand.
Here is what I've done:
1. I clone the git repository of Pascal. I didn't changed anything yet (telemetry, inverted stuff for my X9D+, etc...).
2. I installed WinAVR.
3. Open a command shell (my laptop is running Win10).
4. Launch the Build_orangetx.cmd makefile.
I got this error:
Code: Select all
c:\Multiprotocol>Build_orangetx.cmd
0 [main] sh 1512 sync_with_child: child 5348(0x1A4) died before initialization with status code 0xC0000142
1101 [main] sh 1512 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
0 [main] sh 6316 sync_with_child: child 12680(0x1A4) died before initialization with status code 0xC0000142
582 [main] sh 6316 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
-------- begin --------
Cleaning project:
rm -f MultiOrange.hex
rm -f MultiOrange.eep
rm -f MultiOrange.cof
rm -f MultiOrange.elf
rm -f MultiOrange.map
rm -f MultiOrange.sym
rm -f MultiOrange.lss
rm -f
rm -f
rm -f
rm -f
rm -f
rm -rf .dep
-------- end --------
0 [main] sh 3768 sync_with_child: child 12744(0x1A4) died before initialization with status code 0xC0000142
433 [main] sh 3768 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
0 [main] sh 12848 sync_with_child: child 1388(0x1A4) died before initialization with status code 0xC0000142
466 [main] sh 12848 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiling C++: MultiOrange.cpp
avr-gcc -c -mmcu=atxmega32d4 -I. -x c++ -gdwarf-2 -DF_CPU=32000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -fno-exceptions -Wall -Wa,-adlns=./MultiOrange.lst -MMD -MP -MF .dep/MultiOrange.o.d MultiOrange.cpp -o MultiOrange.o
In file included from MultiOrange.cpp:142:
Multiprotocol.ino: In function 'void setup()':
Multiprotocol.ino:272: error: no match for 'operator|=' in '*1632u |= 4'
Multiprotocol.ino:275: error: no match for 'operator|=' in '*1632u |= 128'
Multiprotocol.ino:281: error: no match for 'operator|=' in '*1568u |= 1'
In file included from MultiOrange.cpp:147:
cyrf6936_SPI.ino: At global scope:
cyrf6936_SPI.ino:270: warning: only initialized variables can be placed into program memory area
In file included from MultiOrange.cpp:148:
DSM_cyrf6936.ino:47: warning: only initialized variables can be placed into program memory area
DSM_cyrf6936.ino:65: warning: only initialized variables can be placed into program memory area
DSM_cyrf6936.ino:137: warning: only initialized variables can be placed into program memory area
DSM_cyrf6936.ino:157: warning: only initialized variables can be placed into program memory area
In file included from MultiOrange.cpp:149:
Devo_cyrf6936.ino:166: warning: only initialized variables can be placed into program memory area
In file included from MultiOrange.cpp:150:
J6Pro_cyrf6936.ino:38: warning: only initialized variables can be placed into program memory area
make: *** [MultiOrange.o] Error 1
Appuyez sur une touche pour continuer...
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
In "pins.h" you will find:
Move the "#endif to after:
Mike.
Code: Select all
// SCLK
#define SCLK_port PORTD
#define SCLK_ddr DDRD
#ifdef ORANGE_TX
#define SCLK_pin 7 //PD7
#define SCLK_on SCLK_port.OUTSET = _BV(SCLK_pin)
#define SCLK_off SCLK_port.OUTCLR = _BV(SCLK_pin)
#else
#define SCLK_pin 4 //D4 = PD4
#define SCLK_output SCLK_ddr |= _BV(SCLK_pin)
#define SCLK_on SCLK_port |= _BV(SCLK_pin)
#define SCLK_off SCLK_port &= ~_BV(SCLK_pin)
#endif
Code: Select all
// NRF24L01
#define NRF_CSN_pin 0 //D8 = PB0
#define NRF_CSN_port PORTB
#define NRF_CSN_ddr DDRB
#define NRF_CSN_output NRF_CSN_ddr |= _BV(NRF_CSN_pin)
#define NRF_CSN_on NRF_CSN_port |= _BV(NRF_CSN_pin)
#define NRF_CSN_off NRF_CSN_port &= ~_BV(NRF_CSN_pin)
#define NRF_CE_on
#define NRF_CE_off
#endif // <<moved to here
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
Compilation should be fixed now. Please try the latest version from Github.
Pascal
Pascal
Re: Orange Module running MULTI protocol
If the range is low, it can be that the PA/LNA pins are reversed on the orange module you have.
To swap the pins, open the file "MultiOrange.cpp.orangetx" or "MultiOrange.cpp" and uncomment (remove the "//") from this line which is at the begining of the file:
Pascal
To swap the pins, open the file "MultiOrange.cpp.orangetx" or "MultiOrange.cpp" and uncomment (remove the "//") from this line which is at the begining of the file:
Code: Select all
//#define DSM_BLUE
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
I forgot that one, thanks.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
@Mike
@planger
Thanks to both of you!
I didn't try Mike's solution, I try the latest version available on the GIT repo. It seems to be better, but not luck yet. I got this error message:
However I realized I don't have the Atmel Studio 7 installed. I will installed it and try again.
I will post a new message as soon as I got a new result.
Seb
@planger
Thanks to both of you!
I didn't try Mike's solution, I try the latest version available on the GIT repo. It seems to be better, but not luck yet. I got this error message:
Code: Select all
/usr/bin/sh: fork: Resource temporarily unavailable
I will post a new message as soon as I got a new result.
Seb
Re: Orange Module running MULTI protocol
Installing Atmel Studio 7 didn't solved my problem.
In fact this issue is coming from a DLL delivered with WinAVR (I'm running Win10).
To fix this "fork" issue, you must download this archive: msys-1.0-vista64.zip
Then replace the msys-1.0.dll with the downloaded one in the folder WinAVR-20100110\utils\bin
After, I got this:
Seems good!
Does it look OK to you?
In fact this issue is coming from a DLL delivered with WinAVR (I'm running Win10).
To fix this "fork" issue, you must download this archive: msys-1.0-vista64.zip
Then replace the msys-1.0.dll with the downloaded one in the folder WinAVR-20100110\utils\bin
After, I got this:
Code: Select all
>Build_orangetx.cmd
Le nom de fichier existe déjà, ou le fichier est introuvable.
Le nom de fichier existe déjà, ou le fichier est introuvable.
Le nom de fichier existe déjà, ou le fichier est introuvable.
-------- begin --------
Cleaning project:
rm -f MultiOrange.hex
rm -f MultiOrange.eep
rm -f MultiOrange.cof
rm -f MultiOrange.elf
rm -f MultiOrange.map
rm -f MultiOrange.sym
rm -f MultiOrange.lss
rm -f
rm -f
rm -f
rm -f
rm -f
rm -rf .dep
-------- end --------
-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Linking: MultiOrange.elf
avr-gcc -mmcu=atxmega32d4 -I. -gdwarf-2 -DF_CPU=32000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wno-main -Wstrict-prototypes -Wa,-adlns=MultiOrange.o -std=gnu99 -Wundef -MMD -MP -MF .dep/MultiOrange.elf.d MultiOrange.o Wmath.o --output MultiOrange.elf -Wl,-Map=MultiOrange.map,--cref -lm -N
Creating load file for Flash: MultiOrange.hex
avr-objcopy -O ihex -R .eeprom MultiOrange.elf MultiOrange.hex
Creating load file for EEPROM: MultiOrange.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 --no-change-warnings -O ihex MultiOrange.elf MultiOrange.eep || exit 0
Creating Extended Listing: MultiOrange.lss
avr-objdump -h -S MultiOrange.elf > MultiOrange.lss
Creating Symbol Table: MultiOrange.sym
avr-nm -n MultiOrange.elf > MultiOrange.sym
avr-objcopy -O binary MultiOrange.elf MultiOrange.bin
Size after:
AVR Memory Usage
----------------
Device: atxmega32d4
Program: 17090 bytes (46.4% Full)
(.text + .data + .bootloader)
Data: 622 bytes (15.2% Full)
(.data + .bss + .noinit)
-------- end --------
Compilation OK.
Use MultiOrange.hex or MultiOrange.bin to program your OrangeTX module.
Appuyez sur une touche pour continuer...
Does it look OK to you?
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
WINAVR has a very old avr-gcc compiler included. Go here: https://sourceforge.net/projects/mobile ... 8Win32%29/, and download "avr-gcc-4.8_2013-03-06_mingw32.zip" (I recommend this one, rather than 4.9.2).
In your WINAVR directory, copy the 5 sub-directories "avr", "bin", "lib", "libexec" and "share" somewhere else, then replace the contents of these 5 sub-directories with the ones from the downloaded .zip file. By taking the copies, you can always go back to the originals.
4.8.0 will generate much smaller code. I have to use it to get er9x to fit on a M64 processor.
Mike.
In your WINAVR directory, copy the 5 sub-directories "avr", "bin", "lib", "libexec" and "share" somewhere else, then replace the contents of these 5 sub-directories with the ones from the downloaded .zip file. By taking the copies, you can always go back to the originals.
4.8.0 will generate much smaller code. I have to use it to get er9x to fit on a M64 processor.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
Thanks Mike!
I will try and keep you inform of the results.
EDIT:
With the mingw tooslchain, I got this error message:
Moreover, I still need this patch msys-1.0-vista64.zip to fix the "fork" issue. Otherwise, I got this error message:
I got 2 questions:
1. When I'm launching the Build_orangetx.cmd for the 1st time in a clean workspace, I got those warning:
Is it expected, or did I do something wrong?
2. When editing the _Config.h (my target radio is a X9D+ running OTX2.2), the generated .bin/.hex are exactly the same (I used MD5 ckecksum to compare). I need to revert to the original branch, then launch again the Build_orangetx.cmd command. Then, the files seem different. Could you tell me, please, what is the correct procedure?
Seb.
I will try and keep you inform of the results.
EDIT:
With the mingw tooslchain, I got this error message:
Code: Select all
c:\WinAVR-20100110\bin\avr-size.exe: unrecognized option `--mcu=atxmega32d4'
Usage: c:\WinAVR-20100110\bin\avr-size.exe [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
-t --totals Display the total sizes (Berkeley only)
--common Display total size for *COM* syms
--target=<bfdname> Set the binary file format
@<file> Read options from <file>
-h --help Display this information
-v --version Display the program's version
c:\WinAVR-20100110\bin\avr-size.exe: supported targets: elf32-avr elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex
Code: Select all
/usr/bin/sh: fork: Resource temporarily unavailable
I got 2 questions:
1. When I'm launching the Build_orangetx.cmd for the 1st time in a clean workspace, I got those warning:
Code: Select all
Compiling C++: MultiOrange.cpp
avr-gcc -c -mmcu=atxmega32d4 -I. -x c++ -gdwarf-2 -DF_CPU=32000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -fno-exceptions -Wall -Wa,-adlns=./MultiOrange.lst -MMD -MP -MF .dep/MultiOrange.o.d MultiOrange.cpp -o MultiOrange.o
In file included from MultiOrange.cpp:147:
cyrf6936_SPI.ino:270: warning: only initialized variables can be placed into program memory area
In file included from MultiOrange.cpp:148:
DSM_cyrf6936.ino:47: warning: only initialized variables can be placed into program memory area
DSM_cyrf6936.ino:65: warning: only initialized variables can be placed into program memory area
DSM_cyrf6936.ino:137: warning: only initialized variables can be placed into program memory area
DSM_cyrf6936.ino:157: warning: only initialized variables can be placed into program memory area
In file included from MultiOrange.cpp:149:
Devo_cyrf6936.ino:166: warning: only initialized variables can be placed into program memory area
In file included from MultiOrange.cpp:150:
J6Pro_cyrf6936.ino:38: warning: only initialized variables can be placed into program memory area
2. When editing the _Config.h (my target radio is a X9D+ running OTX2.2), the generated .bin/.hex are exactly the same (I used MD5 ckecksum to compare). I need to revert to the original branch, then launch again the Build_orangetx.cmd command. Then, the files seem different. Could you tell me, please, what is the correct procedure?
Seb.
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
There is an error in the makefile. A "make clean" does not remove the object files "*.o", before making, but it has removed the dependencies list, so it just re-links from the already existing .o files.
In the makefile change:
$(REMOVE) $(SRC:%.c=$(OBJDIR)/%.o)
to:
$(REMOVE) $(CPPSRC:%.cpp=%.o)
I normally just use the make command and this then checks the dependencies and so re-compiles if you change a header file.
Mike.
In the makefile change:
$(REMOVE) $(SRC:%.c=$(OBJDIR)/%.o)
to:
$(REMOVE) $(CPPSRC:%.cpp=%.o)
I normally just use the make command and this then checks the dependencies and so re-compiles if you change a header file.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
Thanks Mike!
It works.
Any suggestions about the two issues below (avr-size.exe problem with mingw and the warning during the 1st compilation)?
BR,
Seb
It works.
Any suggestions about the two issues below (avr-size.exe problem with mingw and the warning during the 1st compilation)?
BR,
Seb
- MikeB
- 9x Developer
- Posts: 18002
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Orange Module running MULTI protocol
I recall a problem with avr-size, it looks like I use a specific copy (attached).
Not sure about the warnings on first compile, I don't get them.
Mike.
Not sure about the warnings on first compile, I don't get them.
Mike.
- Attachments
-
- avr-size.zip
- (229.73 KiB) Downloaded 160 times
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Orange Module running MULTI protocol
Hi Mike,
With the avr-gcc-4.8_2013-03-06_mingw32.zip + your avr-size.zip version, everything is working fine. Moreover I don't get anymore this strange warning.
So, everything seems OK on the software side.
Now, I'm must modified the _Config.h in order to generate the correct FW for my X9D+ (running OTX2.2 RC10). Then flash my Orange TX (green version) with the AVR-ISP-MK2.
Since, the AVR-ISP-MK2 is supplying a 3V3, I guess I don't need to power the PCB with an external supply? Correct?
Thanks a lot for your support!!
With the avr-gcc-4.8_2013-03-06_mingw32.zip + your avr-size.zip version, everything is working fine. Moreover I don't get anymore this strange warning.
So, everything seems OK on the software side.
Now, I'm must modified the _Config.h in order to generate the correct FW for my X9D+ (running OTX2.2 RC10). Then flash my Orange TX (green version) with the AVR-ISP-MK2.
Since, the AVR-ISP-MK2 is supplying a 3V3, I guess I don't need to power the PCB with an external supply? Correct?
Thanks a lot for your support!!