PDA

View Full Version : PropController Serial Configuration



DynamoBen
04-22-2011, 12:10 PM
I've been thinking about different ways to configure the PropController to make it more user (and even developer) friendly. Since there are two flavors of the project (RS485/DMX and Ethernet) the only common communications method between them is the USB interface (which creates a virtual comm port on the PC side). So I've been thinking this might be good way to configure both devices.

Items that might need configuration:
Input/Output Configuration per connector (Dimmer, RGB Pixel, DMX, Renard...)
DMX Start Address(es)
IP Settings
Diagnostics/Status Montiors
Firmware version information

There are two basic ways we could configure the PropController via serial, through a terminal interface like hyperterm, or via a custom serial protocol and an installable PC configuration application.

The hyperterm option means writing a fair amount of code on the Propeller side to support all the different menus and options. The PC app option keeps the Propeller code lite but means that an application would need written and a communications protocol would need to be found or created.

I'm sort of leaning toward the PC app with serial protocol. Thoughts, ideas, comments?

budude
04-22-2011, 12:44 PM
Perhaps a java app to do the configuration? I know next to squat about java but it would make it usable on different platforms.

DynamoBen
04-22-2011, 12:48 PM
Perhaps a java app to do the configuration? I know next to squat about java but it would make it usable on different platforms.

While I know enough to be dangerous in a number of programming languages, I would need someone who is programmer to help with something like this...with that said it seems like a good idea.

erm213
04-22-2011, 02:11 PM
A Java or .Net (C# or VB.Net) should be a pretty easy application to write. If you use an existing protocol, there may be libraries available, making it even easier. If you have to create the protocol, it will be a little more work to do. I do C# development for a living and could help out. I also know my way around java pretty well too.

Erik

DynamoBen
04-22-2011, 02:25 PM
A Java or .Net (C# or VB.Net) should be a pretty easy application to write. If you use an existing protocol, there may be libraries available, making it even easier. If you have to create the protocol, it will be a little more work to do. I do C# development for a living and could help out. I also know my way around java pretty well too.

Erik

Thanks Erik! Any protocol suggestions?

DynamoBen
04-22-2011, 03:51 PM
Let me describe what’s in my head, I suspect that will influence the protocol that gets selected.

What I'm thinking is that the protocol will be broken up into general categories to cover each part of hardware’s functional areas. There would be system level settings (like IP), and I/O level settings (for daughterboard).

I'm thinking that the PC utility would poll for the PropController, in return the PropController would tell the PC app what it supports and provide a list of settings for each item. The best part about this model is that PC app doesn’t need to be constantly updated as functionality is added to the PropController.

So imagine for a moment the PropController has firmware that supports DMX out, RGB pixel strings, SSR Dimmers, and input triggers. When polled the PropController would return strings describing each supported interface, a list of what interface each I/O is setup to use, and the available and current settings for each interface assigned to an I/O. At the system level the PropController would also report its input type (RS485 or Ethernet), protocol being used (DMX or sACN), and the available and current settings (IP, universe configurations, start address)

erm213
04-23-2011, 08:10 AM
No protocols are jumping out at me. I imagine just using the serial interface would be fine. Would there be any dependencies between the settings? I see the idea of having the PropController report back its status and capabilities, but tracking dependencies will be trickier.

Erik

chilloutdocdoc
04-23-2011, 09:52 AM
I'd be up for the challenge as soon as i get my board in. I'm excited to get some code working.
The protocol my robotics team has used before has been a somewhat simple one
Start Byte, Command Byte, Data Byte(s), CheckByte (Sum or XOR), End byte.
$A192.168.001.001(check)! might be an example, if the controller knew that A meant ip address, there's a real name for a protocol like this, I'll have to find my notes or ask one of the guys in the club, I think it's used with GPS satellites or something.

yvaliente
04-23-2011, 10:40 AM
Note to self "read this thread"

chilloutdocdoc
04-23-2011, 10:52 AM
Just jotted down in words what I think some people are thinking it'd look like.

Propeller Interface Example

$!!!

PropController Ethernet V1.00x Firmware
Ref: "Mega Tree Controller"
IP: ###.###.###.###
MAC: XX-XX-XX-XX-XX-XX
Supported Features:
Ethernet In
DMX In/Out
Pixel (WS2801, LPD6803)
DC Daughter Cards (Model XX.XX)
AC Dimming Cards (Model XX.XX)

Current Configuration:
Card 1: DMX Out Universe 1
Card 2: DMX Out Universe 2
Card 3: WS2801 Pixels Universe 3 (ch 1-300)
Card 4: DC Dimming Daughter Card Universe 3 (ch 301-348)
Card 5 (special): Inactive

Please choose a command
(1) Configure Ethernet In
(2) Configure Outputs
(3) Statistics
(Z) Exit


CONFIGURATION SCREEN


PropController Ethernet V1.00x Firmware
IP: ###.###.###.###
MAC: XX-XX-XX-XX-XX-XX

-Configure Ethernet-
Current IP
Current MAC

Please choose a command:
(1) Update IP
(2) Update MAC
(Z) Exit


This way would have the Propeller managing most of it's communication and interfacing, I don't know what we have in terms of resources on it for doing something as nice as this, basically it would walk you through setting it up, and maybe even have an option for first time setting it up?

I don't know if it'd need more EEPROM to be able to accomplish all of this data storage, I haven't worked with Propellers too much yet.

DynamoBen
04-23-2011, 11:14 AM
This way would have the Propeller managing most of it's communication and interfacing, I don't know what we have in terms of resources on it for doing something as nice as this, basically it would walk you through setting it up, and maybe even have an option for first time setting it up?

I don't know if it'd need more EEPROM to be able to accomplish all of this data storage, I haven't worked with Propellers too much yet.

Conceptually we are on the same page. However functionally we are a little off, in that I don't want the prop to handle all the logic to do configuration. I just want it to set or get strings of data and the app would make it look pretty.

DynamoBen
04-23-2011, 11:15 AM
I'd be up for the challenge as soon as i get my board in. I'm excited to get some code working.
The protocol my robotics team has used before has been a somewhat simple one
Start Byte, Command Byte, Data Byte(s), CheckByte (Sum or XOR), End byte.
$A192.168.001.001(check)! might be an example, if the controller knew that A meant ip address, there's a real name for a protocol like this, I'll have to find my notes or ask one of the guys in the club, I think it's used with GPS satellites or something.

Something like that would work. I will try to get a protocol down on paper.

DynamoBen
04-23-2011, 11:18 AM
Would there be any dependencies between the settings? I see the idea of having the PropController report back its status and capabilities, but tracking dependencies will be trickier.


Hmmm good point. My initial response is no dependency checking between values, but I can see how this might not be realistic. The other thing we have to watch out for are boundary values, in that how do we enforce boundaries, or do we not care.

chilloutdocdoc
04-23-2011, 11:39 AM
Alright, we could "wrap" that idea into a GUI, I don't know if the data checking should go to the propeller, or the GUI. I think it's a good idea, we all accidentally type 525 instead of 255, or 912 instead of 192, and that would not make things easy for trying to access the controller again.

erm213
04-23-2011, 11:48 AM
Alright, we could "wrap" that idea into a GUI, I don't know if the data checking should go to the propeller, or the GUI. I think it's a good idea, we all accidentally type 525 instead of 255, or 912 instead of 192, and that would not make things easy for trying to access the controller again.

Since the PropController is actually going to be applying the settings, it could reject, and not apply any "bad" configuration values. This makes the most sense from a design point of view. The obvious drawback to that is the code is more complex on the PropController side, there could be resource limitation that would prevent this from the PropController.

Erik

pmscientist
04-23-2011, 12:37 PM
I like the idea of limiting onboard functionality to get/set operations. It lends itself to both GUI based config and command line configuration. Multiple platforms are hard to support, even with Java. Having a limited, yet functional, command line would allow virtually any platform to connect without having to support them all with a GUI app. You could even expand that interface to be available via telnet, which is really just a serial console transported over IP. I do alot of work with network equipment, which tends to have pretty limited interface resources. The get/set model combined with an independent GUI works really well in that environment, which is pretty similar to this from the perspective of configuration needs.

In regards to configuration checking, I'd also apply a lesson from the network world. Any variable that, containing a bad value, could cause the unit to become inaccessible (invalid IP or serial port speed, or get/set on port 34 when only 32 ports exist), or has the potential to cause a malfunction in external devices (invalid values sent to DMX or RBG devices) should be checked. Any variable that simply results in an undesired operation (disable channel 1) would be optional to check, based on available ROM space and programming time.

Finally, a method to reset to defaults that is independent of any software interface should be provided. Something like, hold down the reset button for 5 seconds during power on, possibly then acknowledged by blinking LED(s) in some pattern.

I don't have any strong feelings on the syntax, other than it should be human readable and include some limited debug commands (e.g. get dump config, get dump registers).

In regards to ROM size, would it be possible to substitute something like a 24C1024 for 24LC512 EEPROM without modification? Both are serial EEPROMs and appear pin compatible to me. I was considering trying to use a 1M chip of some kind to provide for future growth, if it will work of course.

chilloutdocdoc
04-23-2011, 01:18 PM
I think pmscientist has the right idea, while a gui is hard to have cross compatible, having atleast a command line interface (for those of us that choose to use linux or something else) would be useful if we didn't feel like using a windows gui. Frankly I think windows should be the most supported, and it would be easy to write something in C# or java or whatever.

DynamoBen
04-23-2011, 02:36 PM
Since the PropController is actually going to be applying the settings, it could reject, and not apply any "bad" configuration values. This makes the most sense from a design point of view. The obvious drawback to that is the code is more complex on the PropController side, there could be resource limitation that would prevent this from the PropController.

Erik

Checking value boundaries on the Prop side is reasonable and not difficult to do. In fact most of the code I write already does that internally.

DynamoBen
04-23-2011, 02:38 PM
In regards to ROM size, would it be possible to substitute something like a 24C1024 for 24LC512 EEPROM without modification? Both are serial EEPROMs and appear pin compatible to me. I was considering trying to use a 1M chip of some kind to provide for future growth, if it will work of course.

The 24LC512 is already twice the size that is required to use a Prop. I spec'd out the bigger EEProm to allow folks to have settings and what not. The first 32K is used by the Propeller the rest is scratch pad. As far as going to a 1024, should be plug and play.

chilloutdocdoc
04-23-2011, 03:01 PM
Ben,

Do you want to start laying out some of the various commands, I could start working on a GUI, would be safe if it used a .net implementation since everybody here probably already has it so that they can use vixen.

Anybody else want to help with the GUI, preference between C# or Java?

Edit:
Change the ending char to a new line... makes life easier.

DynamoBen
04-23-2011, 06:34 PM
Do you want to start laying out some of the various commands, I could start working on a GUI, would be safe if it used a .net implementation since everybody here probably already has it so that they can use vixen.

Anybody else want to help with the GUI, preference between C# or Java?


I will start figuring out the protocol and the associated commands. As far as the GUI I'm not a big Java fan, probably because I'm a windows guy, so my vote is for C#.

chilloutdocdoc
04-24-2011, 04:35 PM
I'll scratch something together in C# then. I'm looking at starting as soon as possible, but with finals this week, it'll probably be this weekend, would you be handling the propeller side of things?

P. Short
04-24-2011, 07:31 PM
Perhaps I'm dating myself, but snmp over ip over ppp? Or whatever the more popular/current replacement for snmp might be.

P. Short
04-24-2011, 07:32 PM
Or alternatively, a web interface?

chilloutdocdoc
04-24-2011, 07:58 PM
the thought of a web interface would be extremely nice, but i thought that would potentially consume a socket, causing a tradeoff in channels?

erm213
04-24-2011, 08:30 PM
the thought of a web interface would be extremely nice, but i thought that would potentially consume a socket, causing a tradeoff in channels?

jstjohnz's E680 controller is configured this way. If I recall correctly, it does consume a socket when it is on. Like the E680, it does not always need to be on, only when you need to run the configuration. The E680 has a switch that when pressed on boot/reset turns on the web server. There is also a status LED that lets you know the web server is on.

Erik

chilloutdocdoc
04-24-2011, 08:54 PM
jstjohnz's E680 controller is configured this way. If I recall correctly, it does consume a socket when it is on. Like the E680, it does not always need to be on, only when you need to run the configuration. The E680 has a switch that when pressed on boot/reset turns on the web server. There is also a status LED that lets you know the web server is on.

Erik

Oh! Didn't know that was possible. Hey DynamoBen what about the idea of a web interface? I think most people like that better. It could also be done remotely of course (you would have to do hit the switch, but it wouldn't require having to remove the controller from the outdoors)

There would have to be a "reset to default" incase the ip address just happened to become unreachable.

erm213
04-24-2011, 08:57 PM
Here is a link to the project page for the E680.

http://sandevices.com/e680.html

Erik

derekhessman
04-24-2011, 09:32 PM
What if all the capabilities/configuration of the device were stored in a single file. When you poll the device, it would dump the file using whatever protocol you decide. Once you get the file on the host, you could use whatever language you wanted to manipulate the file. The file would tell you all the capabilities/configuration of the device and those you could use on the host side (GUI or command line) to check for values that were out of line as you configure the device. After your configuring is done, your app verifies there are no "brick the device" values and then sends the file back to the device to be stored using your protocol. This would put all the real work on the host app and leave the prop with only the need to read and write the config file and respond to a valid poll and receive new config file requests.

DynamoBen
04-24-2011, 09:43 PM
Oh! Didn't know that was possible. Hey DynamoBen what about the idea of a web interface? I think most people like that better. It could also be done remotely of course (you would have to do hit the switch, but it wouldn't require having to remove the controller from the outdoors)

There would have to be a "reset to default" incase the ip address just happened to become unreachable.

A couple of things to consider. First, it this won't work on the DMX version, since there is no Ethernet connection. Second, it does burn up a socket which isn't a big deal until you need it (I'm not a fan of a odd reset method to get the page to appear). Third, when/if you run DHCP you need a way to find out the assigned IP address. Fourth, creating a custom webpage that contains all the different combinations of options could get tricky.

For the record I have a web configuration already, it eats up a lot of code space and has been a challenge to maintain as I swap different code objects in and out.

P. Short
04-24-2011, 09:46 PM
Doesn't the DMX version have a serial configuration port? It won't be extremely fast, but you should be able to get a web interface over that port, like in the olden days before everyone had 'broadband' connections. I'm not a windows guru by a long stretch, but you can certainly configure a Linux/FreeBSD serial port for IPV4. .

chilloutdocdoc
04-24-2011, 09:48 PM
A couple of things to consider. First, it this won't work on the DMX version, since there is no Ethernet connection. Second, it does burn up a socket which isn't a big deal until you need it (I'm not a fan of a odd reset method to get the page to appear). Third, when/if you run DHCP you need a way to find out the assigned IP address. Fourth, creating a custom webpage that contains all the different combinations of options could get tricky.

For the record I have a web configuration already, it eats up a lot of code space and has been a challenge to maintain as I swap different code objects in and out.

Personally I don't plan on using DHCP as this will be probably one of two things on the network it knows of. Anybody want to hop in the chat and discuss this in real time?

DynamoBen
04-24-2011, 09:57 PM
Doesn't the DMX version have a serial configuration port? It won't be extremely fast, but you should be able to get a web interface over that port, like in the olden days before everyone had 'broadband' connections. I'm not a windows guru by a long stretch, but you can certainly configure a Linux/FreeBSD serial port for IPV4. .

Both versions have a serial port, and I'm not sure where to start to pull something like this off in windows.

DynamoBen
04-24-2011, 11:03 PM
This serial interface is the "lite" configuration tool. I expect over time folks will create webpage interfaces or even implement RDM as they make finished projects. Until then serial is a quick and dirty way to configure things.

Proposed Protocol:
Start Byte (0xFE), Command Class (get/set/status), Parameter ID (16bit), Parameter Data Length, Parameter Data [Variable Length], checksum high, checksum low, End byte (0xEF)

The Checksum is the unsigned, modulo 0x10000, 16-bit additive checksum of the entire
packet excluding the Start and End bytes. The checksum is an additive sum of the 8-bit fields
into a 16-bit response value.

chilloutdocdoc
04-25-2011, 10:37 AM
Started banging out some GUI code. This is a VERY simple implementation, when more details are worked out, Start and End will be set, the commands will be from a list of known commands, length and checksum's will be calculated automatically, and the debugging window will disappear.


http://img846.imageshack.us/img846/3425/proputil.jpg

DynamoBen
04-25-2011, 11:04 AM
Sweet! Now you are waiting on me. ;)

chilloutdocdoc
04-25-2011, 11:08 AM
I've gotten the advanced window to successfully communicate with my propeller, however I've got the COM port hard coded at the moment, I need to find out how to get the list of com ports available, and a few other settings.
Let me know when I can get SVN access I'll put the files in there so you can test it when you get your stuff working.

chilloutdocdoc
04-25-2011, 10:53 PM
I hate to upload completely non working code. But before finals week it's a bit of something you can use to check it out. I've got the exe in debug folder as it's only the debug compilation so far.
Quickstart
1. Update COM# to your Com Port #
2. Click start port
3. Typing with the large text box as the main focus sends data character by character.

To Be implemented:
Checksum Calculator (need to read up on how to do a 16 bit one.)
Send Advanced
Drop Down Menu's for commands
AutoFind COM ports
Help or Reference Material on command listing
Save/Load configuration from file

Suggest features.

jstjohnz
05-02-2011, 11:02 PM
A couple of things to consider. First, it this won't work on the DMX version, since there is no Ethernet connection. Second, it does burn up a socket which isn't a big deal until you need it (I'm not a fan of a odd reset method to get the page to appear). Third, when/if you run DHCP you need a way to find out the assigned IP address. Fourth, creating a custom webpage that contains all the different combinations of options could get tricky.

For the record I have a web configuration already, it eats up a lot of code space and has been a challenge to maintain as I swap different code objects in and out.

You can get around the reset issue by setting it to fire up the web server whenever there is no DMX data on that socket. However the other points are all valid, and the code to do a web server can indeed get very cumbersome.

jstjohnz
05-02-2011, 11:08 PM
Personally I don't plan on using DHCP as this will be probably one of two things on the network it knows of. Anybody want to hop in the chat and discuss this in real time?

DHCP is nice as a backup for the case where, for whatever reason, you don't know the static IP. If DHCP is configured and fails, I have setup my software to assign a 169.254.74.73 IP address so that, worst case, you can cable it directly to a PC lan port, reboot both, and access the board via a browser, since both board and PC will have 169.254.x.y IPs.

jstjohnz
05-02-2011, 11:14 PM
I hate to upload completely non working code. But before finals week it's a bit of something you can use to check it out. I've got the exe in debug folder as it's only the debug compilation so far.
Quickstart
1. Update COM# to your Com Port #
2. Click start port
3. Typing with the large text box as the main focus sends data character by character.

To Be implemented:
Checksum Calculator (need to read up on how to do a 16 bit one.)
Send Advanced
Drop Down Menu's for commands
AutoFind COM ports
Help or Reference Material on command listing
Save/Load configuration from file

Suggest features.

The checksum calculation is just an addition. Initially clear the 16-bit result value to 0, then add every 8-bit byte that's included in the checksum, ignoring overflows. Just like an 8-bit checksum except the sum is a 16-bit value instead of 8.

chilloutdocdoc
05-03-2011, 09:55 AM
DHCP is nice as a backup for the case where, for whatever reason, you don't know the static IP. If DHCP is configured and fails, I have setup my software to assign a 169.254.74.73 IP address so that, worst case, you can cable it directly to a PC lan port, reboot both, and access the board via a browser, since both board and PC will have 169.254.x.y IPs.

I like the idea, but with the thought of the USB configuration, it's just a few button pushes away from a reset or reading the values. Might be easier than the hassle of DHCP. Also, personally I know most of the stuff on my networks is already on Static IP.

chilloutdocdoc
05-14-2011, 05:07 PM
So, stupid me just realized we're using FTDI chips for the prop controller, which are SUPER easy to interface. A gui could be whipped up in No time flat, and if E1.31 with RDM ever comes out, we could use that.

DynamoBen
05-14-2011, 05:09 PM
So, stupid me just realized we're using FTDI chips for the prop controller, which are SUPER easy to interface.

Yup its just a serial port.

chilloutdocdoc
05-14-2011, 09:02 PM
Yup its just a serial port.

Well, imo i like to use the FTDI driver instead of the serial port interfaces.

I'm going to get back on this project, and that SVN tutorial I had promised now that moving my sister to her new house is over.

DynamoBen
05-14-2011, 09:46 PM
No worries I still haven't create any code for this on the prop side, been to busy getting boards out. ;)

chilloutdocdoc
05-14-2011, 10:50 PM
It's ok, we'll get there.

chilloutdocdoc
05-18-2011, 10:00 PM
Ben, do you know of any example code snippets, or frameworks that I could mess around with? I don't have all of my PropController parts in, but I could start testing with my PropDev board that I have.

Josh

DynamoBen
05-18-2011, 11:52 PM
Ben, do you know of any example code snippets, or frameworks that I could mess around with?

I can't think of anything specific. What might be helpful is checking out some serial examples in the OBEX. One of the unofficial requirements I had for this was to not use up another cog, which means that using an object like Full Duplex serial is out. With that said I would going to bundle it in its own object to keep things neat and clean.

chilloutdocdoc
05-19-2011, 03:31 PM
Sounds like a good plan, i sure wish they would write RDM over Ethernet already.

DynamoBen
05-23-2011, 02:22 PM
Some inspiration if you are interested: http://www.parallaxsemiconductor.com/an018

chilloutdocdoc
05-23-2011, 02:45 PM
Looks like a great starting point, still gotta figure out a way to get around the fact that it uses an entire cog. Is there some way we could "shut down" a cog if we don't see it being used?

DynamoBen
05-23-2011, 03:12 PM
Looks like a great starting point, still gotta figure out a way to get around the fact that it uses an entire cog. Is there some way we could "shut down" a cog if we don't see it being used?

For now it might makes sense to use the cog if we need to conserve cog use we can later.

chilloutdocdoc
05-23-2011, 03:25 PM
Alright, that sounds like a plan. We still need to nail down what commands we actually need to get/set lol... Did you want to start a list?

chilloutdocdoc
05-24-2011, 04:11 PM
Alright, I started looking at that App note that you posted, and I'm scratching some Propeller Code together (although it's probably not implemented in the easiest way. I really need to think about how this will be easy on the processor, and how things will be passed to the different objects. Are the objects even all integrated yet?
Also with including all of these commands, we need to decide how we're going to have the chips programmed, will we have enough Flash to store ALL of the code that we need?
I expanded a bit upon the Communication Protocol, and following Ben's layout, I created a slightly different packet for the Prop to send back to the PC. You can see my layout in the attached file.

With everybody now having their boards, and those of us interested in development having our assembled already, I'd really like to see some code get written for the board so its full potential can be reached and used this year.

I will hopefully be getting the code uploaded to the SVN soon that includes the current implementation of the PropSide Communication, and a basic framework for working with the Computer Side framework. C# with .net 4.0 will be used for the computer side.

10382

DynamoBen
05-24-2011, 05:10 PM
I will start working on this more actively and come up with a more complete model for operation (I have some of it done but it is trapped in my head). Once the model is determined then coding would be next. Sorry for the delay, I need to move this back to the front burner.

chilloutdocdoc
05-24-2011, 05:49 PM
I will start working on this more actively and come up with a more complete model for operation (I have some of it done but it is trapped in my head). Once the model is determined then coding would be next. Sorry for the delay, I need to move this back to the front burner.

What can we do help you out? I know the windows form still needs to be done, but without a model together, I'm in neutral.
The assembly guide is coming together, it's on the Wiki, and as more features are added, more documentation will be added.

Josh

DynamoBen
05-24-2011, 06:00 PM
What can we do help you out? I know the windows form still needs to be done, but without a model together, I'm in neutral.
The assembly guide is coming together, it's on the Wiki, and as more features are added, more documentation will be added.

I think I need to at least get draft version whats in my head out to you guys to be able so we can get started.

We already have a protocol framework but the details need to be filled in and we have to much sure it meets our needs and isn't overkill. We need a set of conventions for inter object communication, so settings can be passed around, and objects can be assigned to I/O headers.

The good news is I already have a plan for some of this, the rest needs some more thought. Let me see what I can do in the coming hours and days.

chilloutdocdoc
05-24-2011, 06:16 PM
I think I need to at least get draft version whats in my head out to you guys to be able so we can get started.

We already have a protocol framework but the details need to be filled in and we have to much sure it meets our needs and isn't overkill. We need a set of conventions for inter object communication, so settings can be passed around, and objects can be assigned to I/O headers.

The good news is I already have a plan for some of this, the rest needs some more thought. Let me see what I can do in the coming hours and days.

What did you think of my layout for the protocol, I basically just started laying out ideas, and putting down numbers, and as things got more detailed, you saw it went further to the ones place holder.

It leaves a TON of room for expansion, and i DOUBT that we'll fill it up, by the time we do, i'm sure we could have a web interface or something put together already.

DynamoBen
05-24-2011, 06:20 PM
What did you think of my layout for the protocol, I basically just started laying out ideas, and putting down numbers, and as things got more detailed, you saw it went further to the ones place holder.

I need to digest it fully, is it modeled after RDM? I suspect we will need to send text labels back and forth, so we will probably end up increasing the FullDuplex buffer size.

chilloutdocdoc
05-24-2011, 06:27 PM
Not at all modeled after RDM, i'll have to see if i can find some documentation on the web for it, i was just coming up with how i saw fit, seeing as nobody else was at the moment, if anybody else wanted something different, they can do it.

Does RDM cover all of the stuff we'll have to update?

DynamoBen
05-24-2011, 07:05 PM
Not at all modeled after RDM, i'll have to see if i can find some documentation on the web for it, i was just coming up with how i saw fit, seeing as nobody else was at the moment, if anybody else wanted something different, they can do it.

What you had seems similar based on the quick glance I gave it. You won't find a ton on the web about it.


Does RDM cover all of the stuff we'll have to update?

It might I need to dig the standard back out and see if there is anything useful in there.

chilloutdocdoc
05-24-2011, 08:06 PM
What you had seems similar based on the quick glance I gave it. You won't find a ton on the web about it.

Alright, that sounds good... cause this was just me writing down what my brain was coming up with. I've never even looked at RDM


It might I need to dig the standard back out and see if there is anything useful in there.
Sounds like a plan.

Can you tell I'm anxious?

DynamoBen
05-24-2011, 09:14 PM
Can you tell I'm anxious?

Yes. ;)

DynamoBen
05-25-2011, 02:11 PM
The big challenge is allowing for modularity but not making this overly complex. BTW I haven't spent much time with the previously proposed protocol so consider this in addition to the other proposal. Also this isn't complete, it's just a starting point, and it could be a terrible idea.

Protocol
I gave up on RDM because its a bit too comprehensive for this application. I really want to do something simple if possible. So I'm thinking about changing the checksum to a simple byte add and changing it from 16 bit to 8bit.

For commands I'm thinking 0x20 = get (response = 0x21), 0x30 = set (response = 0x31), error = 0xFF

As far as parameter IDs we could use the RDM IDs or just make up our own, at this point I'm indifferent. If we do our own we will need to maintain a list somewhere, that somewhere might be in the code.

Device Configuration
For configuration at minimum I suspect we will need the following.

Device Name
Version of firmware (not sure if this matters)
DMX start address (universe is determined by start address, 513 = Universe 2, DMX 1)
Network Settings (IP, subnet, gateway, etc...)

Each Output Header would need

Personality Number (Dimmer = 1, RGB = 1, DMX = 3, Renard = 4)
Data Buffer Location Start
Data buffer footprint (total number of channels it consumes, which isn't editable)
Version of code (not editable)


Prop Code
When a new personality is assigned to a output header it launches the correct object into a free cog and configures it based on the settings from the config setting that were sent. The tricky bit is freeing the cog that is already being used, we will probably need a lookup table that tells us which cog is being used at the moment.

DynamoBen
05-25-2011, 02:17 PM
I'm reviewing chilloutdocdoc's proposal and I like it. How can we merge the two proposals to get a workable solution?

chilloutdocdoc
05-25-2011, 02:27 PM
I think we could keep it maintained in code, or in the wiki, either would work well I think.

Version of Firmware: Useful, each time a new feature (new pixel type, output addition) we could increment the revision (V1.X, and for large overhauls increment the version VX.0)
Data Buffer Location: Cool, is it going to be one large (2048 element) array to do this?
Version: Useful
Footprint: This is how many channels it sends out? May be useful to have a number of channels out we're talking?
If you're just talking about how much memory it uses, ignore above comment.
For the renard stuff, it would also require baud rate configuration.

Add: Ethernet Status: Rx'd Packets, Lost/Error Packets, Time online.

Prop Code: What about keeping an 8 element byte array, each cog has it's own element, and each portion of code has its own assignment number. (Master = 0, E1.31 In=1, DMX in = 2, DMX out = 3, etc.)

Since configuration will not be done mid show, it's ok if it takes a bit of time, or if it requires a reset of the controller.. (We can reset via USB?)

I like the idea of reducing the checksum to 8bits, just makes things simpler, do you think an XOR would be more robust or just an unnecessary complication?

Overall, while I think RDM is a great standard, i'm not sure that implementing RDM over USB is really standard anyway, so it'd be ok if we shy away from it and write something now (providing we leave room for implementing new features as they come). I think what you've suggested in modification to the previous protocol, so:

Start Byte (0xFE), Command Class (get/set/response/error), Parameter ID (16bit), Parameter Data Length, Parameter Data [Variable Length], checksum, End byte (0xEF).

How long of data are you thinking of sending in the parameter data? Ideally we could send full strings back from the prop if we wanted to, but considering i'm planning on keeping the Windows App, and the documentation up to date, I don't think it's necessary.



I'm reviewing chilloutdocdoc's proposal and I like it. How can we merge the two proposals to get a workable solution?


Let me open it up, make the changes you've shown, and i'll repost it.

chilloutdocdoc
05-25-2011, 02:49 PM
Additions to Protocol

I think I made sure to catch everything.

10393

DynamoBen
05-25-2011, 03:42 PM
Data Buffer Location: Cool, is it going to be one large (2048 element) array to do this?
Typically I have an array per universe of incoming data, then we need to map the output to a point in the array.


Footprint: This is how many channels it sends out? May be useful to have a number of channels out we're talking?
It's not as much about what it sends out but what it typically uses. For example the 32 channel dimmer board uses 32 channels, knowing this helps you represent the device graphically when patching.


For the renard stuff, it would also require baud rate configuration.
Yeah this an interesting use case, it might be easiest to send the baudrate as a value.


Add: Ethernet Status: Rx'd Packets, Lost/Error Packets, Time online.
Maybe, someone would need to add code for these statistics they don't exist at present.


Prop Code: What about keeping an 8 element byte array, each cog has it's own element, and each portion of code has its own assignment number. (Master = 0, E1.31 In=1, DMX in = 2, DMX out = 3, etc.)

That's all well and good until the number of possible output types exceeds the number of cogs. We could reserve cogs 1-4 for each of the outputs, but that would mean everyone would need to respect that. It's almost easier just to log cog usage in a table and call it done.


(We can reset via USB?)

You can by toggling DTR (you also have to have the programming jumper set) or you can do it in code with a reboot command. I don't know that we will need this though.


I like the idea of reducing the checksum to 8bits, just makes things simpler, do you think an XOR would be more robust or just an unnecessary complication?

I'm indifferent, both are easy to implement.


Start Byte (0xFE), Command Class (get/set/response/error), Parameter ID (16bit), Parameter Data Length, Parameter Data [Variable Length], checksum, End byte (0xEF).

Yup, looks good.


How long of data are you thinking of sending in the parameter data?
What about a max packet length of 256. Too short?

chilloutdocdoc
05-25-2011, 03:47 PM
That's all well and good until the number of possible output types exceeds the number of cogs. We could reserve cogs 1-4 for each of the outputs, but that would mean everyone would need to respect that. It's almost easier just to log cog usage in a table and call it done.


I don't think we're following each other. What i was saying would give us 255 possibilites for each different cog (could even use a word or a long and get 16bit or 32 bit if we needed)



What about a max packet length of 256. Too short?

I'll modify the FullDuplex Serial and it'll work, I don't think it's too short, i don't forsee most things going over 10 bytes, but it's good to have the flexibility.

Check out my revised command list I uploaded.

DynamoBen
05-25-2011, 04:11 PM
I don't think we're following each other. What i was saying would give us 255 possibilites for each different cog (could even use a word or a long and get 16bit or 32 bit if we needed)

Maybe make it word sized, then we have room to expand as new objects and derivatives are created. Although Longs are the "native size" on the prop... (might not be worth the extra bytes)


...i don't forsee most things going over 10 bytes, but it's good to have the flexibility.
Text labels should be no more than 32 bytes in length, too.


Check out my revised command list I uploaded.
Where?

chilloutdocdoc
05-25-2011, 05:09 PM
Maybe make it word sized, then we have room to expand as new objects and derivatives are created. Although Longs are the "native size" on the prop... (might not be worth the extra bytes)

Sounds good



Text labels should be no more than 32 bytes in length, too.

Good Plan



Where?

Post 68

DynamoBen
05-26-2011, 10:09 PM
Looks good to me, I suspect it will continue to be tweaked ultimately it seems like a workable solution.

chilloutdocdoc
05-27-2011, 12:16 PM
Alright, let's get cracking, i'll start on the computer side of things. Should have something together soon, wiki's a priority at the moment.

DynamoBen
06-03-2011, 12:07 PM
OK don't hate me for this, but I want to throw out a little different idea and see if it has legs.

Up to now we have focused our efforts on a client side app and a custom serial protocol. The other day I read this appnote (http://www.parallaxsemiconductor.com/an005) which got me thinking. While I know doing VGA with keyboard would be overkill I wonder if instead of a client side app we should just be using a terminal interface. This would allow any terminal app to connect to the device and the user could then navigate menus. This technique is commonly used on network gear via the "console" port. In our case the menus would need to be generated dynamically and each object would be responsible for presenting the available menu options to the parent to be displayed to the user.

Now I know a bunch of time has already been spent on client side app and protocol, but I wanted to put this out there to see if we should change direction or continue on the path we are already on.

chilloutdocdoc
06-03-2011, 12:44 PM
You knew I was going to be working on the serial setup soon. So this method would require each protocol's object to service it's own menu? Or would the master menu object service everything? I'm a bit confused on how it works, although this would make it easier in the long run, and there would be less for there to be kept up. Although with this much effort to do it via terminal, do you think going the extra step further is worth it and just doing it over Ethernet?

DynamoBen
06-03-2011, 12:58 PM
You knew I was going to be working on the serial setup soon. So this method would require each protocol's object to service it's own menu? Or would the master menu object service everything? I'm a bit confused on how it works, although this would make it easier in the long run, and there would be less for there to be kept up.

First off this is just a concept, and could be a bad one at that.

As far as functionality I'm thinking the serial object would handle the look, flow, and I/O of the menus and what not. The object would need to provide structure, text, and options. I might need to mock something up, but see the example below.


Although with this much effort to do it via terminal, do you think going the extra step further is worth it and just doing it over Ethernet?

Even with ethernet you need a way to configure the IP address, so the need to configure via serial doesn't go away. However much of this might be usable by an HTML.




Switch Main Menu
================

1. System Configuration Menu

2. Port Status

3. Port Configuration

4. System Mode (Layer 2 / Layer 3)

5. Help

0. logout

ArrowKey/TAB/BACK=Move SPACE=Toggle ENTER=Select ESC=Back
>

chilloutdocdoc
06-03-2011, 01:27 PM
Looks like a great idea, I don't have any experience with this type of setup, otherwise i'd start laying it out. We could probably keep a lot of the old protocol, the menu based system, etc. Past that I'll have to read up, let me know what you'll need help with.

DynamoBen
06-03-2011, 01:45 PM
Looks like a great idea, I don't have any experience with this type of setup, otherwise i'd start laying it out. We could probably keep a lot of the old protocol, the menu based system, etc. Past that I'll have to read up, let me know what you'll need help with.

I have to do some more reading and thinking on this too, but clearly that is worth doing so I will continue. As I think of stuff I will post back.

chilloutdocdoc
06-03-2011, 02:43 PM
Maybe the parent has a set protocol to communicate from the child, and it just passes data back and forth. I envision the parent just printing a set of buffers stored in the child memory (pointers), and then passing the response back into the child which in turn updates those buffers. It's going to take a bit of thinking if you don't already have an idea.

DynamoBen
06-18-2011, 01:05 PM
The config util has been retired, in case anyone is looking for it.

chilloutdocdoc
07-06-2011, 10:44 PM
Just a few teaser pictures.

Ethernet to Renard Converter. Capable of inputting 4 universes, capable of outputting 4 universes, independent of each other, or copies of each other.

So far it's logged about 750k E1.31 Packets (total, only about 100k this boot time). The new sACN driver is looking great, along with simultaneous serial communication.
1069010691