Hempstead

Pre-Configured File Sets From now on, Hempstick will come with sets of pre-configured configuration files. It will be located in src/config/..., for instance, src/config/Cougar/. You just pick the set you want, copy all the files in there to src/config/ overwriting whatever is there and compile and burn the firmware. If you have a set that you wish to contribute and share with others, please let me know, I will put it up to the official release.

Cougar Demo Project Completed The Cougar Demo Project is completed. The official announcement is here, http://www.hempstick.org/jforum/posts/list/0/14.page#28. You can use Hempstick to convert your whole Cougar, a lot of wiring works. But you will end up having an up-to-date electronics. Why? Hempstick does 1KHz USB report while Cougar does 100Hz. Hempstick's ADC is a 12bit hardware, software enhanced to 14bit while Cougar has a 10bit ADC You could use Target to program Hempstick converted Cougar. I imagine this would be interesting for the F16 crowd, but probably not for others. Nevertheless, this demo project was really to demo how easy it is to use Hempstick to do the whole joystick.

The Hempstick Cougar Demo project is almost complete. 1. The sweet & short document is written. 2. Corrected the TMStick button mapping error (ha... thank goodness I implemented button/axis mapping, including TMStick button mapping. All I had to do is tweak the button mapping table to correct this problem). 3. Added 8 way Hat Switches support. I forgot one of the hat switches on TMStick is actually an 8-way. Doh... Tested it in TARGET, showed up as a Cougar. Also tested it in Target Device Analyzer. ;-) But I do not use it myself in TARGET other than testing purpose. Man, I haven't touch my Cougars since Warthog came out. I have a longer version of the document, detailing how the Hempstick event-based system works and how the FreeRTOS tasks interact with each other and where and how to implement the 8 way switch support. It's quite messy. But it does show some of the basics of how to add new tasks to extend Hempstick. Not sure if anybody is interested in this and it's not ready for release anyway. But if you re interested in such "work-in-progress developer's document", please contact me. I will proof read the document and release the updated code tomorrow, July 30. Stay tune.

Ha ha... I can't believe you pulled out the bus factor joke. I have always loved that one. ;-)

Having said that you can program Hempstick to work in Target. I must give you a big fat warning, even though I am not a lawyer. It might not be illegal to program Hempstick, or any USB devices to work in Target. It might be illegal to use Target in this manner. You can say it can be done, but never tell people how to do it. The dissemination of that information might be in violation of DMCA. If they sue you, even if you win the case, you still lose on the lawyer's fee. I personally do not use TARGET with Hempstick, except in educational demonstration and research reasons, which are permitted by DMCA. Why would I use Target for Hempstick while I can use it as a straight USB joystick controller, or use vJoy to do similar things (As a C programmer, I have no love for the bastardized C-like Target's scripting language). Getting Target to work with Hempstick is not the purpose of Hempstick.... it's merely a by-product of any USB firmware. You just can't avoid it if you write any USB firmware. If ThrustMaser decides to update Target and their firmware to authenticate between Target and TM controllers, I have no desire to circumvent that with Hempstick. It works with Target if you know how now, and it works as-is. Use it this way at your own risks.

No Cougar programming with Foxy!!! Nor will there be composite USB mouse/keyboard that Cougar does. It just shows up as a Cougar w/ a Joystick device, like Warthog. What good is that for? Well, you can program it in Target just like a Warthog. I am writing the document on how to do this and add the Hat Switch and correct a small problem of mapping the stick buttons at the wrong location. This doc. includes wiring up both the throttle and stick to the Hempstick board. The stick is wired up with the existing 5 pin PS2 connector. I basically dump both the main board and the matrix board in the throttle and connect to the PS2 connector, the pots, and the header 261 in the throttle handle with a tangle of wire to a breadboard. You will have to decide how you want to neatly wire it up with a more permanent solution, like using a ribbon cable and where you are going to put the Hempstick board; I don't show you that. For the F16 crowd, you can wire up just the throttle and make it show up as a Cougar, and use it in conjunction with a Warthog stick under Target and suffer no more Cougar's crummy gimbal. And your pots are now all 14bit, instead of 10 and 8bit. You can do this w/ a Bodnar board, but you can't program it in Target. I keep saying this. I cannot show you how to make it show up in Target, in fear of DMCA. But it's so trivial that you will figure it out if you read the document. Sokol, you probably remember I said that three years ago on SimHQ. I am still saying that today., as the darn DMCA law is still there. But with the release of Hempstick source code, it become trivial for you to figure it out yourself. I only figured it out three years ago because I had the prototype code of Hempstick on an AVR32 board so I could try out different ideas. The Cougar demo project should be done in a few days.

FYI. Currently, Hempstick uses this much program and data memory space. There is plenty of headroom to code a lot of stuff you want. Program Memory Usage : 41232 bytes 2.0 % Full Data Memory Usage : 58784 bytes 35.9 % Full Note that, the SAM4SD32C chip SAM4S XPro board runs up to 120MHz, has 2048KB of flash program memory, and 160KB of SRAM. In contrary, the PIC18F2458 chip used by one of the most popular sim controller board runs at 12MHz, has 24KB program flash, and 2KB data memory. I am already using about 40KB program space, which you could never squeeze into that PIG, and I still have 98% head room to grow. Do you see why I say that PIC chip is outdated? It's got nowhere to go except upgrading to a bigger and better MCU. But why bother upgrade if you dominate the market and every other competitor uses the same outdated chips as you do?.... until somebody releases an OpenSource one that is bigger and better and gives you a clear upgrade path. Will I ever use up the other 98% program memory? Most likely not! But I do not have to worry about running out of program space and twist the design/code to accommodate the small space and make the code a spaghetti, difficult to code, maintain, extend, and upgrade.

Cougar Demo project progress Worked the whole weekend on the Cougar Demo project. One of my old Cougars is in pieces. Every hole on the Cougar was probed. ;-) Thanks to ViperPits & Foxy sites' extensive information, saved me a lot of time. All wires hooked up -- in a tangled mess. It's running..... As expected, no code modification required, only the axis and button mapping files are modified. But.... Found a problem with my TMStick code... I forgot to map the POV as a special USB POV 8 way, instead I just output them as 4x regular buttons... Buzz, wrong. Will need to modify the USB HID report to add a POV 8 way, then modify the TMStick code to map that 8 way data. Then shift all the buttons behind forward by 6 bits (there are 2 bits, 1 and 2 unused in Cougar, and 1 bit unused in Warthog (and Warthog took bit 2 and mapped it to button 19). This modification shouldn't take long. Should be just a couple of lines of code. Changing the USB HID report descriptor could be a real pain in the your know where though... I ain't got expensive USB hardware sniffer... so If I get it wrong... the host would just ignore me and say NOTHING! Minor correction, no big deal. It's all in the TMStick task and will not impact other parts. Enough coding today... to be continued.

It works fine.... except when updating firmware of the stick/throttle. For that, you "might" have to hook up to the root hub on the motherboard. Don't know if TM has fixed this problem yet. Warthog is two USB Full-Speed devices, not even High Speed. They can't be that demanding as long as your hub is at least USB 2 and not too crowded.

Bug fix July 27, 2014 Bug Fix. A bug was introduced in July 12, where I introduced a new feature to map ADC channels to any USB axis. It caused any ADC channel at and above HID_JOYSTICK_REPORT_TOTAL_NUM_ADC_AXES not being copied to the USB report. Default of this value is 8. So, you would not see ADC8 or above values. Mea Culpa. I was an idiot and did not test all the axes. Please pull new code. All announcements can be found at here, http://www.hempstick.org/jforum/forums/show/5.page

SAM4E support delay Hit a brick wall in SAM4E support project, USB port stopped working... Got to be something stupid like didn't configure the USB VBus pin correctly, the new chip requires slightly different calling procedure, need to explicitly configure USB interrupt b/c of default value changed, or something like that... Aaahhh... No worry, I will figure it out eventually. But it will take longer for this board to be supported. I do regret sitting on Hempstick source code w/o releasing it for a year, even though I finished it, put up the GPL v.2 license notice in source, and wrote the User's guide a full year ago already. I blame my sofa being too comfortable. Ok, BattleField 4 should share some blame too while I am at it. ;-)

I don't think you were baiting me whatsoever... ;-) Just that I have learned from past bitter experience that you never know what part of people's work they hold dear. There are two aspects of the Hempstick. 1. If you just want it for inputs of buttons and 0-3.3V analog voltage signals (plain old POTS are fine), and even reading TMSticks. Hempstick is no vaporware. It's here. It works. You can use it to control the whole Cougar and more, period. 2. If you want something outside of that. It's here for you to extend. #1 aspect is to provide the basic framework and prove that this thing works and is extendable, the TMStick task proves that. Consider TMStick task as "contributed" task #1. This is for those who just want to use it for what it does and don't want to fuzz with coding what has not been done before. That alone is quite useful! And Yes, I drive the Cougar and Warthog sticks with 3.3V, works just fine. The more people contribute (that includes me), the more #1 aspect grows. Make no mistake. #2 is BLEEDING EDGE! It has tremendous potential. But potential is potential, it's not today. You and I have to extend it. If you are into building something that the current ones don't do. There is no point of going Arduino, other than its vast library that somebody else already wrote, if all you need to do is already written. But then, that's not going where no man has gone before, is it? If you are writing new things.... Hempstick is, IMHO, the way to go (of course, I am biased, take it with a grain of salt! ;-). Now, back to PS Cockpit. Does it work? Sure it does. Will it work for you? Depends on what you want it to do. If you just want what it does, easily hook up and control some PWM LEDs, read some knobs, buttons/switches, or even control some RC servos for your gauges, 10bit ADC is plenty. Go with the proven platform. Sheps and others have already build several pits to prove it. If that satisfies all your needs, there is no point of using Hempstick, or Arduino. My only beef with it is why oh why did Sheps used an outdated MCU. A current version wouldn't have cost much more. But if you want a packaged deal, this is it! But, if you want to do things that they don't do or don't do it the way you like it, like air core analog gauges, control several NeoPixels like TigerShark does, Ethernet DeviceNet, or programmable electric spring, gradual dimming, flashing your LEDs in different rates, reading accelerometers, MLX90363, etc. etc. etc. You have no choice but to use an extendable one. And obviously, I consider Arduino inadequate for that. But none of these is here with Hempstick.... Well, except reading TMStick. BTW, I know somebody writing a firmware currently capable of reading MLX90363 on a PIC... My MLX90363 is only half way working. I DO NOT intend to provide all these... hell, I will try most of them and most likely succeed with only a few of them. I provide the basic framework, you extend it to write it your way. I will only write the ones that I desperately want and am interested in, for instance, the TMStick. Take the TMStick task as an example on how to write a complex contributed task (Complex? It's just 300 lines of code! But it uses a hardware SSC and DMA to read the stick! Those are a bit tricky to get right. I had to hook up a Logic Analyzer to see what the hell it's doing. Overkill overkil! Yes, it is... just the way I like it!)! That is the kinds of things you will be writing. You don't have to write complex ones! You can start with simple ones like flashing your LEDs and dimming it. If you are going to learn programming, learn to do it the right way. Don't go with the great dumb loop! if you are going to bleed, bleed for something you enjoy doing. If you don't enjoy doing this kind of things, stick with aspect #1 of Hempstick, or other controllers. Trust me.... you use Hempstick to do it the #2 way... you will bleed, you will sweat, and you will curse me for why in the hell did you ever buy into Hemp's BS and used Hempstick. But, if you succeed, even with the smallest thing like flashing the LEDs in just the way you like it, it's all worth it. Hey, if you do things the way I like it, I will pull from your repository! If I do it the way you like it, pull from my repository... If nobody likes my shit, nobody will pull from mine. It's all very democratic... you vote with your pulls. ("pull" is a Git repository terminology. Pulling from my repository means you get my code change into yours, sort of). Let me be very frank with you... go with Sheps' PS Cockpit as your main board, as I am not interested in building a complete pit. I only want some parts of it that matter to me. But somebody in the FUTURE MIGHT build it. For a few things that PS Cockpit can't do, that's where you turn to Hempstick to tinker the way you like it. If it doesn't work.... it's only 39 bucks plus s/h and some of your tinkering time. What? You have a problem with your tinkering projects don't work out? Dude, check how many PhDs I have (Projects Half Done). But keep an eye on what others are doing with Hempstick. If you are an F16 crowd, like Sheps is... take Hempstick and update your old Cougar. That is, use whatever fits the job best.

Hempstick SAM4E XPLAINED Pro board support project has started... on going...

Yes, I did look at it. It's a PIC with a 10 bit ADC. 10 bit ADCs was the thing of the Cougar era. Wait a minute! It was developed in 2011!!!??? Huh??? Didn't PICs have more modern ones with 12bit ADCs? Bodnar has it. I ain't gonna get baited into criticizing fellow simmer's pride & joy much further than that! Suffice it to say that I rejected it because I want the controller I use also be able to do stick readings. 10bit? No deal! Maybe Shepard changed it to a newer MCU later, maybe not. That was a mistake in 2011 to come out w/ an 10bit ADC, nevertheless. Where is the source code? If no source code, how do I add more features? No, I am not talking about the GUI configuration that I don't care a bit about (zero value to me). I am talking about how I can add TMStick reading, DeviceNet protocol, electrically programmable spring feedback, MLX90363, air core gauges... And other things that I can't think of now. You can do all these with Arduino though. Even if I can add more features, what happens when I run out of CPU? Is there an upgrade path? Most embedded controllers have a short life span (except the ones in your cars and appliances alike durable goods) , a couple of years best. It's outdated, you ditch it and buy another newer & better one. So, why bother writing robust and extendable firmware on it? Well, are you ditching your pit in 5 years? Ha! 5 years later, you probably aren't even half done with your pit!!! Some might argue that pit building is an on going process, always work in progress, so some parts of working old systems can stay as-is. If it ain't broke, don't fix it. But switching to a new board on newer parts of construction means you need to invest on learning the new board and still maintain the old.... Or are you gonna stick with the older outdated board? Grr.... Some of you half way into your pit building are probably asking yourself this very question now there is indeed a much more powerful one in OpenSource. Both the Arduino Due/X and the XPLAINED pro boards have fixed headers, and Hempstick will let you internally remap buttons/axes pins. So, if there are new boards, it might be possible for you to produce "pin compatible" boards to replace your older Hempstick boards.

That is precisely why I don't make the boards but relying on Atmel's off the shelf evaluation boards, and Arduino Due/X. I can't beat their prices. For a USD $39 board that comes with an on board debugger/programmer, it's extremely difficult for anybody to match that price against the manufacturer of the chips. SAM4E boards would be $99 and up.... There might be possible. But probably still not worth the effort. CMSIS & FreeRTOS do help some in porting. But what about all the peripherals used? You'd have to find equivalent ones on the target chip, then port all the ASF calls into raw registers/memory accesses and make sure they still work for all supported boards. You'd need in depth knowledge of all the supported chips and their peripherals. All of that heroic efforts for saving a couple of bucks? If I were selling this stuff in the millions, ya maybe that adds up. But I am not selling any and I do wanna get back to playing my sim sometime, right?

Zero to no chance that I will support any non-Atmel MCUs. Because I use Atmel Software Foundation (ASF) framework to simplify the settings of the MCUs and, most importantly, to gain portability among Atmel MCUs, but unfortunately I also get locked into Atmel MCUs. There is zero to no chance ASF will support non-Atmel chips. So, I will not even try. The deal I have with the devil (figuratively speaking, not that I have any deal with Atmel to promote their chips; the devil here is the ASF) is that Atmel keeps coming out with newer & better MCUs, supporting just some of those "worthy" new MCUs for Hempstick would be quite a task already (like I am currently working on SAM4E support in Hempstick to gain Ethernet so I can do DeviceNet protocol, and soon there will be Atmel W23 WiFi module, announced but not yet available; your SIM controller go WiFi, Yeehaw!!! For what? I don't know. It's cool.). ASF makes it easy to "update" Hempstick to newest Atmel MCUs, so that I don't fall into the same trap others fell into -- i.e. you spend a lot of time/effort developing a good firmware on a particular chip, then you get stuck on it because your code is not portable to newer MCUs, or you get complacent with your market dominance and are unwilling to spend the tremendous effort porting your code to newer chips with greater capability. I bought one of those... and I was like... dude, this is at least 10 years old technology with a 12 bit ADC, that's all. And I can't add anything. If I am going to get locked in, I'd rather get locked into one family of chips that are continued to be updated by a company that is going to survive for the foreseeable future, other than one old old chip. Think what a growing pain Arduino went through to do Arduino Due/X! And then people are still using the old old 8bit 16MHz Uno. Their popularity has become their biggest baggage! If you make a barebone board using ATSAM chips, like ATSAM4S/4E/3X, with just say a crystal circuit, and route out all the pins in convenient places, and sell it for $13, I will absolutely support it. Arduino, although I give them very high regards for bringing electronics tinkering to the great unwashed. I am, however, very dubious about the level they dumb it down. I researched it. Bought a couple of boards from them, wrote some test code on them, and found out that there is no way I can do things the "right way." There are things that is absolutely a no-no except in special situation that is the main way of doing things in Arduino, for instance, the great dumb loop! Sure, there are some later libraries that allows you to do multi-thread, but they are grafted on and the majority of libraries out there don't do it. With Hempstick, you create as many FreeRTOS tasks as you wish (within limit, and the easiest is a timer task), and then you do whatever you wish in those tasks, as long as you don't go mugging the data my tasks are using without proper locking. Each of these tasks is a separate thread. Sounds complicated? See the following code of how I flash an LED with an FreeRTOS task. Anybody who can handle Arduino can handle this. int main (void) { xTimerHandle ledTimer = NULL; setup_hardware(); // 200ms per call, we get 400ms duty cycle. ledTimer = xTimerCreate((const signed char* const) "LED Timer Task", (200 / portTICK_RATE_MS), pdTRUE, NULL, ledTimerTask); xTimerStart(ledTimer, 0); // start USB device udc_start(); vTaskStartScheduler(); } static void ledTimerTask(void *parameters) { /* Toggle an LED to show the system is executing. Very handy when the code crashes the whole system. If the LED stops flashing, you screwed up big time. */ taskENTER_CRITICAL(); { gpio_toggle_pin(LED0_GPIO); } taskEXIT_CRITICAL(); } In Hempstick, there is a button handling task, an ADC handling task, a TMSTick task , and other tasks, all triggered by hardware events so they only wake up to do things when there are things to do. For instance, if you don't press or release any button, the button task is not called at all; it would sleep there faithfully waiting for the master to call and uses absolutely no CPU cycle. You want to add something? You do the same thing, add a new task to do what you wish to do! Keep adding tasks until you run out of CPU or memory. And your tasks are just as first class citizen as mine, as long as you keep the same default thread priority. What's the difference between this LED toggling thing and Arduino's great dumb loop? You don't see me having a loop in the LED task, right? Doesn't mean you cannot have a loop in there! The most important thing is that whatever you do in your task does not co-mingle with my code and interfere with each other, except in some very timing critical code like bit-banging (for that, you have to turn off interrupts temporarily and set your task's priority higher than all other tasks; but most people's tasks won't be doing such things!), or using shared data. Hey, go hog wild and have one task controlling one LED if you want so that each LED flashes in different rates. Oh... I do that already. ;-) This way, your code does not interfere with mine, and mine does not interfere with yours (well, most of the time anyway). Is this FreeRTOS task thing so complicated that the great unwashed can't handle it so that Arduino had to dumb it down that much? If Arduino originally put this kind of things in, I wouldn't have set out to write Hempstick! If you are doing an 8bit ,16MHz chip... ya, ya, ya... a great dumb loop is acceptable. That thing doesn't have much oomph anyway so the code is bound to be very simple. But, when you start doing anything non-trivial when MCU speed/capability progresses, you are bound to run into modularity trouble when adding more "stuff." And by Moore's law... the speed and capability of these things fly! For what Hempstick currently does, do I really need an RTOS? No. But, it's what I can't think of doing now what I am aiming at! As a new framework, the current capabilities of the Hempstick is pretty thin... but it's currently as capable as all those commercially available ones for sims, if not more capable. Hempstick can read Warthog and Cougar sticks. Which one else can do it now? Why didn't they write it? Probably because there is no commercial value for it. And I did it with less than 300 lines of code. I want it, so I add it! The point is that we can keep on adding more of these. Not enough CPU for it? I will keep upgrading to new Atmel MCUs. For the foreseeable future, Moore's law always win. Maybe there is not much head space for Intel, there is plenty Moore's space for MCUs to go forward. If you are really going with Arduino, then I'd suggest going with the Arduino Due/X board. At least, you get more oomph, and if you wish to change platform, you can switch to Hempstick anytime. Say, you want to upgrade your old Cougar's electronics to make it 12bit ADC?

Shameless plug from me... If you are willing to learn some programming... (or not willing to learn programming for that matter), you definitely should try to learn how to use Hempstick, http://www.hempstick.org, USD $39, and you get a 120MHz 32bit ARM processor full of current generation peripherals, instead of Arduino Uno's 8bit ATMega 328 16MHz. In addition, with ATMega, you get 10bit ADCs, as opposed 12bit ADC in Hempstick (12bit, up to 16bit depending on the board you choose). Wait for next week... I will demonstrate how easy it is to use Hempstick to control the whole Cougar, with absolutely no coding (most of the work would be to find out which wire does what in Cougar and construct two mapping tables (buttons & ADC channels) to feed the Hempstick, and the physical wiring job). ThrustMaster is gonna hate me... b/c I am giving the old Cougars a new lease of life, by updating its entire electronics.

Sorry, no plan for FFB. Personally, I am not interested in FFB, and I don't have the required motor drive electronics expertise for it. It's OpenSource, so, other people with the interest & expertise can build it. I can provide the support for Hempstick side. My current priority for Hempstick is as the followings. 1. Demo project for Cougar conversion with Hempstick & Documentation. 2. SAM4E board & Ethernet support. 3. DeviceNet protocol & LED PWM support. 4. MLX90363 Hall Effect sensor support. 5.... maybe... support for a chip to do analog air core gauges (very low priority for me even though I already have some of those chips & some air cores at hand). I can be convinced with different priorities... but FFB is a tall order. After that, I go back to why I started the Hempstick to begin with -- build my panels, joystick, rudder, and other stuff.

Doh.... I forgot I already bumped it up to 64 buttons a year ago.... It would take me maybe 15 minutes to bump it up again, but it takes a lot longer to validate that it works for all supported boards and release it. However, please remember, each button is connected to an MCU pin directly so we can take advantage of the built-in hardware rebouncers, resistors, glitch filters, and level change interrupt on each pin. And I do not provide the full mapping of the 64 buttons. You have to provide that, b/c I have no idea what mapping you actually want to have. Ok, ok, I am more interested in coding it right than tedious data mapping.

Rudder Demo Project As promised, the Rudder Demo Project is up. The announcement is at http://www.hempstick.org/jforum/posts/list/0/11.page#19. This document will take you step-by-step from a blank SAM4S XPLAINED Pro board to having the rudder show up in TARGET. However, again, I cannot tell you how to make TARGET accept Hempstick. That part you have to figure it out by yourself. But if you read the document carefully, it's almost inevitable that you will figure that out by yourself. It's just two values you must choose yourself. Choose wisely and it gives you eternal life, Indy. The document is at http://www.hempstick.org/download/manual/RudderDemo.pdf or http://www.hempstick.org/download/manual/RudderDemo.ibooks. They are still a bit rough, haven't done much proof reading yet. So, please let me know of any error or suggestion. I have not updated the Hempstick web site's download section for this yet (some yet to be finalized work-in-progress changes of the the site prevented reflecting just this change).

That was on page 2 of this thread.

Sorry, not a chance. Because I use Atmel Software foundation library in Hempstick code and I use other Atmel hardware/software during development so I am stuck on Atmel chips. This makes it easy for me to support other new chips from Atmel, like the new SAM4E with 16bit ADC and Ethernet. But there is a price to pay... Teensy 3.1's chip is a Freescale. No chance Atmel will support it, so nor will I. Getting stuck on a family of chips is very common in embedded development. Teensy made the conscious decision of moving from Atmel to Freescale and that decision has its consequences. This is one of them. Even though it's also possible to support other Atmel chips, like Arduino Uno's ATMega AVR chips, I will not support them either, because that defeats the whole purpose of using higher end chips to do much more advanced functions at much higher speed.

Added a new customization chapter in the User Guide document.

New code pushed to GitHub. Do your git pull to update your code. 1. Fixed a problem with enabling/disabling reading TMStick. Now, just flip a flag and it deals with all the crap for you, instead of having to change several places for that. 2. Added a new feature to allow ADC channel to HID axes mapping. Meaning, which ADC channel do you wish to map to which USB HID axis. No longer needs to change the code for it. For the official announcement, see http://www.hempstick.org/jforum/posts/list/0/9.page#17 The next project will be to demonstrate how to use Hempstick to hook up your rudder. Obviously, this will be easy 3 axes. But the purpose is to get you started on where things are, what configuration files to change for what. The demo project after that will be building on what you learned from the rudder hook up. we will do the whole Cougar (yes, both throttle and the stick). I will connect the rudder and Cougar to TARGET. But I can't show you the critical part. You will have to figure that one out yourself.

For future proof, I would change the protocol to prepare for the possibility of sending other types of values other than uint16_t by changing the attribute struct as the following. struct { uint_16_t name, uint8_t value_type; uint16_t value_len; // in bytes. char* value, } attribute; Then, of course, we'd need to change the processing code accordingly, but currently implement only value_type 0x00, i.e. uint16_t, and ignore everything else for now. Meaning, the C code on the server side (C++ in the Arduino case) completely ignores the value_type and value_len for now and assumes the value is of type uint16_t by casting it to uint16_t. (The safer way is to check if the value_type is 0x0000, i.e. uint16_t. If not, ignore it, so that if a newer version of client sends the a datagram with other value_types to an older version of server that does not support other value_type, it won't crash the server. Speaking of that, it's probably safer to put a protocol version at the very beginning of the protocol. But it's not really critical to have; just that I would sleep better. ; -). For full implementation of other types, it's best handled with union, etc. But no need to do that now. Then, the Lua datagram templates for on/off need add 3 more bytes for each attr, but these 3 bytes are always fixed for your LED control anyway. That is, we put in the provision for the future, in case we need to send other types, like string or floating points. But we don't implement them now. And implement only uint16_t type. And, if we do implement other types in the future, it's backward compatible so the existing client code don't need to change.