HobbyKing.com New Products Flash Sale
Closed Thread
Thread Tools
Old Dec 08, 2012, 11:17 PM
Registered User
United States, TX, Katy
Joined Aug 2009
109 Posts
Quote:
Originally Posted by PGR View Post
Hint: This isn't the only thread in this forum.

Pete the helpful
Thanks for the Help, But again WHAT WAS THE ANNOUNCEMENT?
wwmilanl is offline Find More Posts by wwmilanl
Sign up now
to remove ads between posts
Old Dec 09, 2012, 12:07 AM
PGR
Low AltiDude
PGR's Avatar
United States, CA, Costa Mesa
Joined Jun 2004
7,976 Posts
-sigh-

Check out the first post in this thread:
http://www.rcgroups.com/forums/showthread.php?t=1784809

Pete
PGR is offline Find More Posts by PGR
Old Dec 09, 2012, 01:02 PM
Pants on the ground
xsubsailor's Avatar
exit 26 Jersey
Joined Jul 2007
6,220 Posts
Quote:
Originally Posted by wwmilanl View Post
Thanks for the Help, But again WHAT WAS THE ANNOUNCEMENT?
I would tell you but Jim would delete my post
xsubsailor is offline Find More Posts by xsubsailor
Old Dec 09, 2012, 01:05 PM
Stop scaring my donkey!
JohnathanSwift's Avatar
Greenland
Joined Mar 2012
8,732 Posts
Quote:
Originally Posted by xsubsailor View Post
I would tell you but Jim would delete my post
Yup....
JohnathanSwift is offline Find More Posts by JohnathanSwift
Old Dec 09, 2012, 07:09 PM
Registered User
Joined Feb 2012
58 Posts
I'm not sure why that announcement wasn't included in this thread, at least as it pertains to the transmitter. It's the most relevant bit of information in a long time:

"I have not actively worked on the transmitter since my return from Guam for James Cameron's project in April. My focus has been on other products .... Once the dust settles, I will return full time to finish up the transmitter. I do not know at this point how long this will be."

April was back when the transmitter hadn't been worked on for a long while due to the Cameron side project. I think Jim is making the right choice to work on the Nanos and other receivers (and other unannounced products?) since he needs to support the existing customer base first. I don't think the 3216 Tx itself will be available for a long time. Nor will the replacement boards for other transmitters, since they are essentially the same thing.

Jim, do you think the long delays will eventually result in choosing a different chip family? It seems like a lot of people are shifting their attention to ARM-based designs that are more powerful, allowing more features or maybe less assembly coding.
wingz is offline Find More Posts by wingz
Old Dec 10, 2012, 10:54 AM
Registered User
idletime's Avatar
Canada, ON, Toronto
Joined Apr 2011
1,650 Posts
Quote:
Originally Posted by kgfly View Post
Given all the news it looks as if the TX will never ship in the original form. I will be surprised to see an XPS TX for sale before 2014, if ever.

Jim has expressed a very strong preference for assembly programming in the past, doubt that has changed.
While most find assembly difficult to program - it does lead to the fastest executable code - thus you can use a 'slower' cheaper CPU and still achieve great results.

I knew a guy once that could program in assembly like a fat man can eat chips.


Only an issue if you expected to program yourself / third party for the Tx.

My 2c
idletime is online now Find More Posts by idletime
Old Dec 10, 2012, 12:44 PM
Xtreme Power Systems
Lake Havasu, AZ
Joined Jun 2005
15,920 Posts
Again, I can't stress this enough. This thread is strictly for discussing FEATURES of the XPS 3216 transmitter - NOTHING ELSE.

I don't see anymore of a 'delay' for the transmitter progress because I will be able to focus on it instead of other projects. It's difficult to work on something that should not even be known about yet, not to mention features and such given. I never wanted to mention anything about the transmitter project until they were sitting in boxes ready to ship.

The PIC I am using for this transmitter is 40 MIPS in speed. That coupled with 100% assembly code yields the ability to have 1ms frames. The fastest frames that are possible RF wise are about 3.5ms using 6 channels, but I chose 5ms to be the maximum frame rate. So, I have about 5 times the CPU power necessary. Microchip is making a new version of the CPU that is pin compatible and 80 MIPS, but it really is not necessary. I could do this project with a 10 MIPS CPU.
JimDrew is online now Find More Posts by JimDrew
RCG Plus Member
Old Dec 10, 2012, 08:33 PM
Registered User
United States, TX, Katy
Joined Aug 2009
109 Posts
Quote:
Originally Posted by idletime View Post
While most find assembly difficult to program - it does lead to the fastest executable code - thus you can use a 'slower' cheaper CPU and still achieve great results.

I knew a guy once that could program in assembly like a fat man can eat chips.


Only an issue if you expected to program yourself / third party for the Tx.

My 2c
Yes Assembly if faster when you do it correctly, But future maintenance on the code is much much difficult, also will create a problem when you have to move the code from one type of CPU to another , in my opinion is much better to do the main code in C or C++ so maintenance and portability is much much ease. of course some critical code could be done in assembly for speed.
wwmilanl is offline Find More Posts by wwmilanl
Old Dec 10, 2012, 09:05 PM
↓↘→ + (punch)
theKM's Avatar
central PA.
Joined Sep 2004
20,223 Posts
I can't see Jim releasing a product with the core coded in anything other than assembly. Jim mentioned once that the hardware in the Aurora9 was capable of far better than the resulting latency would suggest... code performance matters a whole bunch, it turned a potentially fast system into an absurdly slow one. The proof being in the pudding, Jim removed half the latency by fixing up the module/receiver side with the XPS offering. Proof enough for me.

A feature of the XPS3216 will be its ability to load and run third party apps... a core of rocket fast assembly code and add-ons-that-can't-effect-performance written in whatever else, seems pretty ideal to me.
theKM is offline Find More Posts by theKM
Old Dec 10, 2012, 10:09 PM
Xtreme Power Systems
Lake Havasu, AZ
Joined Jun 2005
15,920 Posts
Quote:
Originally Posted by wwmilanl View Post
Yes Assembly if faster when you do it correctly, But future maintenance on the code is much much difficult, also will create a problem when you have to move the code from one type of CPU to another , in my opinion is much better to do the main code in C or C++ so maintenance and portability is much much ease. of course some critical code could be done in assembly for speed.
First of all, anyone who thinks that 'maintenance' is somehow more difficult with assembly code, needs to actually learn assembly code so that they will realize the real truth. It is BY FAR easier to maintain assembly code than C/C++/C#. I have been programming professionally since 1977, assembly since 1979 - and after learning and using COBOL, APL, FORTRAN, FORTH, PASCAL, ASSEMBLY (6502, Z80, 680x0, 80x86, PPC, 8051, PIC, AVR, ARM, etc.) I find that I program the fastest in assembly. It's the way I think... straight to the point, without million braces or parenthesis!

So, no switching of CPUs. There is no need. Even at the very fastest frame rate I have 5 times the CPU power necessary, and at the 'normal' 20ms frame rate I have 20 times the CPU power needed. I have LOTS of headroom here with this project. Figure 40,000 instructions per millisecond with most instructions requiring 1 cycle, and other than a divide (which I try to avoid by using recip math) being 19 cycles, only the interrupts really take up any CPU time to get in out. Also consider that all data transfers for the RF, audio, SD media, EEPROMs, etc. are all done using DMA so there is no waiting around for something to get done. That CPU time can be used for something important (like the cosine math needed for calculating variably changing curves).

TheKM is correct. If the A9 code was written assembly instead of C, the display wouldn't flicker and there would be likely no latency. Instead, Hitec has opted to apparently add a 2nd CPU for handling the screen with their new version.
JimDrew is online now Find More Posts by JimDrew
RCG Plus Member
Old Dec 10, 2012, 11:17 PM
Registered User
United States, TX, Katy
Joined Aug 2009
109 Posts
Jim, Am sorry I do not agree w. You, I also program in assembly Z80/6502/80x96/motorola 680xx/Sun Ultra Sparc/IBM Risc 6000/SGI MIPS series Etc. also write micro code for Array Processors like the FPS100 / FPS120 / IBM 2938 and etc, in the old days for Seismic Processing Imaging,
give you code to somebody else for future maintenance and let see how they do. The future of any organization can not depend on one person abilities.


In the other hand as you know

, HARDWARE goes obsolete fast , That why portability is a must

any way, this is of topic




Quote:
Originally Posted by JimDrew View Post
First of all, anyone who thinks that 'maintenance' is somehow more difficult with assembly code, needs to actually learn assembly code so that they will realize the real truth. It is BY FAR easier to maintain assembly code than C/C++/C#. I have been programming professionally since 1977, assembly since 1979 - and after learning and using COBOL, APL, FORTRAN, FORTH, PASCAL, ASSEMBLY (6502, Z80, 680x0, 80x86, PPC, 8051, PIC, AVR, ARM, etc.) I find that I program the fastest in assembly. It's the way I think... straight to the point, without million braces or parenthesis!

So, no switching of CPUs. There is no need. Even at the very fastest frame rate I have 5 times the CPU power necessary, and at the 'normal' 20ms frame rate I have 20 times the CPU power needed. I have LOTS of headroom here with this project. Figure 40,000 instructions per millisecond with most instructions requiring 1 cycle, and other than a divide (which I try to avoid by using recip math) being 19 cycles, only the interrupts really take up any CPU time to get in out. Also consider that all data transfers for the RF, audio, SD media, EEPROMs, etc. are all done using DMA so there is no waiting around for something to get done. That CPU time can be used for something important (like the cosine math needed for calculating variably changing curves).

TheKM is correct. If the A9 code was written assembly instead of C, the display wouldn't flicker and there would be likely no latency. Instead, Hitec has opted to apparently add a 2nd CPU for handling the screen with their new version.
wwmilanl is offline Find More Posts by wwmilanl
Old Dec 11, 2012, 01:50 AM
Registered User
E_ferret's Avatar
Launceston Arpt, Tasmania, Australia
Joined Jan 2004
564 Posts
Quote:
Originally Posted by wwmilanl View Post
give you code to somebody else for future maintenance and let see how they do. The future of any organization can not depend on one person abilities.
regardless of what language you write it in, even machine code for that matter, it is the accurate documentation of each subroutine, including each variable use that I find the most inportant. problem is that the documentation is only accurate in the beginning. as the program gets re-written, patched, updated, changed, all of it sometimes in a hurry under pressure from senior management, the revised documentation gets put on the back-burner, "no time right now, Christ it is 4 AM already, I'll do it when I've got time". never happens.
When somebody else takes-over the program for maintenance or update, then lots of routines get left behind and untouched because whoever does an update does not understand what the frigging thing is supposed to do!
E_ferret is offline Find More Posts by E_ferret
Old Dec 11, 2012, 12:01 PM
Xtreme Power Systems
Lake Havasu, AZ
Joined Jun 2005
15,920 Posts
I never have to worry about documentation. I comment just about every single line of code along with detailed headers for every single subroutine. I am looking at some Commodore 64 and Amiga code I wrote 20+ years ago, and it all makes perfect sense because I am so detail oriented with my documentation.

As far as hardware changing fast, sure it does! But if you design your product with ample head room, then you should never be able to outgrow its requirements. This is why I always try to have 5 times the clock speed in 'wasted' time available. Even if I added every bell and whistle I could think of, there is no way to burn up every last bit of CPU time available... and since there is a migration path already to a part that is twice the speed, there is always a way out.

This is why it is key to have engineers that know both hardware and software (firmware). You get into trouble when you have two different groups that don't know much about the other.
JimDrew is online now Find More Posts by JimDrew
RCG Plus Member
Old Dec 13, 2012, 10:54 PM
Registered User
United States, AZ, Queen Creek
Joined Aug 2004
795 Posts
Quote:
Originally Posted by JimDrew View Post
I never have to worry about documentation. I comment just about every single line of code along with detailed headers for every single subroutine. I am looking at some Commodore 64 and Amiga code I wrote 20+ years ago, and it all makes perfect sense because I am so detail oriented with my documentation.

As far as hardware changing fast, sure it does! But if you design your product with ample head room, then you should never be able to outgrow its requirements. This is why I always try to have 5 times the clock speed in 'wasted' time available. Even if I added every bell and whistle I could think of, there is no way to burn up every last bit of CPU time available... and since there is a migration path already to a part that is twice the speed, there is always a way out.

This is why it is key to have engineers that know both hardware and software (firmware). You get into trouble when you have two different groups that don't know much about the other.
The trouble with sticking with one device is the device will become obsolete and you will have trouble getting them. I tested the code for the 747-400 flap control system written in Ada It used an 80286. I bet they had to use another device when they had to replace one.
Then if you program it in assembly, and you change the device, you have to learn another instruction set.
dirtybird is offline Find More Posts by dirtybird
Old Dec 14, 2012, 12:08 AM
Xtreme Power Systems
Lake Havasu, AZ
Joined Jun 2005
15,920 Posts
It's quick to change a CPU type and convert code.
JimDrew is online now Find More Posts by JimDrew
RCG Plus Member
Closed Thread


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Sold XPS 2.4GHz JR Transmitter Module (9x) az_heliguy Aircraft - General - Radio Equipment (FS/W) 19 Apr 05, 2012 12:07 AM
For Sale Hacker / Spin 170 Controller, XPS Pro Dynamax, 15S 6800 XPS packs in 3S bricks. penceaviation Aircraft - Electric - Jets (FS/W) 9 Oct 13, 2011 08:55 AM
Wanted XPS 6800mah 65c 6s want to trade for xps 5000mah 65c and will pay difference sherlockshah Aircraft - Electric - Batteries & Chargers (FS/W) 3 Oct 12, 2011 09:30 AM
For Sale 3s xps 5000mah 65c $60 shipped with warranty also 2s xps 5000mah 65c $45 shipped with sherlockshah Aircraft - Electric - Batteries & Chargers (FS/W) 2 Sep 24, 2011 01:48 PM
Sold TransMitt transmitter bag / warmer**price drop** aerosheldon Aircraft - General - Radio Equipment (FS/W) 5 Mar 31, 2011 01:40 PM