Hempstead

The trouble with this protocol is that you can only send uint16_t integers over. You can't send anything else. To be able to send something else, you'd need to extend this and add encoding, like string type, int type, float type, double type, etc. etc.

Ok. say we define the format as the following struct. Note that, these are pseudo code to demonstrate the concept, so forgive me for the possible syntax errors; I ain't no compiler. #define DEVICE_NET_TARGET_DEVICE_LED 0x0001 #define DEVICE_NET_DEVICE_LED_ATTR_R 0x0000 #define DEVICE_NET_DEVICE_LED_ATTR_G 0x0001 #define DEVICE_NET_DEVICE_LED_ATTR_B 0x0002 #define DEVICE_NET_DEVICE_LED_ATTR_INTENSITY 0x0003 #define DEVICE_NET_DEVICE_LED_ATTR_NUM 0x0004 struct { uint_16_t name, uint_16_t value, } attribute; struct { uint16_t target_device, uint8_t num_attrs, attribute *attributes } device_datagram; Then, a device_datagram example would look like this. {DEVICE_NET_TARGET_DEVICE_LED, 0x0005, DEVICE_NET_DEVICE_LED_ATTR_R, 0x0000, DEVICE_NET_DEVICE_LED_ATTR_G, 0x00CA, DEVICE_NET_DEVICE_LED_ATTR_B, 0x00FE, DEVICE_NET_DEVICE_LED_ATTR_INTENSITY, 0x8888, DEVICE_NET_DEVICE_LED_ATTR_NUM, 0x0000} or translated to all hex without symbols. {{0x0001, 0x0005, 0x0000, 0x0000, 0x0001, 0x00CA, 0x0002, 0x00FE, 0x0003, 0x8888, 0x0004, 0x0000} Meaning, the target device control is LED control, and give me the color 0x00CAFE for LED # 0, with 1/2 intensity. So, the processing loops becomes something like this (assuming network byte order and the machine is big endian to simplify the pseudo code). len = recvfrom(fd, buf, BUFSIZE, 0, (struct sockaddr *)&remaddr, &addrlen); if(len > 0) { device_datagram data_gram = (device_datagram)buf; target_num = data_gram->target_device; uint8_t num_attrs = data_gram->num_attrs; for(uint8_t i = 0; i < num_attrs /* && needs to guard against buf overrun here */; i++) { uint16_t current_attr_name = data_gram->attrs[i].name; // needs to store these to somewhere or use them immediately. uint16_t current_attr_value = data_gram->attrs[i].value; } switch(target_num) { case DEVICE_NET_TARGET_DEVICE_LED: // do something with the stored attrs against LEDs. break; /* to support more devices, just add more cases here. */ default: printf("Unsupported device num = %d, damn it, are you trying to crash me?\n", target_num); break; } } See? No string parsing nor scanning. Just go take the data out.

Forgot that it will also need the 5th attribute. 5. Name = 0x0004 (LED #). Also, since each name and each value is two bytes, you do have to specify whether it's big endian or little endian... I would go with the network byte order, i.e. big endian. But it doesn't really matter that much, as long as it's specified.

It's a structured data... I would avoid string processing altogether... i.e. design the protocol so that it requires no string processing... particularly, string processing is not the strong suit of embedded processors. What I mean is that the data is a simple name/value pairs. And due to the size limitation of UDP datagram, if you wish to control many devices (or indicators), you have to send multiple datagrams anyway. So, why not do this. 1. Each datagram is for one device only. 2. First 2 bytes is the destination device id (2 bytes gives you 65536 devices, might want to reserve device #0 as the broadcast). 3. The next byte indicate the total number of name/value pairs. 4. each name is 2 bytes, and value is 2 bytes. No parsing is needed. But the receiver decoding code do have to be carefully written so that it doesn't do buffer overrun in case the total number of name/value pairs is maliciously bigger than the actual. This way, you can send more than one value to each devices, and it's a little extendable -- for now, you only have a couple of name/value pairs. 1. Name = 0x0000 (Red) 2. Name = 0x0001 (Green) 3. Name = 0x0002 (Blue) 4. Name = 0x0003 (Brightness, perhaps PWM control of brightness?) And, later on, you can define more attributes to send. Not only that, each device number can have different legal name/value pair definitions.

Oooh..... plastic rubbing against steel... bad idea.

Here's the regular C code to receive a UDP datagram. recvlen = recvfrom(fd, buf, BUFSIZE, 0, (struct sockaddr *)&remaddr, &addrlen); The receiver already knows the length of the payload. Thus, no need to mark the beginning and the end with marker chars... offset 0 is the beginning, offset recvlen - 1 is the last char. With TCP, stream-based socket, you do need to mark the beginning and the end (or send the length as part of the payload), with UDP datagram... no need for that. No big deal, if it helps you parse the string, I can always skip offset 0 and offset recvlen - 1 chars.

Excellent! I'd be interested in the UDP protocol, as I am trying to make Hempstick support the SAM4E XPLAINED Pro board, which has Ethernet on it. I have a much bigger plan for the Ethernet with Hempstick and will define a protocol for it as well. But if you have a protocol ready, why not supporting it? Saves me time to write the script bridge software module. BTW, I am not quite sure I understand what you mean by "'*' means the string is beginning, ..., and '#' means end of UDP message." A UDP packet is just one packet... and the payload is just one continuous bytes stream with length indicated by the UDP packet payload length. There is no need to mark beginning and end with special characters. I must have misunderstood something.

Did you put the broken ring back?

Sure... as soon as the account request is approved.

User Manual Correction v.1.0.1 I apologize to those who read the User Manual and clicked on the links to libHemp.zip and Hempstick.zip in the PDF file... they don't exist anymore. I have corrected the document on pp.12 to reflect the the move of the source code to GitHub. For the full announcement, please see http://www.hempstick.org/jforum/posts/list/0/6.page#6 Also apologies to those who tried to download the user manual and got 404 yesterday... I honestly forgot I had to put those documents back after I updated the site pages. Sorry, I got to get this process better and less error prone.

You can now PM me at http://www.hempstick.org/jforum to order the PTFE ring. Does not matter which way you do it, PM here or there, I get an email notification and my computer dings me about it.

Hempstick Forum is Online I have added a JForum on http://www.hempstick.org. You can either use the link on the site or you can directly hit it with your browser at http://www.hempstick.org/jforum. Fire up your questions, suggestions, and requests (or demands;-). The Hempstick site now has minimal information. Everything is work in progress, more information will be added slowly, as well as features. Check back often. From here on forward, announcements will be posted on the Hempstick forum. But milestone and important announcements will be cross posted here for your convenience. And you can also PM me there for ordering the PTFE ring.

For toggles, buttons, switches, and anything electronics, Mouser and Digikey have quite some comprehensive collections. But they are a bit more expensive than others. The other one is Grainger. But Grainger is more of anything hardware as opposed to Mouser & Digikey's electronics focus. The other two are Sparkfun & AdaFruit. These are more geared toward the "Maker" crowd. For controller... Obviously I am biased toward Hempstick.

Yes, very easy. Just change a couple of lines in the header file and configuration files and change the USB descriptor to match and you are done. No code change. However, the current supported boards do not wire all the leads out, and they have some on board "stuff" like additional RAM, SD card, etc. that are wired up already. But you can make a vanilla board to bring out all of them.

I can't really say how complicated it would be to really drive the FF motors. So far, Hempstick does only input to the host, but not output. If they really use the standard USB HID FF standard, it shouldn't be too difficult to change the device descriptor and report descriptor and to invoke an RTOS task when a report is received. But what the task does, I have no idea. Particularly, I have no idea how G940 and FFB2's motor drive work. You got to reverse engineer that first. If they use custom Windows driver and sends custom protocol over to the controller, then you got to reverse engineer that protocol too. It's OpenSource, take a crack at it.... I can help, but output to it is low on my priority. I will soon put up a forum on http://www.hempstick.org to support the Hempstick though.

Did you run 22 wires into the Cougar stick with the Bodnar board or 5? With Hempstick, I run 5 using the original PS2 connector; didn't even open the stick to rewire anything. True for regular pit builders that Hempstick just turns your whatever creation into a regular USB HID controller; that's the whole point so it requires no special driver on the OS side! ;-) But it's possible to use TARGET to do the curve and more. Bodnar can't do that. He does that, he will probably lose his USB license over that. But he might be able to implement similar feature and let you change it. I don't know, I am not a lawyer. However, I don't have a USB license to lose and I am not doing it. You are doing it. And it's NOT ILLEGAL for you to do it. USB developers do it all the time. It just might be illegal for me to tell you how to do it, because of DMCA. So I am not tell you how, just that it can be done easily with Hempstick. And it uses much more powerful 32bit ARMs MCUs than other flight sim controllers out there. You can do a hell lot more with these ARMs. Reading the ThrustMaster Cougar/Warthog sticks is just one such example. You want more sensors, and outputs, write it up. There's plenty of CPU cycles available! Actually, this is one of the main initial points I had against using the Bodnar board myself. I bought a Bodnar board, and found out I can't do a lot of things I want it to do. So, I decided to roll my own, which eventually evolved into Hempstick. Since it's OpenSourced, it's perfectly ok for somebody else to design a board laid out more friendly to pit builders, burn custom Hempstick firmware on them, and sell them. It's just that I ain't gonna do that.

That should work, although I have not done it myself. If you wish to have Hempstick masquerading as a TM Cougar, I cannot tell you exactly how, in fear of DMCA. But it should be just some configuration changes without any source code modification. Take a look at this post on SimHQ 3+ years ago, http://simhq.com/forum/ubbthreads.php/topics/3140402#Post3140402. That CADDY was my old handle on CougarWorld. However, Cougar has some of the configuration/settings sent to the board and stored right there, including axe curves. Hempstick does not do that. So, even if you make it masquerade as a Cougar, you cannot use Foxy to configure it. It's just not a Cougar and I have no intention of making it a Cougar. Why bother? Use vJoy.

Yes, it's released under GPL v.2. Free as in freedom!

http://Http://www.hempstick.org Announcing Hempstick OpenSource USB firmware for Joystick and general purpose flight sim controller. 1. Uses Atmel's ARM 32bit MCUs, up to 120Mhz. 2. You buy the supported boards from either Atmel directly or buy the Arduino Due board from anywhere (none of my business). 3. Contains FreeRTOS, a real-time operating system and is fully multi-threaded, unlike Arduino's dumb busy polling loop wasting CPU cycles. 4. Uses voltage level change event-based interrupt handlers tasks to read buttons and switches. No button press, no CPU cycles used. 5. Up to 16 channels of 12bit ADC. Contain a digital averaging noise filter. Can use over-sampling to increase resolution to 14bit w/ software (can do 16bit, but I personally feel it's quite phony so it's artificially limited to 14bit). ADC reading uses DMA freewheeling, without software intervention, so you always get the latest ADC values at the USB report time. 7. Reads TM Cougar and Warthog sticks with hardware (only for MCUs that have SSC modules, SAM4S and SAM3X), so it doesn't waste CPU cycles to generate the right wave form for the stick's buffer. 8. 1000 samples per second, max a full speed USB can do. There is plenty of CPU to do more, but no point of doing that. 9. Configure the USB VID/PID to anything you want. My CH rudder is, for instance, configured as TM16000, as I don't have any USB VID. Works just fine. Currently, these values are compiled in. A planed feature would let you configure them at runtime, as these are written in SRAM, unlike some written in ROM. 10. You get the source code, install the IDE, change a configuration file, press a button and it burns the firmware for you. Instructions in the form of PDF and iBook. For some boards, you will need to buy a hardware programmer, but for some other boards, Atmel includes an EDBG chip on board that allows you to debug/program the MCU w/o additional hardware debugger. Yes, you read that right, YOU BURN THE FIRMWARE. Don't worry, I have step-by-step screen shot instructions walking you through downloading/installing the software tools to pressing the button to compile/burn the firmware. Installing the IDE is not unlike installing a game program. After the installation, all you will need to do are unzip the source code, open the two projects, change a config file and press the build button. 11. Uses Atmel Software Foundation library, so supporting newer faster/better Atmel MCUs would be quite simple. For instance, I just got my paws on a SAM4E board that has a build in Ethernet on die, and Atmel's W23 WiFi module is just announced and availability is imminent. Planed feature includes reading MLX90363 ion SPI digital mode.

If you really want flexibility.... you might wanna wait for my Hempstick controller firmware. Yes. I wrote the firmware last year. I don't design the electronics. I just use ready made boards that uses Atmel's ARM processors, like Arduino Due, and Atmel's SAM4S XPlained Pro. These are 32bit MCUs, up to 120MHz, I have been using the predecessor version of this firmware for my CH rudder to work in TARGET for 2 or 3 years. It contains a FreeRTOS, and is full Multi-Threaded, using interrupt based button/switch reading (unlike Arduino's dumb polling loop for reading sensors/buttons/switches wasting CPU cycles). It can do 1000 sample rate (max. USB Full Speed can do; some Atmel MCUs can do high speed USB, enabling even higher sample rate, but I doubt the utility of over 1000 reports per second). This leaves the MCU cycles free to do a hell lot more things, like reading TM Cougar/Warthog sticks (although I actually use an on die hardware module to read the stick without CPU cycles. ;-). If I have time, and am able to crack the damned protocol, maybe I will support controlling NeoPixels. The source code is up on GitHub, but the main web site is still not up yet. If you are interested, keep an eye on http://www.hempstick.org. It will be up soon, as soon as I can make a bracket to mount the new rack mount server under one of my tables. ;-)

There are two kinds. One is analog, one is digital. The analog one is not called NeoPixel, and cannot be individually addressed, i.e. you control the whole strip with the same color and power, but cannot say pixel one with R50%/G50%/B50%, pixel #2 R10%/G20%/B30%, ... etc. However, the analog ones should work fine for panel backlighting. AdaFruit even sells a ready-made controller for analog strips with which you can adjust the color and intensity. AdaFruit also has a controller called PhaseCandy for controlling strips of NeoPixels. But as far as I understand, you need some software/computer to "program" it.

This has been there for quite some time on AdaFruit, since last year. It has quite some weird protocol. AdaFruit has an Arduino hand tweaked assembly to get it to work. They can be cut down to individual units, each consists of one NeoPixel, plus one current limiting resistor, a complete unit. You can NOT drive it with a straight DC or PWM. You must drive it with a serial protocol. The protocol is basically an 800 baud asynchronous serial protocol, no start, no parity, no stop bit, 8 bit data. No Hardware UART can do no stop bit (either it's 1, 1.5 or 2 stop bits, or longer, but never 0), b/c basically asynchronous serial protocol requires start and stop bit to mark each char. Synchronous serial protocol requires no stop bit, but needs a clock line. But NeoPixel does not have a clock line, so it's sort of a hybrid of an async and sync protocol. And it's sort of a modified NRZ. 1.25ms per bit, 0.4 mark is 1, 0.8 mark is 0. I have been thinking about how to make hardware USART built in to Atmel SAM MCU to drive it instead of using AdaFruit's time sensitive not-exactly-portable software assembly code to drive it (I write my own firmware to drive my panels and joystick/rudder, soon to be OpenSourced). But I have not gotten it to work yet. And for me, driving NeoPixel obviously has lower priority than other features like reading MLX90363 hall sensor, or reading TM's Warthog/Cougar stick. Please do let me know, if you have any luck with it. I'd be very interested.

Really? That'd be interesting to see. Would you mind posting a picture of it? Let's just make sure it's not the Chinese workers omitted the rubber ring, which would cause wear of the ABS plastic rubbing against the steel plate. If true that TM has changed the design without the rubber ring, I'd be glad to get out of this making PTFE ring thing eventually. ;-)

The funny thing is that you went to Russia to hunt for the man who is about 15 miles away from you. Such is the Internet. :smilewink:

http://www.adafruit.com/products/1303