going to try this stuff

Hello,
First a great thanks for doing all this work on Hempstick and then even sharing it. I absolutely love trying stuff like this out, especially if I can re-use an old HOTAS. I intend to try this project with a TM FLCS and TQS. I am an engineering manager, but still a layman.

I can muddle my way through code if I have to, cut and pasting and figuring out config files is not a problem, I can read schematics and do wiring of electronics, good at linux and windows, network and firewall administration, etc. to give you a little background. I do have a few questions:

1. I was thinking to use two MCU's, one for each device. This is due to your note about potential noise introduced on the analog wires going from one device to the next, plus it avoids the Windoze 32 button limit. But, when these devices are originally created do they not have these analog connections going from one device to the next (i.e. the TM FLCS/TQS combo or even newer Cougar setup)?

2.a. I cannot find anything that is an Arduino DUE/X, only Arduino DUE. Is there really something that is a DUE/X? where do I find it?

2.b. Related, do you anticipate any issues using a DUE clone? they are far cheaper, and I need cheaper right now (or I would just buy a warthog stick!).

2.c. You stated you need a separate debugger to program the Arduino DUE, but I have read that it can be programmed though its USB interface? (the answer to 2.a. might be telling though)

3.a. Looking at the size of the boards, I would like to use something smaller than I can definitely fit inside the enclosures. Could this be ported to say a Teensy 3.1/3.2? Does it have the specs to run this project? The processor can be overclocked on that if necessary.

3.b. What issues would you forsee porting this first to a new IDE (Arduino with teesyduino) and then the code? maybe just figuring out the config options and a few other annoying issues?

Thanks for your time!

1. Sure, the shorter the analog lines the better, but it's not the only way to avoid noises. You could use shielded cables for that. Particularly, there is a software running average filter on the ADC results to mitigate this problem. It really depends on your "environment" a lot. For instance, if you are just running the analog line on your desk between stick and throttle, then, the chance of picking up a lot of noises is very low (60Hz AC hum is probably not a real problem). But if you run the analog inside a pit along a bunch of motor power line, you may get a real problem. What I am saying is that separate MCUs is the best, but do you really need it?

2a/b. AFAIK, Arduino Due and Arduino Due/X are the same thing. The /X specifically refers to the 'X' in the SAM3X MCU is uses. As long as your Due board has the SAM3X MCU, it should be fine (I don't know if there is one that is not, but I could be wrong). Arduino Due clones should do just fine. But since I have not tested them myself, I can't give you a definitive answer.

2.c. Arduino boards each has a low-end Atmel chip acting as an on-board debugger/programmer. The firmware in this chip is designed specifically to work with Arduino IDE (or command line executable behind it). Hempstick on the other hand does not use this chip. Actually, Hempstick does not care what debugger/programming interface it uses, it's the Atmel Studio IDE that cares. It uses whatever Atmel Studio's interface, which works with either 1. a separate programmer supported by Atmel Studio, or 2. the Atmel's EDBG chips. Some newer Atmel boards have this EDBG chips on board (acting as the on board debugger/programmer interface similar to Arduino's, but uses a completely different and incompatible interface), like the SAM4S XPLAIN Pro board. Arduino Due board obviously does not have this EDBG chip. So, yes, to use the Due board for Hempstick, you have to use a separate debugger/programmer).

3.a. No, I will not port Hempstick to support Teensy 3. Teensy 3 uses non-Atmel MCUs. Hempstick is built on top of Atmel Software Foundation (ASF), which understandably only supports Atmel chips.

3.b. Other IDEs... That's not exactly possible. Here's the thing. This is embedded programming. The IDEs for embedded usually come with support of "emulator." The emulator usually not just "emulate" the MCUs, it also allows you to inspect the state of the MCU, like the values of various registers. This is very valuable to debugging, as embedded programming usually means you don't even have a console to see the return values or not even have serial line to printf to see what's going on. Unless you are willing to forgo this "emulator", you'd have to implement an emulator (or implement something to read/write to registers an modules on the MCU, and it has to support multiple MCUs). And the worst part is... what do we gain from spending such heroic programming efforts? Pretty much nothing while all we have to do is use the manufacturer's IDE (which is free of charge).

hlfritz wrote:Hello,
First a great thanks for doing all this work on Hempstick and then even sharing it. I absolutely love trying stuff like this out, especially if I can re-use an old HOTAS. I intend to try this project with a TM FLCS and TQS. I am an engineering manager, but still a layman. I can muddle my way through code if I have to, cut and pasting and figuring out config files is not a problem, I can read schematics and do wiring of electronics, good at linux and windows, network and firewall administration, etc. to give you a little background. I do have a few questions:

1. I was thinking to use two MCU's, one for each device. This is due to your note about potential noise introduced on the analog wires going from one device to the next, plus it avoids the Windoze 32 button limit. But, when these devices are originally created do they not have these analog connections going from one device to the next (i.e. the TM FLCS/TQS combo or even newer Cougar setup)?

2.a. I cannot find anything that is an Arduino DUE/X, only Arduino DUE. Is there really something that is a DUE/X? where do I find it?

2.b. Related, do you anticipate any issues using a DUE clone? they are far cheaper, and I need cheaper right now (or I would just buy a warthog stick!).

2.c. You stated you need a separate debugger to program the Arduino DUE, but I have read that it can be programmed though its USB interface? (the answer to 2.a. might be telling though)

3.a. Looking at the size of the boards, I would like to use something smaller than I can definitely fit inside the enclosures. Could this be ported to say a Teensy 3.1/3.2? Does it have the specs to run this project? The processor can be overclocked on that if necessary.

3.b. What issues would you forsee porting this first to a new IDE (Arduino with teesyduino) and then the code? maybe just figuring out the config options and a few other annoying issues?

Thanks for your time!

This message was edited 1 time. Last update was at 05/10/2015 10:05:43

Thx. for taking the time, especially for a newbie. I view this a way to really get into programming and embedded stuff, especially potentially taking on a port. I am thinking just do as is first, then maybe port. Along those lines, I would like to ask if you care if someone worked on that using your code?

For 3A I was not suggesting you do it, just a question about the feasibility. Your answer to 3B kinda sums that effort up as well I believe.

Perhaps a separate box on the desk with connections to each controller might be a better way to go? I think the original Cougar stick gets away with a 5 or 6 pin cable because the buttons are matrixed on the original config? Is that a correct assumption? If so, in this case it seems a higher conductor count cable would be required, and then the same for the stick.

So after writing that and thinking about it, perhaps 2 MCU's in a separate box on the desktop (no pit here - no way I could get away with that!) with discreet connections to each controller. This avoids the 32 button limit for DirectX (one of my requirements), unless you think that TARGET has an advantage here (interested in opinions, I have never used it - only foxy way back when for stickworks digital chips and saitek sst).

Thanks again for your time, appreciated.

Well, it's GPL'd code. You get to do whatever you wish with it as long as you abide by GPL terms. I see a feature useless, and you see it essential.... well, you can fork it and do it yourself.

This is not a very good way to get into programming... This is one very low level programming... some call it Bare-Metal Programming, i.e. there is just physical stuff right under there, almost nothing between you and the metal.

I certainly "perfer" using more MCUs than using one giant MCU. The reason is not really the long analog signal line, although that is a consideration. My main rationale for that is the Unix philosophy -- do one thing, and do one thing well. If a controller can do two thing well, I am not going to argue against that. So, if it's a joystick controller, than do joystick and do it well, and nothing else. But with an ARM32 MCU, using it to just do that one thing is a bit wasteful. So, if you really feel that you must do two things, ex. stick and TQS... oh well, why not?

But, the other benefit of using multiple MCUs, in addition to being more modular, is that it is more flexible in terms of Windows/DirectX and TARGET. Quite a lot of modern games allow us to use multiple controllers and use up to 32 buttons, 8 axes per controller. TARGET will only let you have one combined virtual controller. TARGET has much better calibration/programming/curving options, but all the physical controllers that get "combined" get programmatically unplugged -- TARGET claims exclusive access to them. With multiple MCUs, you get to say "Hey, I only need the best configurability on stick and rudder" so you program TARGET to only combined stick and rudder letting the TQS hang there as an independent controller to be picked up directly by the game/sim (and use the limited in game curving setting).

Oh... I just double side tape my controller right there on top of my CH rudder right between the two pedals. Looks geeky anyway. The new rudder I am designing, of course will look a lot more "professional."

hlfritz wrote:Thx. for taking the time, especially for a newbie. I view this a way to really get into programming and embedded stuff, especially potentially taking on a port. I am thinking just do as is first, then maybe port. Along those lines, I would like to ask if you care if someone worked on that using your code?

For 3A I was not suggesting you do it, just a question about the feasibility. Your answer to 3B kinda sums that effort up as well I believe.

Perhaps a separate box on the desk with connections to each controller might be a better way to go? I think the original Cougar stick gets away with a 5 or 6 pin cable because the buttons are matrixed on the original config? Is that a correct assumption? If so, in this case it seems a higher conductor count cable would be required, and then the same for the stick.

So after writing that and thinking about it, perhaps 2 MCU's in a separate box on the desktop (no pit here - no way I could get away with that!) with discreet connections to each controller. This avoids the 32 button limit for DirectX (one of my requirements), unless you think that TARGET has an advantage here (interested in opinions, I have never used it - only foxy way back when for stickworks digital chips and saitek sst).

Thanks again for your time, appreciated.

Understood on low level stuff, but maybe I misunderstand the custom library? It seems that it abstracts some stuff, but perhaps that is the complicated, low-level glue that make all this work with the rest of the application? And it would require porting to a different IDE?

I do have a very sr. ee on tap i can ask questions of, so i feel a bit cocky.

My guess is I will feel very overwhelmed once i start, but I like challenges. I also have time on my side, absolutely no rush required.

I do like the idea of the multiple mcu's and discreet devices so everything is native widows as well.

Regarding mcu's themselves, does it really need to be that high power? There are plenty of other arduino boards that are in fact smaller, but they are significantly less powerful - i.e. 16MHz. The same may well be fore ATMEL MCU's. I would have to look at the other features such as number of digital pins, memory, etc. Maybe those are just not as well suited or just plain old underpowered/underfeatured. You might know already, but I can try to figure it out as well. I feel the need to start looking at freeRTOS now as well to see about its requirements.

Thx once again!

No, it doesn't "need" to be this high powered MCU.

However, there are several reasons for using such high powered "overkill" MCUs.
1. You get more RAM, and SRAM to store large programs and more RAM to serve as call stack and dynamic data.
Just using ASF alone (it uses a lot of constants which eats up a lot of .DATA region). Then function calls eats up stack. A lot of those 4KB SRAM (for program) and 1024B RAM tiny MCUs have trouble even loading FreeRTOS, not to mention using the 1024 for something useful. Say, I am going to use the board to control a bunch of AdaFruit's DotStar LEDs for an F16 caution panel. There are 32 lights, each needs 3bytes, requiring total of 96 bytes of of RAM. That would already eaten almost 1/10 of the total RAM, even if we are not using ASF or FreeRTOS. In other words, the small RAM and SRAM severely limits the functionalities we can put on the MCU. This is, I assume, one of the reasons why ATTiny chips are not supported by ASF.
2. The prices of an ATMega 8 can be had for about USD $2.62 (quantity of 1 from DigiKey), and an ATSAM4S can be had for about USD $6.29. Almost 3x more expensive!!! But, if you are making 100K units, that makes a huge difference, but for hobbyists, with only a couple of units, a couple of dollars makes absolutely no difference. Even if you use 10 of them, the price difference is less than $50. Might as well use the high end chip and take the freedom and simplicity of code (reads less efforts to write and support).
3. Those low end chips don't have all the nice "features" like pull up/down resisters, glitch/debouncer filters, etc. etc. These are some of the core assumptions I made in Hempstick code base. Supporting those low end chips, then I would have to have a lot of "alternative" code path to do the same thing without hardware features. That makes the code messier and takes a lot more time to write and support.

In fact, my converted CH rudder still runs the predecessor version of Hempstick using a UC32, an AVR32 chip. But the prices of the evaluation board of the ATMega boards and ATUC32, and ATSAM4S are almost all the same. So, if we stick to the Atmel evaluation boards, then the high power SAM32 chips basically come at no additional cost. It would only be more expensive if you design your own boards, which I am reluctant to do, as I am no EE engineer. Moreover, if you make your own board, then you have to make big volume to justify the costs, and buying large volume of the MCUs, the price difference between high and low end MCUs drop very significantly.

My plan is to eventually make all these to read/write Ethernet, say SAM4E or SAME or SAMV chips, and I am considering rewriting Hempstick to Hempstick++ using C++ (didn't do C++ b/c ASF keeps warning about C++ is not supported). This will certainly necessitate high-end chips. Sure, you could use a low end ATMega 8 and hook it up to an external Ethernet "shield" via SPI or something like that, but that is not only slow, why would I use an external slow chip if I could have it on die?

So, these are some of the reasons why I completely ditched the support of low end chips (on top of the reason that I really don't have time and patience to support low end chips). I mean, why would I spend all those time to support low end chips while all I have to do is spend a couple dollars more using high end chips? If I were making a million units, then that would have been maybe $2M difference in profit, then spending that engineering effort (reads money) is worth it. But I ain't making 1M units, I make zero units and I probably will only use max. 10 units, which incidentally, as I mentioned earlier, costs me nothing extra when I use evaluation boards.

hlfritz wrote:Understood on low level stuff, but maybe I misunderstand the custom library? It seems that it abstracts some stuff, but perhaps that is the complicated, low-level glue that make all this work with the rest of the application? And it would require porting to a different IDE?

I do have a very sr. ee on tap i can ask questions of, so i feel a bit cocky. My guess is I will feel very overwhelmed once i start, but I like challenges. I also have time on my side, absolutely no rush required.

I do like the idea of the multiple mcu's and discreet devices so everything is native widows as well.

Regarding mcu's themselves, does it really need to be that high power? There are plenty of other arduino boards that are in fact smaller, but they are significantly less powerful - i.e. 16MHz. The same may well be fore ATMEL MCU's. I would have to look at the other features such as number of digital pins, memory, etc. Maybe those are just not as well suited or just plain old underpowered/underfeatured. You might know already, but I can try to figure it out as well. I feel the need to start looking at freeRTOS now as well to see about its requirements.

Thx once again!

completely understand, trading simplicity and a few dollars for time. from my point, an extra $20 savings on a board (vs. comparing only chip cost differences) does make a difference, especially if I am going to use two of them. I think I am coming around more to the idea of a separate "brain box" with two controllers and maybe even a usb hub, sits on the desk, the controllers connect to it (gotta figure out wire/cable).

i am well aware of PCB/PCA fab costs - deal with it a lot.

while being able to bury the mcu within the controller enclosure is a nice idea with a board that definitely fits, it seems it would not be worth the effort - especially if you are going to expand hempstick to ethernet later. (i think i will be ordering stuff within 2-3 weeks and will see how things fit)

along those lines, would you keep support for Due and ATSAM4S-XPRO? or select one over the other?

Support for SAM4S XPLAIN Pro and Due will both be kept. SAM4S is really well suited for doing stick and other smaller controllers where you need few GPIO lines but need fast operations, i.e. low latency. Due is better at having a lot of GPIO pins. Both have their uses.

Hempstick++ not necessarily will support SAM4S and Due boards (the main goal for it is to support SAM4E or SAME, or SAMV with Ethernet and be even more modular with all the goodies of C++). I will very much like to support SAM4S and SAM3X (Due), but when push comes to shove, they will be sacrificed. But note that I am still contemplating on how best to do Hempstick++, so it's not even started yet. When I will start and how long it will take... I don't know.

hlfritz wrote:completely understand, trading simplicity and a few dollars for time. from my point, an extra $20 savings on a board (vs. comparing only chip cost differences) does make a difference, especially if I am going to use two of them. I think I am coming around more to the idea of a separate "brain box" with two controllers and maybe even a usb hub, sits on the desk, the controllers connect to it (gotta figure out wire/cable).

i am well aware of PCB/PCA fab costs - deal with it a lot.

while being able to bury the mcu within the controller enclosure is a nice idea with a board that definitely fits, it seems it would not be worth the effort - especially if you are going to expand hempstick to ethernet later. (i think i will be ordering stuff within 2-3 weeks and will see how things fit)

along those lines, would you keep support for Due and ATSAM4S-XPRO? or select one over the other?

wow - those are quite expensive! still probably less so that the amount of time it would take to create or port something else.

At the risk of firing up an old topic, I will shortly embark on this very journey myself to get back into BMS after a 10 year break.

I have two sets of FLCS+TQS (my original one that I bought in 1996 and upgraded with SWF22 chips) and another set that I recently picked up online. I was planning on going the typical Arduino route but I always thought the looped cycle was rather crude, to put it politely.
(In 25 years of coding, I can count the number of times I've thrown something into an endless loop on one hand and none of these I would count as my best work.) Thank goodness someone pointed me into the right (read: this!) direction and I like very much what I see. In particular the thing with TARGET that we're not supposed to talk about ..

However, I will probably be using a single board in the TQS housing given the cost and the fact that I would only build this for desktop usage with a relatively short (shielded) cable between the FLCS and TQS.

In your documentation, you mention that the ATSAM4S-XPRO would only be $29 USD per board but down under I can't find them for any less than $75 NZD (~ 52 USD) at best? Is there a particular supplier in the US that you could recommend?
(I have a freight forwarding address in Portland so its no problem if they do not ship internationally)

Many thanks for sharing your work and insights!!

Tazz wrote:At the risk of firing up an old topic, I will shortly embark on this very journey myself to get back into BMS after a 10 year break.

I have two sets of FLCS+TQS (my original one that I bought in 1996 and upgraded with SWF22 chips) and another set that I recently picked up online. I was planning on going the typical Arduino route but I always thought the looped cycle was rather crude, to put it politely.
(In 25 years of coding, I can count the number of times I've thrown something into an endless loop on one hand and none of these I would count as my best work.) Thank goodness someone pointed me into the right (read: this!) direction and I like very much what I see. In particular the thing with TARGET that we're not supposed to talk about ..

However, I will probably be using a single board in the TQS housing given the cost and the fact that I would only build this for desktop usage with a relatively short (shielded) cable between the FLCS and TQS.

In your documentation, you mention that the ATSAM4S-XPRO would only be $29 USD per board but down under I can't find them for any less than $75 NZD (~ 52 USD) at best? Is there a particular supplier in the US that you could recommend?
(I have a freight forwarding address in Portland so its no problem if they do not ship internationally)

Many thanks for sharing your work and insights!!

The SAM4S XPLAIN is now about $31. SAM4S XPLAIN Pro is $53. You can find them here, https://www.digikey.com/products/en?keywords=SAM4S%20XPLAIN%20ProSo, you'd probably want to buy it from NZ, the s/h and potentially custom tax would make it impractical. Oh... now other countries are picking it up. The first time I heard of freight forwarding was from a friend in Georgia (the country), and then a guy having a forwarding address in Florida for Jamaica. Now the New Zealanders are picking it up the idea.

The difference between SAM4 XPLAIN and SAM4 XPLAIN Pro is the followings, although the use the same MCU chip.
1. The pro has more leads wired out than the non-pro version.
2. The pro has an embedded debugger chip on board so you don't need an external hardware debugger.

Atmel probably picked up the idea of using an ATMega chip and program it as a debugger from Arduino, but they hard coded the whole thing as a custom chip. They don't sell this chip though, except they use it in the Atmel ICE debugger for about $100.

The embedded debugger (DBG) chip is fine, but its USB driver is a little buggy. You have to use it the right way or it will crash (and your Windows won't shutdown, without pushing the big red button). NEVER unplug the USB cable to your target board without software disconnecting the debugger from Atmel Studio. The old old SAM ICE is much more robust, but it's a lot slower than the DBG-based debuggers.

Arduino Due is slightly cheaper, but more powerful. But it requires an external debugger. So, if you are going to do several boards, or continue to play with it, Due is a better choice. But if you are going to do a one off thing, then SAM4S XPLAIN Pro is a better deal.

The dumb busy polling loop is the first thing I ever saw Arduino does. As soon as I saw that, I told myself... I am never gonna be caught dead with it! I don't care what useful libraries it comes with, that busy loop makes it impossible to predict the latency. I understand why they did so. In a extremely resource limited MCU like the ATMega 328, putting an RTOS on it, although possible, is going to eat up a lot of precious resources. But the unpredictable latency is not going to cut it for flight sim controllers. For artists and making some toys turning on an LED here and there, that kinds of behavior, although not ideal, is acceptable. But for a flight sim controller, it's a deadly sin, as flight sim controllers require predictable latency and tight timing (for real flight controller, hard real time is required as missing a timing dead line and somebody might die, but for flight sim, soft real time is ok, as the worst is that you crash your virtual jet or eat a missile up your real end), and it is very un-future-proof. Case in point, now they have Arduino Due, that is no longer so resource limited, but due to the impossibility of porting the now huge established Arduino framework, it is still doing the busy loop. Arduino Due with busy polling loop is unforgivable, as it can no longer justify the busy polling loop with the excuse of scarce resource!

But, their "strategy" did work and proved that not the best product wins on the market. It's at the right place, the right time wins.

I am working on an all metal RudderCore and a Hall sensor MiniStick prototypes now. I might need a smaller board like the SAM D21 or D11. So, I may port Hempstick to that, but don't count on it as I might just lazy it out with a Due board. But I am planning (and learning) to do FPGA. The next gen Hempstick will be FPGA based. You will notice that Hempstick does not have take output from the host. I plan on doing that with FPGA chips, and Ethernet. So, Hempstick will stay on doing low end, fast response simple no-output controllers. And the FPGA-based will do the higher end control, communicating two-way with the flight sim on the host.

The freight forward service is actually owned and provided by our national postal service (sorta like USPS but then NZPS). They operate facilities in the USA, UK and China. Using a specific address code (e.g. the Suite number actually relates to my NZPS account number I think), they know exactly who the package is for. Once it arrives, it gets weighed and I pay the NZ shipping charges which are usually less than the DHL/Fedex/UPS charges. The great thing is that when you order from different places, they can easily combine shipments and make it far more cost effective. A great solution when you're stuck on a tiny island (well actually 2 of them) .. surrounded by lots and lots of water. And sheep.

It would be a heck of a lot more practical if Hempstick could be ported to a smaller board or of Amtel would release a compact version of the SAM4S-XPRO. But I fully understand that such a project will take a lot of time so I'll just use what is available (SAM4S-XPRO) as a starting point. Thanks for highlighting the difference there. Given that I am not planning on buying a pile of SAM4S boards, I think buying the XPRO with the onboard debugger is going to more costs effective than buying a separate debugger.

Now given that the Cougar isn't going to consume all the available resources on the SAM4S-XPRO, would it be possible to turn the FLCS+TQS into a "Cougar" ... while also adding a second keyboard USB HID device on the same microcontroller to host my ICP and MFD controls?

One SAM4S-XPRO is now on its way down under! It got a bit confusing as Microchip bought Amtel a while ago.. I thought I was looking at some dodgy clone before I realized it was the real thing!

Very interesting that the forwarding service is actually run by the NZ government!

One drawback with porting Hempstick to smaller Atmel chips is that those smaller ones don't have hardware SSC module, which I use to read TM Stick. And I refuse to do software bit-banging. Moreover, bit-banging is a multithreaded environment is troublesome. It's particularly bad when everything is interrupt driven. Meaning, in order for bit-banging to work without getting interrupted, one must disable all interrupts before entering bit-banging region in order to get the timing right. See, let's say it takes 2 ms to bang out the signals for reading one TM stick data set. Within this 2 ms, the bit-banging thread must not be swapped out, and no interrupt may be serviced, so the bit-banging code can operate without interruption. That means, the latency guarantee of 1ms of other threads is completely broken. Surely, reading one TM stick report wouldn't take that long, if I run that at say 1MHz, one report would only take about 0.028ms. But that still violates one of the principal design principles of Hempstick -- nobody monopolize the MCU by disabling all interrupts. Moreover, some hardware cannot be run at such high speed to fit within 1ms latency guarantee, for instance, a long string of Neo-Pixels.

So, even if I port Hempstick to smaller MCUs like D11, it wouldn't be able to be used for TM's sticks. That limits its utility. But it would be good as a rudder controller or other small controller though. That's why porting to smaller MCUs is such a low priority for me. $50 board vs. $20 board? Take the $50 board and save the trouble, unless size of the board is a concern. For a rudder, I definitively has space to accommodate the bigger SAM4S XPro or Due. In other words, I haven't found a real compelling reason to port it.

Just a short update - Finally received my SAM4S-XPRO board. I will hook it up tonight and start loading the firmware and all, but I'm still waiting for the cables and all to arrive from China.