NEW - PropController Project

OK Ben, I got my package today.
First, thanks for getting the project up and going.

I want to also publicly thank you for arranging the the WIZ812MJ modules for me also. These modules are impossible to find here on the underside of the earth. Many thanks for "going the extra mile" as they say. Now I too can join in on the fun.
 
Matt_Edwards said:
OK Ben, I got my package today.
First, thanks for getting the project up and going.
Click to expand...
You are welcome.

I want to also publicly thank you for arranging the the WIZ812MJ modules for me also. These modules are impossible to find here on the underside of the earth. Many thanks for "going the extra mile" as they say. Now I too can join in on the fun.
Click to expand...
Glad I could assist and welcome to the party. ;)
 
I would like to thank everyone who jumped in feet first and bought a PropController board. I'm glad to see there are folks who are interested in learning the Propeller and I'm excited to see what you all create with it. I'm also looking forward to the day where I'm not the lone code contributor. ;)

Also there might be additional Propeller coding opportunities (beyond the PropController) in the near future, so start getting up to speed on SPIN and PASM.
 
DynamoBen said:
I suspect a new opportunity to code with the Prop will surface in the coming months. Sorry to be all cloak and dagger but it's still in the discovery stages and may not happen.
Click to expand...
Sounds great, all other projects aside for the moment,

How long do you figure before we start tying up some loose ends on the PropController Project? There's a lot of things still to be written, and not a lot of direction. I think most of us have been waiting for you to lead on the project, and without much direction, we (or maybe just be) have been idling without much to go on.

I don't think we need to be quite as detailed as say Arduino's documentation and setup, but I think if we're aiming at having an OpenSource Development Aimed board, we need to make it developer and user friendly.

Can we get some people to volunteer for the tasks at hand (or even a list of said tasks at hand?) It's already June and time is winding down to where people don't want to be working on controllers, they want to be sequencing and setting up their show.

I think there is a ton of potential for such a cheap, easy to use, and powerful board, but I think most of that potential has yet to be unleashed.

Josh
 
chilloutdocdoc said:
How long do you figure before we start tying up some loose ends on the PropController Project? There's a lot of things still to be written, and not a lot of direction. I think most of us have been waiting for you to lead on the project, and without much direction, we (or maybe just be) have been idling without much to go on.
Click to expand...

It can and should start now if folks have interest. Like most open source projects the direction comes from what people need. I wrote the code that exists in the project for two reason one was I needed it for my show (the dimmer projects) the other was to meet potential needs I saw in the community (the RGB pixel string and Renard drivers).

Completed ready to run projects would be a good thing, also having new daughter boards with drivers. Testing and improving on the projects and drivers that are already up would be a good thing. Really the sky is the limit.

What can I do to help promote development? What needs to be worked on? What is unfinished?

Loose ends I can think of:

The RGB drivers, with the exception of one, are written to use one output pin. It would be awesome to make all of them work with 4 output pins.

I wrote the Renard driver but have no idea if it works. That needs testing and might need work, not to mention there is no hardware for it.

I have a strong start on an RDM driver, it requires a lot of ASM work which is why I keep putting it on the back burner.

I have a BAM (bit angle modulation) driver to dim LEDs, it needs testing and tweaking but budude isn't finished with the hardware yet. I am happy to post what I've got.

I started adding dimmer curves to the channel driver but got side tracked on those improvements.

The serial configuration code could be started. I don't have anything yet but the protocol exists in another thread.

Someone could try to figure out a modular way to do configuration via a webpage.

It would be nice to have a way to patch channels, the hard part will be figuring out how to configure the patch. (I did this on another project with an LCD and 4 switches, I could post that code)

I don't think we need to be quite as detailed as say Arduino's documentation and setup, but I think if we're aiming at having an OpenSource Development Aimed board, we need to make it developer and user friendly.
Click to expand...

Parallax has a wealth of development information and example code, so I think most of that info already exists. Combine that info with the schematic for the PropController and you are good to go.

With that said having "canned" or premade/modular projects would make it a lot more use friendly.

Can we get some people to volunteer for the tasks at hand (or even a list of said tasks at hand?) It's already June and time is winding down to where people don't want to be working on controllers, they want to be sequencing and setting up their show.
Click to expand...

The task list is going to be based on how people plan to use the PropController for their show this year.

Personally I need to create an input daugtherboard with driver for Halloween so I can trigger Vixen sequences via the network. In addition I could really use a servo board and driver. In my head the daughterboard would be a series of shift registers with a header for a supplemental power to run the servos. The OBEX has servo code to do this I just haven't gotten around to the hardware. Beyond those things I may also need a motor speed controller (hardware and a driver).
 
I do have the hardware for the "Prop48LSD" laid out on a protoboard for testing. I can take the code now if you have it ready to go. Once the hardware is proven out, I'll commit it to the board layout. I "sort-of" have this done as well but need to swap the channel outputs end-to-end as I put them in reverse. It will use all through-hole parts. I'll post a pic of it once I swap around the outputs.
 
Two more for the pile:

I have some older ArtNet code that I believe might still work but defiantly needs optimization.

I would also like to get the sACN code into its own object, the reason is so you can swap between network protocols by just changing objects (IE sACN to Artnet). At present part of the sACN code is in the parent object.
 
Update: I've created an "unreleased" folder within drivers and posted some new code. This contains code that either needs testing or needs work. Once we have confidence that its working we can move it out of there.

New code includes ArtNet, GE Color Effects, Channel Driver /w some dimmer curve code. BAM and Renard are also in there because they both need testing and tweaking.

I've also added two enhancement requests under issues on the project site in regard to the Pixel drivers. I'm not sure if or how the rest of the info I posted should be captured on the project site. Wiki??

Also if you want to be added as a Project committer just PM your request to me.
 
Last edited:
I'm going through right now rebuilding some of the E1.31 to DMX to suit my needs, adding a few features, taking a few out as i don't see them necessary.

Do you think we should create a template file for projects. It seems like the controller is mostly doing a Input, Process, Output (typical to computers huh?) which could be laid out. I'll put some stuff up in a bit to show what i'm talking about.

The channel patching feature you talked about is probably quite simple. Have a recieved buffer, a patch method, and an output buffer, each iteration of the loop, the recieved data goes in the first buffer, the patch moves the data around, and the output buffer is used by the output plugins.

Josh
 
chilloutdocdoc said:
The channel patching feature you talked about is probably quite simple. Have a recieved buffer, a patch method, and an output buffer, each iteration of the loop, the recieved data goes in the first buffer, the patch moves the data around, and the output buffer is used by the output plugins.
Click to expand...

It is easy the hard part is the configuration of the patch when there is no UI. I have patching code, just no way to configure it.
 
DynamoBen said:
Two more for the pile:

I have some older ArtNet code that I believe might still work but defiantly needs optimization.

I would also like to get the sACN code into its own object, the reason is so you can swap between network protocols by just changing objects (IE sACN to Artnet). At present part of the sACN code is in the parent object.
Click to expand...

When you say move the sACN code into it's own object, do you mean just copy the code over, or put it in a seperate cog then the "master"

Right now my ideal configuration would be

0: Master
1: Serial Configuration (calls functions in master)
2: sACN or Art-Net
3: Output1
4: Output2
5: Output3
6: Output4
7: Output5

Does this follow what you were thinking for a pretty basic "starting point"?
 
Last edited:
chilloutdocdoc said:
When you say move the sACN code into it's own object, do you mean just copy the code over, or put it in a seperate cog then the "master"
Click to expand...

Actually if you look at the ArtNet code you will notice that it is a self contained object, any dependencies like the WizNet driver are bundled into it. All you have to do is add ArtNet to the parent code and start making calls to it. That object gathers all the data into a buffer where that data can be retrieved (similar to the DMX object).

The sACN code isn't like that at the moment. Most of the methods are in the parent code (it was easier to develop the proof of concept that way), it would be better to have a single object, and then make calls to it from the parent. That would also make swapping between protocols easier, a single object reference change and you are done.
 
Alright, I'll look into working on that, I'm going to hopefully test the Renard output either tonight or early next weekend. I'm not sure if I'll be developing a PCB for it or not, I'll look into the possibility. What I would like to see is if it can be modified to do more than one Renard output per cog. The ideal situation would be one cog handling each of the headers, which leaves 4 data pins, which means four seperate renard outputs.

Josh
 
chilloutdocdoc said:
...I'm going to hopefully test the Renard output either tonight or early next weekend. I'm not sure if I'll be developing a PCB for it or not, I'll look into the possibility.
Click to expand...

RPM sent me an updated Renard driver today that I need to code review and get up on the site. The PCB part I expect will have two purposes, DMX and Renard. The big dilemma is if it should be galvonically isolated. I'm person request is it had both types of headers on it.

What I would like to see is if it can be modified to do more than one Renard output per cog. The ideal situation would be one cog handling each of the headers, which leaves 4 data pins, which means four seperate renard outputs.
Click to expand...

Except that you might want to make the board more universal and allow Data in (see previous comment), that then would eat up 3 pins.
 
DynamoBen said:
RPM sent me an updated Renard driver today that I need to code review and get up on the site. The PCB part I expect will have two purposes, DMX and Renard. The big dilemma is if it should be galvonically isolated. I'm person request is it had both types of headers on it.

Except that you might want to make the board more universal and allow Data in (see previous comment), that then would eat up 3 pins.
Click to expand...

Both great ideas that I'll run with I'll wait to test the updated Renard library. One feature I'll be coding in is a self check to make sure it's not trying to send out more channels then the data-rate can handle.
 
You must log in or register to reply here.
Back
Top