I sure wouldn't design a motor driver without ever connecting it to a motor.
What kind of motor is it? DC motors make back EMFs. Steppers have variable coil inductance. Both store rotational energy. All sorts of fun stuff.
-- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
The fact that the title of this thread has "BLDC motor" in it certainly indicates that it's a BLDC motor.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Hi John,
John Larkin wrote: []
Do not underestimate the garbage you could produce within an FPGA and how eventually strongly coupled are all those tiny synchronous FSMs, just to the point that they become a giant blob of gates!
The idea to break functionality into small, manageable pieces of logic, which interact in a /controlled/ way is very applicable to software as well. Yet the practice is not always the most common one.
The biggest hazard in FPGA is the very same as software...a big blob of unstructured and unmaintainable code. Most of the times functions are tightly coupled and faults in one propagate way too far before revealing themselves. In the end a debugging nightmare.
As the number of IPs and their configuration space increases, a very similar scenario is starting to appear in the ASIC/FPGA world as well (and we do not have open/free platforms to play with like we do with software).
You can do the same horrors on FPGAs fabric, but as I said, the software complexity is way bigger.
Threads do provide a very similar level of 'concurrency' between tasks. The main difference I see is in the mindset. When you have to go to silicon the cost is such that you are forced to instrument your code with lots of testing features and the verification is not something you can scrap off the schedule easily.
IMO this is why big software projects fail or are far too expensive since they inherit the very quick modify-compile-try cycle from the 'hello world' program, believing that you can *always* modify the code. When you are forced to change the pillars of your software it may easily fall as a card castle, beyond repair. Yes you can change the code, but the consequences are far too often not perceived correctly.
Al
On a sunny day (11 Dec 2014 23:49:50 GMT) it happened snipped-for-privacy@gmail.com (alb) wrote in :
Hi Al, yes I agree 100% with you on all points. That may be an unicum, but OK.
After posting reply to J.L. I was looking last night if opencores.org still existed, and yes, and in the processor tab I found old Apollo guidance system. Did you write that?
BTW of course processors are not 100% checked these days either, have long errata, say PICs or even 386 had long lists. Still undetected bugs happened, say 386 math bug.
I use gcc, it is a good compiler, PICs and other micros I like to program in asm. I try to avoid libraries but this is not always possible, [avoid] mostly because library APIs change all the time, do not like to rewrite soft every time. The rest I write in C, C is extremely portable, compilers (or gcc support) exists for most micros. Most errors I make are typos (all the time with this keyboard), gcc will find those, assembler will find those. For FPGA I use Icarus verilog and then webpack or whatever. I do not really understand the problems people like J.L. seem to have with code. I think he has some slave coding for him?
Coding is very much like math, just the same in an other language. Like telling somebody directions, go left, go right go right again, if you make one mistake than everything after that is wrong. What's the problem? If you can solve the problem (know where to go) then you can tell the computah to do it too. If you do NOT know how to solve the problem (where to go), work that out first (we have great tools for that these days, mathlab, octave ,etc) and then start giving directions (to the computah, processor, how to wire the hardware). Do you need to think object oriented of learn python because you are too lazy to learn C? or even bash scripting? Too much is babble and too little code is released by those people. They always complain and never come with solutions.
I play like this:
J.L. was stating 'timing is no problem with the current FPGA tools', at the same time he is dangling with pico seconds for some laser fusion. if timing is no problem what is the deal? OK.
And my programs have bugs, I could say those are features, not bugs, but I would be lying. J.L. claimed several times in the past his programs or hardware is bug free. have not heard that much of that lately. My thoughts for the moment.
So, I was actually talking to him, will need to copy this OK (saving text).
Hi Jan,
Jan Panteltje wrote: []
project maintainer is Dave Roberts, what makes you think that I wrote that??? While I certainly encourage the sharing of IP cores with free (as in libre) licenses to foster collaboration and preserve the right to protect your ideas, I find opencores.org a timid attempt to provide a platform of exchange.
When at my GNU/Linux console I can install a package from a trusted source in a matter of seconds. The package comes with documentation and a horde of people willing to help/share/contribute.
Try to imagine a similar world for FPGA development, as of today is just a chimera. And EDA vendors are not certainly helping to make the transition.
it all depends on the project criticality. Manned missions CPU systems are massively complex yet with a reliability that is extremely close to
100%. And bugs are documented so that are avoided operationally.I'm not sure what kind of validation you can get of your gcc, but I can tell you that cross-compilers for a space rated processor are rather expensive. And they *are* validated.
as long as the library has been previously validated you could use it as is, but you need to prove that you did not change a single line of code. Otherwise it'll be as if you wrote the library and you have to provide verification of that code.
[]the problem is that when you make a mistake, the impact may appear many hours, days, years after that mistake. Dormant bugs lay in your code until an assumption is misinterpreted or an environment condition has drifted beyond the original considered margins.
Sure, the solution may well be to throw away your code and restart, which you won't do it so easily because you are sentimentally or psicologically attached to it and you drag on with a crappy piece of software.
[]I like your meditation technique...after few minutes in the meditation I'd fall asleep for at least a day or two... :-)
Nearly all of them have, the difficult part is to know them and identify way around the bugs.
Al
Ah. Good point.
Even more reason to connect said driver to said motor. Or at least to a similar motor. Besides, spinning things is fun.
-- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
On a sunny day (12 Dec 2014 15:41:01 GMT) it happened snipped-for-privacy@gmail.com (alb) wrote in :
Hi Al,
Well, OK, it is better than nothing. Had not been there for maybe 10 years, happy it still exists.
Now wait a minute, but maybe that is more for sci.crypt, but 'trusted' is a word that makes me wonder twice. Recently FSF released a program that is supposed to find government spy programs... now who controls who, we see RSA was payed 10 million to put a NSA hack into their encryption. Open SSL or whatever Sel-Linux?? yamustabekidding.
When I started with 'Linux' in 1998? it was SLS Linux, found it on some CD that came with a magazine. Because the apps I needed (not that the apps word even existed at that time) did not even exist, so started writing my own. Honestly sometimes because it was faster and more fun than RTFM for things others wrote, that is how this news reader I use (NewsFleX) was born, I needed a Free Agent for Linux.
I did use some jpeg encoding stuff that many years ago from opencores, and I learned a lot from looking at others code.
We used to say: The difference between professional equipment and just commercial stuff is that he professional equipment has all things documented. Need not be better though, sometimes it was not.
Yes, and no. There is the F35 (fighter), and recently on the air show in the UK (where it could not go because it was grounded and limited to a 4 hour flight or something), there also was a small fighter design made with of the shelves parts, faster, cheaper, and 4sure better than the F35, in the sense that it did really fly for example. So all the bean counters or women quotes in power of political assigned puppets who decide where it goes are fully concentrated on job creation and not an any result whatsoever. At that point J.L. is right, large software projects are sold because what is really sold (at the most) is simulations, that cargo handling system for the UK for example, and reality was a bit different, cost overruns, customers pissed etc. We had the same with the tax system modification software, millions were spend, and nothing worked.
Sure, work from bottom up, modular, I re-use code I wrote all the time. So do not use exotic languages, keep an overview of the total thing, NASA had that landing gear switch problem on one of the mars landers that caused it to crash. In the time of Von Braun there was one man who knew his stuff who had overview, he was bottom up. Now some ballpen sucker in the pentagon draws up something and it goes nowhere. Like an architect that does not know about stones.
No, it means you had no clue when writing it, I know, I often have no clue, and have to search of hours or find out the hard way how to do it, but that experience is worth it, from that point on things fly.
I have several directories with programs i started and then abandoned (never finished) because there were better ways. In fact I have so many programs that on a regular basis I run into some code (and gave it name too) I wrote, and just wonder 'what in the world is this', If i did not bother with a README, run the -h for help, if that still means nothing then I have to read the source.. Oh yea, I remember now.
Would I trust my life with my own programs? Probably not :-) But, if I had to, maybe yes. Depends.
Sure, some people design logic hairballs. But the true religion of synchronous logic design can be taught, to willing listeners, pretty quickly.
Programs are never commonly-clocked synchronous state machines, and the interactions are not synchronous or necessarily atomic. Emulating the FPGA model in software is possible (I do it) but rare. Most multi-thread programs, and maybe most single-thread programs, are hairballs.
My guys test bench things before they run it, with logic simulators. FPGAs usually work at first compile. The worst situation is when we use other peoples' hard or soft IP, which tends to be poorly documented. So we often do stuff by hand, like DDSs, to be sure we understand it.
An FPGA doesn't have an OS or RTOS, so at least we don't have to fight that.
Sure. I have observed here in the past that, the easier it is to change something, the less likely it will be right. Software can be changed and compiled and run in seconds, so people tend to hack and try it. I do that myself for things like screen layouts... futz it until it looks good. People who build bridges and airplanes and ASICS tend to be more careful. I think FPGA designers tend to be more careful than c coders.
Good book: "Showstopper!" by Zachary.
Yeah, the tipping point is when the project complexity exceeds the module quality; then, as you say, it often goes to hell. Small single programs, like the embedded things that Jan (and I) write, can be done well and quickly. The dangerous size of a programming team is two or more.
We live in the dark ages of computer programming. Something better has to come along, along the *rough* idea of LabView.
One of the best programming languages of all time was/is COBOL.
-- John Larkin Highland Technology, Inc picosecond timing laser drivers and controllers jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
And PM motors look like gigantic capacitors at low frequency.
Cheers
Phil Hobbs
-- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
how about just using switches to do commutation and do the current regulation with a buck preregulator?
-Lasse
Hi Frank, my apologies for such a delayed reply, the thread has moved to s.e.d. a week ago and I did not inform c.a.e. promptly (shame on me). I took the liberty to crosspost your reply on s.e.d.
Frank Miles wrote: []
Maybe not a showstopper for my application where the motor is *always* running and is stopped only in non nominal cases (profile reconfiguration, or similar stuff).
An open-loop will not be able to attain the precision required. The whole system is thought to be operated in closed loop.
Al
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.