Hempstead

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

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

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

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

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

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

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

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

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

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

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

That was on page 2 of this thread.

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

Added a new customization chapter in the User Guide document.

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

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

I don't know nothing about Lua. But the thing is... nobody says you have to implement the full capability of what the protocol can do. Do just the LED part. You can cheat while still conforming to the protocol. ;-) Let's say, you just want to turn LEDs on and off, with no control of intensity with PWM. NeoPixels won't let you do PWM control anyway. So, your first byte will always be 0x0001. 2nd byte will be the 0x0004, then send the 4 attributes (not 5!). Each pair will be 4 bytes. The order of attributes don't matter, but let's simplify it further by fixing the order, and still conforming to the protocol. 1st pairs is always R attribute. 1st byte is always 0x0000, 2nd is always 0xFFFF to turn it on, 0x0000 to turn it off. 2nd attr and 3rd are similar. 4th attr has the first byte always be 0x0004, 2nd byte is the LED number you wish to control. No need to send intensity attr. You can cheat even further, by getting a fixed byte buffer with the following 2 byte arrays. {0x0001, 0x0004, 0x0000, 0xFFFF, 0x0001, 0xFFFF, 0x0002, 0xFFFF, 0x0004, 0x0000} // the on datagram {0x0001, 0x0004, 0x0000, 0xFFFF, 0x0001, 0xFFFF, 0x0002, 0xFFFF, 0x0004, 0x0000} // the off datagram Now, to turn an LED on, take the on datagram, and modify byte 10, with the LED #. And then send the whole datagram over. Repeat this for every LED you wish to control. To turn off an LED, take the off datagram modify byte 10.... In essence, you cheat by taking advantage of the fixed format of only the functions you wish to implement, i.e. only LEDs, by using two template datagram. Well, the protocol is capable of much more, but you only implement what you need, and claim done for only the LED control.

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?