|
|
Post by jimsfield on Apr 21, 2010 16:09:04 GMT -5
The PS3 really runs like a computer in that it has a CPU and much of its functionality derives from the software that runs on it. The UMC-1 has chips that have functionality built into them. This is a two edged sword. The chips make it less expensive to build but they are limited by the functionality built into them. Part of the functionalty of the UMC-1 comes from the way the chips are hard wired and part comes from the firmware that runs with the chips. The hardwiring can't be changed. The firmware can. Rewriting the firmware is a big job for a small company like Emotiva.
Bill, if I've not got this right feel free to make any corrections you want. BTW I like your attitude and appreciate the effort you've put into making this process easier for all of us.
|
|
|
|
Post by hollip3020 on Apr 21, 2010 17:06:29 GMT -5
Bill,
If this were my product, I wouldn't outsource the tool in the first place. I wouldn't expect an outside developer to know the best way to interface with the product. I would, however, expect it of the people who designed it. Also, USB interfacing is relatively easily accomplished within any .Net environment. As such I don't see the financial benefit. Not only that, but outsourcing the tool effectively limits it's operation to whatever the developer determines, which, as we've seen, may not be the best. In that case, it'll cost even more money just to get a better process developed; another strike in the financial department.
To me, updating a product, no matter how many times during the products life it will occur, is an essential aspect that should be handled in house no matter what the cost. It's the only way to truly assure it will be performed correctly and be nimble enough to change as needed.
Assuming they outsourced the tool (which I'm guessing is what they did due to your proposal), and assuming option A from your question, I still don't see any reason they couldn't use something like AutoHotKey to automate the computer side of the process. It's obviously not the ideal solution, but my guess is it would alleviate at least a few of the issues.
|
|
|
|
Post by BillBauman on Apr 21, 2010 18:20:10 GMT -5
Bill, If this were my product, I wouldn't outsource the tool in the first place. I wouldn't expect an outside developer to know the best way to interface with the product. I would, however, expect it of the people who designed it. Also, USB interfacing is relatively easily accomplished within any .Net environment. As such I don't see the financial benefit. Not only that, but outsourcing the tool effectively limits it's operation to whatever the developer determines, which, as we've seen, may not be the best. In that case, it'll cost even more money just to get a better process developed; another strike in the financial department. To me, updating a product, no matter how many times during the products life it will occur, is an essential aspect that should be handled in house no matter what the cost. It's the only way to truly assure it will be performed correctly and be nimble enough to change as needed. Assuming they outsourced the tool (which I'm guessing is what they did due to your proposal), and assuming option A from your question, I still don't see any reason they couldn't use something like AutoHotKey to automate the computer side of the process. It's obviously not the ideal solution, but my guess is it would alleviate at least a few of the issues. I think you and I are just going to have to agree to disagree on this one. That said, for a little clarification, yes, you can interface with USB from .NET, but you cannot (feasibly) write a device driver in .NET. Are you proposing that Emotiva should have written their own USB device driver? That certainly would NOT have been cost-effective in any way at all ever I can't emphasize it enough in a run-on sentence (stopping for breath). Are you proposing they should have hired a full-time .NET programmer to write an overlay application on to the solution they chose? Or, are you saying they should have hired a contractor to write such piece of code? Isn't hiring a contractor the same as outsourcing? Only, more expensive, and that person has to be paid to come up to speed on the solution. From this perspective, I can't see why they're using those outsourced DSP's, they should have just built one. To say that the update program would be best understood by the people that created the product is, well, naive, at best. Are you saying that the DSP programmers should become .NET programmers and learn the Silicon Labs EC2 interface model in order to be able to update one product? That would be more cost-effective? I guess I end up right back where I started. It's a low-cost, entry-level, high-performing system. There is no budget in there for hiring an in-house developer (that I guess you fire when the project is done). One goal of any (well-thought-out) development project is generally to reinvent as few wheels as possible. Sometimes, that doesn't work out all that well. Emotiva isn't in the business of writing Windows programs, or Linux programs, or writing device drivers. They are in the business of building audio equipment. Assuming the budget for creating update programs has been spent, if you want to volunteer to implement an automated response system that will improve the update process, I'm sure Emotiva will listen. |
|
|
|
Post by gkarracer on Apr 21, 2010 18:22:08 GMT -5
Since the updater is apparently only a user mode process and is very time sensitive, I wonder if raising the priority of the process would help prevent other processes from stealing valuable CPU at critical times. Has that been tried at all? Of course, without a post checksum it is hard to verify when it's completed correctly.
I may try this when I update. At the moment I'm holding off for V7.
|
|
|
|
Post by BillBauman on Apr 21, 2010 18:26:58 GMT -5
Since the updater is apparently only a user mode process and is very time sensitive, I wonder if raising the priority of the process would help prevent other processes from stealing valuable CPU at critical times. Has that been tried at all? Of course, without a post checksum it is hard to verify when it's completed correctly. I may try this when I update. At the moment I'm holding off for V7. I had thought of this, but I figured explaining how to accomplish it (and some potential pitfalls of doing it) wouldn't be worth making it a public idea. But, since you bring it up, go for it! I theorize it would certainly help, but you probably want to give the process Realtime priority. If it hung, you might end up with a relatively non-responsive PC. Not that it's a huge deal, since theoretically you won't be running anything else concurrently, anyways. |
|
|
|
Post by hollip3020 on Apr 21, 2010 19:21:55 GMT -5
Are you proposing that Emotiva should have written their own USB device driver? Certainly not. You mentioned in your "initial" post in this thread that the controller comes packaged with a generic driver and I'd assume that driver comes with enough built-in functionality to allow basic I/O to the point that it wouldn't need to be rewritten to allow data to be transferred to the unit via the updater tool. (I can do run-on sentences too!  ) Are you proposing they should have hired a full-time .NET programmer to write an overlay application on to the solution they chose? Not necessarily. Are you saying that the DSP programmers should become .NET programmers and learn the Silicon Labs EC2 interface model in order to be able to update one product? That would be more cost-effective? I find it hard to believe that none of their programmers know or couldn't learn .Net and the interface model in a reasonable amount of time. And no, I don't think it would be for only one product. It's perfectly reasonable that they'd use the same controller on the XMC-1 and other upcoming products (that's what I'd do), which would then make it plenty cost effective. Maybe not necessarily for the UMC-1 but down the line most definitely. Assuming the budget for creating update programs has been spent, if you want to volunteer to implement an automated response system that will improve the update process, I'm sure Emotiva will listen. If it means I'll get my UMC-1, sure. I think you and I are just going to have to agree to disagree on this one. Fair enough. |
|
|
|
Post by BillBauman on Apr 21, 2010 20:00:42 GMT -5
hollip3020, your response is well put and well received.
My response, in re-reading it, was not. I'd like to apologize for the tone of my response. I was hoping to make it back from the gym and apologize before you responded, but I'd rather it be a little late than never. I feel as though the tone of my response was overtly aggressive. None of that was my intention, nor is it how I want to represent myself here. That sort of tone only deteriorates constructive discourse.
Back on topic, it usually would be a perfectly reasonable assumption that the code could be reused, but in this case, I don't think that assumption would hold true. I guess I am working from a bit more knowledge, so my assumptions reach different conclusion. I have it on good authority that the next generation platform will be a departure from the current generation in how firmware updates are applied. So, although the process might (I can't say for sure or for not) be applicable for the XMC-1, it won't be applicable (at least, not planned) to any generation past that. That might change your perspective on writing an in-house app, I know it would alter mine.
I do appreciate your perspective here. I'm curious, if someone were to dissect the commands (it should just be an RS-232-based command set), do you think you could piece together a .NET-based loader for them?
Again, I apologize for my earlier attitude. I know excuses are just excuses, but I think I'm lacking sleep, as I was up way too late last night teaching myself how to use php to access a MySQL DB from a web form. ;D
|
|
|
|
Post by hollip3020 on Apr 22, 2010 0:51:52 GMT -5
My response, in re-reading it, was not. I'd like to apologize for the tone of my response. I was hoping to make it back from the gym and apologize before you responded, but I'd rather it be a little late than never. I feel as though the tone of my response was overtly aggressive. None of that was my intention, nor is it how I want to represent myself here. That sort of tone only deteriorates constructive discourse. Don't worry about it. At least your arguments are cohesive and knowledgeable, which is more than can be said about 99% of the forums out there. Plus, I enjoy a stimulating debate from time to time. Back on topic, it usually would be a perfectly reasonable assumption that the code could be reused, but in this case, I don't think that assumption would hold true. I guess I am working from a bit more knowledge, so my assumptions reach different conclusion. I have it on good authority that the next generation platform will be a departure from the current generation in how firmware updates are applied. So, although the process might (I can't say for sure or for not) be applicable for the XMC-1, it won't be applicable (at least, not planned) to any generation past that. That might change your perspective on writing an in-house app, I know it would alter mine. I think I'd still keep the development in-house, if only for the purpose of keeping it flexible. Even if the overall process changed, interfacing with the unit would probably stay relatively stable. Because of that, I still see a financial benefit. I do appreciate your perspective here. I'm curious, if someone were to dissect the commands (it should just be an RS-232-based command set), do you think you could piece together a .NET-based loader for them? I wish I had time. Today was one of the few days in which I've had a relatively light workload. I average around 60 hours/week and often work through the weekend as well. The hours aren't the greatest but I love what I do. Again, I apologize for my earlier attitude. I know excuses are just excuses, but I think I'm lacking sleep, as I was up way too late last night teaching myself how to use php to access a MySQL DB from a web form. ;D Keep at it. I've already had to fall back on web development a couple times between jobs. It provides a nice little stop-gap in between major projects, and, if you can do the design/development double whammy, can pay more than some traditional soft. eng. jobs. Unfortunately, unless you can find a company that needs a full time web developer, it's intermittent at best. Anyway, we should probably get back on topic. |
|
|
|
Post by jimsfield on Apr 22, 2010 7:55:16 GMT -5
Very refreshing to read an exchange on this forum between two knowledeable people who disagreed and yet were respectful, even if I didn't understand it all.
|
|
)