Hempstead

http://www.adafruit.com/product/2000 Yet another 1/2 the price, made in USA name brand board, not your Chinese clone, containing FTDI serial-USB chip and active power supply chip/circuit on board. Google is your friend.

USD $8.88, straight from the horse' mouth, Atmel the chip manufacturer, not your average Chinese clone. And it even got a power supply chip/circuit on it to stabilize the power for the MCU. It also contains an Atmel EDBG embedded debugger chip on board. http://store.atmel.com/PartDetail.aspx?q=p:10500392#tc:description

I think Milan is probably towing gliders in the Croatian Glider Championship. So, just a bit more patience.

Eeeerrrr..... Why wouldn't the Arduino shield you use work? I don't understand this sentence... what chip? One ATMega chip per string of NeoPixel? If you use the AdaFruit's extremely timing critical "demo" code for driving NeoPixel, indeed that would be the case. That code is so timing critical that even if you change the frequency of the CPU, it will break. And if you don't turn off the interrupts it will break too. It's only good for demo purpose, but people keeping using it. Check out this approach, http://www.pjrc.com/teensy/td_libs_OctoWS2811.html. And BTW, an NeoPixel costs USD $0.41, while an SMD LED could be had for USD $0.04, and a 5mm through hole LED is about USD $0.10 to $0.20. Even if you use 200 of them per pit, the price difference is minimal.

Why not? AdaFruit's code too timing sensitive? Unable to handle large number of NeoPixels? Why is the Max7219 a better solution?

Tiny open loop steppers, maybe.

Let me put it this way.... If the flower power artists can do Arduino and even write some code on it, you as pit builders have no excuse of saying this building/burning Hempstick from source code is too difficult. Remember, my intended audience is those people who tinker/build their pit/joystick etc., not the virtual aces, although they are welcome too. If the virtual aces don't wanna learn this technical stuff... so much better we nerds get to kick their asses in the air! Remember, if it's a fair fight, you didn't plan it right (or hack it right!).

No, I will not write a UI for configuring it or burning firmware through bootloader. Somebody else can write it, if they feel so urged to. Or get somebody else to burn it for you. Hell, buy one that is burned for you, if somebody wants provide such a trivial service and charge a fee for it. I do consider other method for configuring Hempstick dynamically, there are some very good ideas I could do, but this functionality has much lower priority than other core functionality Hempstick currently lacks. Releasing it as an OpenSource has its perks. Modify it as you wish. I made it easy to just change couple of configuration .h and .c file, you change it and you compile & burn the firmware yourself. That's why I spend so much time writing the User's Manual providing step-by-step instructions of the "screenshot digest" format. So you can install the IDE and tool chain yourself, load up the project, modify the config files, and then press just one button and the IDE will do everything including compiling/linking, upload and burn the firmware for you automatically. The IDE does a wonderful job at that. Why bother writing another application to upload and burn the firmware through the bootloader while the IDE does a better job? I actually consider this process better for an OpenSource one than using a bootloader. I'd rather spend my time ensuring that Hempstick is not a pig instead of putting lipstick on it. I am not saying writing a GUI is always lipstick, it's necessary for closed sourced ones, but not so much with an OpenSourced one. Yes, it's less user-friendly... if somebody else really wants it that bad, s/he can write it. I also intend to use this to "entice" people to learn this development process a little bit so they get their feet wet into this by start with modifying the configuration files a bit and then eventually starting writing things that they want themselves; or stay at the level of end user by downloading a set of config files created by others. Play with it, start your own project and create a set of your configuration files by modifying the existing one, then contribute it back to the community! For instance, if you don't want to use 1ms USB report rate, go change src/config/conf_usb.c inside the USB device descriptor to whatever value you want, then burn your own firmware. Or, if you get a set of config files that have cleaner wiring for, say Cougar Throttle, than mine, share your config files. In other words, b/c it's OpenSourced and the process of building/burning firmware is so easy, the Windows configuration GUI gets downgraded from "essential" to optional status, hence much lower priority.

Thanks for your kind words, Milan! Well said, Milan. That's exactly the strategy I took in Hempstick! ;-) I used an internal timer to trigger ADCs at a configurable frequency, at 1KHz x 4^n oversampling rate to match the 1ms USB reporting rate. And let the ADC run on its own pace at that rate. All 16 channels can be sampled by one timer trigger event. The ADC module will automatically sample all the channels I enable in one shot. Once it's all done, it does a DMA transfer to my designated buffer, and then issue an interrupt to my ADC interrupt handler, all done without intervention. The interrupt handler simply copies the data away from the buffer and reload the DMA buffer pointer preparing the buffer for next ADC trigger. Then it does a "give" on a semaphore to trigger a FreeRTOS task. And it returns immediately so that it doesn't hog the CPU in the interrupt handler for longer than it needs to. Then, the FreeRTOS task handling the ADC will get unblocked and scheduled to run by FreeRTOS to process the ADC values. This ADC task just does a decimation on the existing buffer of the running circular buffer and a running average low pass filter. Then it copies the latest values to the USB report and went back to blocking waiting for the next notification of ADC value availability. So, even if I have multiple ADC conversions during one USB report period, say due to CPU being too busy or FreeRTOS scheduling delay of the ADC processing, it will always report to the USB host the latest available values, never wait for ADC conversion to finish. The ADC conversions simply run independent of the USB reports. ;-) This way, the host computer always gets the latest of what you "feel" in your hand and is available for reporting, minimizing the delay as much as possible. I imagine it would be very hard to formally quantify the delay quality when it comes down to sub-10ms range without a rigorous large scale study. And I can't find any hard data on this subject. So, I took the safe route of over kill strategy since I got a lot of CPU power to bring to bear and Hempstick is an event-based architecture so it doesn't use any CPU cycle when there is no event to process. I give you 1ms USB reports, and the latest ADC/button values. So, that gives the upper bound of the delay to 1ms as well (as long as the ADCs don't take more than 1ms to sample all enabled channels and the CPU is not too busy; this is why I can only do 3x 16bit oversampled axes, because 4x would take more than 1ms to sample). Since I have a lot of CPU... I don't do adaptive anything. I just brute force it to keep the code simple and straight forward. ;-) In short, I basically ensure that the oldest report USB is going to get is 1ms old and it's the latest one, if the CPU is not overwhelmed.

The shift register chip, CD4021BC by Fairchild, used inside Cougar/Warthog is obsolete. Can't buy it anymore from regular channels. So, I found a replacement HCF4021 from ST. It runs up to 20MHz, although it only goes up to 10V instead of 15V, it's good for both 3.3V & 5V operations. It's so cheap that I had to order 100 of them ($19.40) and still couldn't justify the s/h, so I also ordered a bunch of MCP23S17 IO expander chips with SPI interface. We will see which one works out better. Maybe I will support both.

I didn't detect any criticism. I am a programmer by trade. I talk straight. CDU is a good example I didn't think of. Good point. My mistake. There are basically two approaches to solve this problem. 1. Brute force it. Get a bigger MCU with more leads. But that depends on the manufacturer, and it costs more money. Or get multiple $39 boards. This sucks. 2. Extend it to read more buttons other ways. The whole point of Hempstick is that we can extend it relatively easily. ;-) I'd say #2. Controlling one device with two boards is just stupid. There are basically two ways to solve this problem. A. Use a matrix. B. Use a buffer like TMStick does, or use a bunch of input extender chips like BU839X does. I'd go with B with buffers like TMStick has for two reasons. i). Hempstick already has a TMStick module to read the buffer with pure hardware. And it does software debounce on it already. And we know the hardware buffer solution has worked well for oh so last decade or more. ii). No diode to deal with., no ghosting either, and the wires number is ---- you guessed it, 5. Less wiring than a matrix solution. And less MCU pin demands too! The hardware cascaded buffer is so simple to construct, you can use a breadboard if you want. But I wouldn't recommend using breadboards, b/c if we drive the damned thing through a couple of MHz, you are going to run into trouble. Yes, even these old old chips can run into a couple MHz... I just felt it wasn't necessary to drive them that hard and ran them at a couple of hundred KHz. Moreover, the longer the wire the more problem there could be with higher frequency. But with more chips cascaded, you probably want to run them at higher freq. so it doesn't take too long to read. Hardware reads it anyway, it doesn't use more CPU at all (well, except that originally I copy three bytes, now I copy 16). There are two parts to this modifications. 1. Steal the TMStick code and you can construct a cascaded buffer just like TMStick has. Cascade it to infinity & beyond, ok. ok, up to 128. Cascading this thing longer than that is a bit crazy. But there is nothing stopping you from doing that. 2. Optional. If 128 is all you want. Change the USB report to be 128 instead of the current 64. Trivial. If you want more than 128, well, change the USB report to have to HID report descriptors, and then send back two reports. Each containing 128 buttons. This is not so trivial, but not exactly difficult. Very minimal amount of code change. Time to order a bunch of those buffer chips.

Absolutely no ATMegas! It defeats the whole purpose of using up-to-date electronics. ATMegas are too old as a joystick controller, so are a lot of the PIC MCUs used in today's joystick controllers. I wrote Hempstick mainly because I couldn't find one available on the market that is up-to-date and extendable. Why would I go backward? As to 256 buttons... then I must ask this question. Why stop at 256? How about 1024, i.e. 8x composite joystick controller all in one physical controller? Is 1x 256 buttons controller better than 4x 64buttons $39 controllers? In what way? To really understand why there is a limitation on how many buttons Hempstick is WILLING to handle, you have to understand event-based architecture Hempstick uses. I am writing an article about it right now that will explain why you don't want to use the old way of busy polling that everybody seems to be using, except a few newer ones. Hang tight.

However, let me give you a little warning about using Target with Hempstick. Any USB firmware can do it, not just Hempstick. it's dead simple. No code modification needed. If TM is unhappy about it, they can take it out anytime they wish. As somebody who makes a living out of programming, I fully respect their right to do whatever they wish with their software so I have no intention of circumventing that. Use it at your own risk. However, if they want to take it out. They would have to do the followings. 1. Update Target. 2. Probably also update the drivers. 3. Update the firmware to match the driver change. #2 & #3 above apply to all TARGET supported devices, including MFDs, Cougar, T.16000M. So, as long as you don't update your TARGET and Driver... it will continue to work. Now legality warning. It may be illegal to divulge how to make any non-TM-made controller to work with TARGET, due to DMCA. Although it may be perfectly legal to program Hempstick this way, it may violate your license agreement with TM for using TARGET in this manner. I am not a lawyer, but you have been warned.

You read that right. I did that with my my Cougar-in-pieces too. Of course there are limitations... there is no composite keyboard/mouse thing that Cougar does. You just get a bunch of buttons/axes that you can use inside TARGET and program them. But, that's all you need. You don't need those stinky virtual mouse/keyboard thing with TARGET. TARGET does that for you anyway. You can't program Hempstick with Foxy either because I didn't implement any Cougar-specific settings like axis curving/button mapping thing that used to be stored on Cougar firmware. Why bother doing that anyway, it's a horrible way of doing things while you can do the same thing in TARGET. TM at least made a very good choice of moving this kind of stuff into TARGET instead of having it done in the firmware (both commercially and technically). If you do embark on such a project. Let me know, I will help you produce a better mapping configuration so it's a lot easier to wire up (I use the ball of wires method, but it's possible to use a ribbon cable to make it neater and easier).

If it's just generating straight keystrokes, yes I will add that sometime in the future. It will just behave like a straight keyboard and you can use it to build a hell of a keyboard -- every key hooks up directly to an MCU pin, all hardware debounced, absolutely no matrix, thus absolutely no ghosting. But, unless you have a custom board, there are not enough pins brought out to build a full keyboard, This is mainly intended for input like radio keypad input etc. I mean, you could use button for these, but if it's a keyboard, why not make it a keyboard.

On Resolution Here's an article I just wrote about controller resolution... http://www.hempstick.org/download/articles/OnResolution.pdf. In view of so much interests in the pursuit of higher and higher resolution, I attempt to rationalize why I limit the resolution of Hempstick to 14bit. And to, again, dispute the 16bit resolution myth of the Warthog (damn it, this thing just won't go away!). You be the judge.

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.