Messages posted by: Hempstead

I have locked up the new user registration again.

The Russians are just too relentless on the forum spamming.

My practice had been to find the spammer's IP# from the log files, and do a whois search on it. Then I block the whole block of IP#s. I know they are from the ISPs, and I don't give a shit. You host spammers on your /10 network, I shit list your whole /10 network with Linux iptables, in hope that eventually I get most of the shitty ISPs (or most of them to make a difference in my life).

Unfortunately, I am on the losing end of the battle. There are just too many shitty ISPs willing to look the other way. I simply spend too much time cleaning up and shit listing these people. They got nothing better to do, but I do. So, I am closing the new user registration permanently.

Not sure why in the Project Tools it only allows you to select 2MHz. But that should be fine. The speed of SWD is not very critical. 2HMz should be fast enough.

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.

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.

Definitely let me know how it goes....

Sorry I saw the post a couple of days ago, but thought that it was posted in June.

Rudder for leftie? I don't quite get it.... root pedals for rudder don't have leftie/rightie thing. For RC may be?

It's going to take much more than just a 3D printer.

In the last few days, March 15 to March 17, there was a huge windstorm in the Seattle area that knocked out my power a few times.

This caused the hempstick rack mount server's UPS to run out of juice. For some reason, the hardware firewall I have went a bit crazy. But it came back by itself after a day or protest. So, the Hempstick.org web site went dark for more than a day.

After it came back from the strike. The mysql daemon process went a bit crazy a few times as well. That caused this forum going dark, but the httpd was still good.

I apologize for the confusion and inconvenience.

It has just been brought to my attention that the following YouTube video contains the wrong information on where to install the PTFE ring, https://www.youtube.com/watch?v=VDb99oRoD8U

The pictures of the following post shows you the right place for the PTFE ring, http://www.hempstick.org/jforum/posts/list/24.page

Notice that I use the strong words of "right/wrong." Putting the PTFE ring at the place where the YouTube video shows potentially will damage the plastic gimbal rim, as the ABS plastic will rub against a rough metal plate -- the plastic always lose on that battle. Although some people swear by no ring (either rubber or PTFE) works great, I wouldn't recommend that. I have a PTFE ring user reported that the stick runs "gritty" after he installed it according to the YouTube video. The "grittiness" is a good indication of uneven surface from the rough metal surface.... that spells friction, unwanted friction. Please don't do that!

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?

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!

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.

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!

http://www.atmel.com/tools/ATSAM4S-XPRO.aspx

And you can either buy it on DigiKey, Mouser, Future, or directly from Atmel. Note that nowadays if you buy it directly from Atmel, it get dispatched by DigiKey. This is much better for us actually, because now shipping is cheaper from DigiKey than when Atmel used to ship from Malaysia by DHL. Also, it means that DigiKey should have better stock of Atmel's eval boards.

So, if you are not buying enough boards to justify the s/h charge, or you have something else you also want to buy, like LEDs, Hall Sensor chips etc., you are better off buying directly from DigiKey, as you can't buy these non Atmel stuff from Atmel store.

What's not so good with DigiKey is that they would charge me sales tax, but Mouser (in Texas) does not. But Mouser doesn't have as good stock as Digikey. A lot of times I can't get some Atmel boards or Melexis Hall chips from Mouser, so I am forced to buy them from DigiKey and get charged sales tax.

So, try Mouser first, then DigiKey, then Atmel.

Over the weekend, I made a batch of 89x PTFE rings (only 1 failure out of 90 due to the controller computer ran out of battery power and shut down! The charging plugged to a USB hub didn't work... grr...).

We are not going to run out of stock for a while.