Electronics-Related.com
Forums

BLDC controller and ATF16V8B/GAL16V8B/PAL16V8B

Started by Unknown September 17, 2014
In article <c153b9c4-95df-4870-acb3-354a16dca8de@googlegroups.com>,
Lasse Langwadt Christensen  <langwadt@fonz.dk> wrote:

>In singles $1.50 will buy you an AVR that Atmel has already written code for >to drive a BLDC sensorless
Info, pretty please? This could be very useful for a project I'm working on...
Den mandag den 22. september 2014 23.57.50 UTC+2 skrev edward....@gmail.com=
:
> On Monday, September 22, 2014 2:32:27 PM UTC-7, Lasse Langwadt Christense=
n wrote:
>=20 > > Den mandag den 22. september 2014 22.59.56 UTC+2 skrev edward....@gmail=
.com:
>=20 > >=20 >=20 > > > > > The problem is PALASM's design of active low logic. However, it =
should not stop us from using external pull-up active high, since it's only= driving MOSFET gate anyway. I tried adding GAL22V10 to it, but the origin= al code base is not very flexible, I ended up rewriting a limited simulato= r (only 2 out of 8 product terms) and probably the synthesizer eventually,
>=20 > >=20 >=20 > > > > So you are going to use an obsolete GAL with half baked or broken t=
ools=20
>=20 >=20 >=20 > >Galasm works fine for GAL22V10. Atmel is still making the compatible AT=
F22V10. and no programmer,=20
>=20 > >=20 >=20 > > > We can buy the chip with it pre-programmed. Once programmed, we don'=
t expect to change this code much.
>=20 > >=20 >=20 > > > > then add a bunch of hardware to detect multiple logic levels to do =
the job that is much better served by 6 pins on a micro or at worst a $0.50= micro ?
>=20 > >=20 >=20 > > > We would still drive this and others (for example, an LED counter) fr=
om a single micro. BTW, i never found any usable micro for $0.50.
>=20 >=20 >=20 > >=20 >=20 > > so you'll go through all that trouble just to (maybe) save a few pins o=
n a micro?
>=20 >=20 >=20 > To avoid programming multiple micros. >=20
So instead you have to program a PAL?
>=20 >=20 > >=20 >=20 > > if you buy one no, if you buy a few 1000 you can get a 48MHz Cortex=AE-=
M0 for $0.50
>=20 > =20 >=20 > > In singles $1.50 will buy you an AVR that Atmel has already written cod=
e for to drive a BLDC sensorless=20
>=20 >=20 >=20 > This would be a dedicated micro. We still need to figure out how to=20 > communicate between this and the main micro.
So why not use 6 pins for the drive? It still has to do all the timing crit= ical work of commutating, you PAL does nothing to help with that -Lasse
Den tirsdag den 23. september 2014 00.11.47 UTC+2 skrev David Platt:
> In article <c153b9c4-95df-4870-acb3-354a16dca8de@googlegroups.com>, > > Lasse Langwadt Christensen <langwadt@fonz.dk> wrote: > > > > >In singles $1.50 will buy you an AVR that Atmel has already written code for > > >to drive a BLDC sensorless > > > > Info, pretty please? This could be very useful for a project I'm > > working on...
http://www.atmel.com/Images/doc8012.pdf -Lasse
On 09/22/2014 09:10 PM, Johann Klammer wrote:
> With the block commutation that you seem to be doing, you can try to add > another input to the GAL for PWM and combine that signal with the driver > outputs for the upper FETs. Using a small uC is probably a better Idea. > you just need power and UART lines...
Actually, you can get all this fairly integrated, with predrivers and Hall comparators already inside. @See NJM2624A... but there are others too... depends on the features you need...
>> With the block commutation that you seem to be doing, you can try to add=
another input to the GAL for PWM and combine that signal with the driver o= utputs for the upper FETs. Using a small uC is probably a better Idea. you = just need power and UART lines...
> Actually, you can get all this fairly integrated, with predrivers and Hal=
l comparators already inside. @See NJM2624A... but there are others too... = depends on the features you need... Not sure how you can control the speed with this chip. ---------------------------
>> Be sure to test the output states and reset on actual hardware. From wha=
t I remember, PALASM(the version from the web) requires some hacking to get= the output polarities right... =20 The problem is the active low output of the PAL series. The original PALAS= M enforces it, but the later verson does not. We just have to rmember that= it is active low; so, i changed my logic to decode '0's rather than '1's. = I believe the GAL series have configurable output inverters, but some of th= e program (including galasm) does not configure it. I am going to download= the (ridulous) 1G bytes of Lattice ispLever to check it out. Then the nex= t step is to figure out how to burn the chips. http://173.224.223.62/motor/wave.jpg ---------------------------
> What is the logic behind that?
I am using the GAL22V10 for BLDC Johnson state decoder, need 3 registers and 6 outputs GAL26V12 for 7-segment BCD decoder, need 4 registers and 7 outputs. up to 9999 RPM 20mA x 7 x 4 =3D 380mA (too much for PIC32MX1) Plan B: GAL26V12 x 4 + PIC32MX1 +++++++++ 3' +++++++++ GAL22V10 Plan C: XC9536 x 4 + PIC32MX1 +++++++++ 3' +++++++++ XC9536
On 09/23/2014 03:38 PM, edward.ming.lee@gmail.com wrote:
>>> With the block commutation that you seem to be doing, you can try >>> to add another input to the GAL for PWM and combine that signal >>> with the driver outputs for the upper FETs. Using a small uC is >>> probably a better Idea. you just need power and UART lines... > >> Actually, you can get all this fairly integrated, with predrivers >> and Hall comparators already inside. @See NJM2624A... but there are >> others too... depends on the features you need... > > Not sure how you can control the speed with this chip. >
I believe by PWM'ing the enable input and using a lo side output as tacho... Oh, it won't do the speed regulating by itself, but that GAL will not do that either...
> --------------------------- > >>> Be sure to test the output states and reset on actual hardware. >>> From what I remember, PALASM(the version from the web) requires >>> some hacking to get the output polarities right... > > The problem is the active low output of the PAL series. The original > PALASM enforces it, but the later verson does not. We just have to > rmember that it is active low; so, i changed my logic to decode '0's > rather than '1's. I believe the GAL series have configurable output > inverters, but some of the program (including galasm) does not > configure it. I am going to download the (ridulous) 1G bytes of > Lattice ispLever to check it out. Then the next step is to figure > out how to burn the chips. >
Not sure when the lattice guys went mad... Atmel seem nicer...
> http://173.224.223.62/motor/wave.jpg
Are you using hall sensors or the back-EMF for position feedback? If it's hall sensors you'll also have to decode the sensor inputs to find the proper output. in that case you do not actually need registers. Just a look up table, actually. Or are you using some fancy hybrid BLDC/stepper thingy...? All that variable frequency stuff would then actually make sense....
> > --------------------------- > >> What is the logic behind that? > > I am using the GAL22V10 for BLDC Johnson state decoder, need 3 > registers and 6 outputs GAL26V12 for 7-segment BCD decoder, need 4 > registers and 7 outputs. up to 9999 RPM 20mA x 7 x 4 = 380mA (too > much for PIC32MX1) > > Plan B: GAL26V12 x 4 + PIC32MX1 +++++++++ 3' +++++++++ GAL22V10 > > Plan C: XC9536 x 4 + PIC32MX1 +++++++++ 3' +++++++++ XC9536 >
I believe 7 segment decoders can also be bought.
On Tuesday, September 23, 2014 8:42:48 AM UTC-7, Johann Klammer wrote:
> On 09/23/2014 03:38 PM, edward.ming.lee@gmail.com wrote: >=20 > >>> With the block commutation that you seem to be doing, you can try to =
add another input to the GAL for PWM and combine that signal with the drive= r outputs for the upper FETs. Using a small uC is probably a better Idea. y= ou just need power and UART lines... =20
> >> Actually, you can get all this fairly integrated, with predrivers and =
Hall comparators already inside. @See NJM2624A... but there are others too.= .. depends on the features you need...
>=20 > > Not sure how you can control the speed with this chip. >=20 > I believe by PWM'ing the enable input and using a lo side output as tacho=
... Oh, it won't do the speed regulating by itself, but that GAL will not d= o that either... So, it's no better than the GALs. The sensor needs to be feed to the contr= oller 3' away anyway, not the power module.
> > --------------------------- >=20 > >>> Be sure to test the output states and reset on actual hardware. From =
what I remember, PALASM(the version from the web) requires some hacking to = get the output polarities right...
>=20 > > The problem is the active low output of the PAL series. The original P=
ALASM enforces it, but the later verson does not. We just have to rmember = that it is active low; so, i changed my logic to decode '0's rather than '1= 's. I believe the GAL series have configurable output inverters, but some o= f the program (including galasm) does not configure it. I am going to down= load the (ridiculous) 1G bytes of Lattice ispLever to check it out. Then t= he next step is to figure out how to burn the chips.
>=20 > Not sure when the lattice guys went mad... Atmel seem nicer...
After they brought Vantis and decided to upgrade their software, and drive = their customer out of dos, and into other vendors. After all, the simple c= ommand tool kept me going on the MACH CPLDs for a while. =20
> > http://173.224.223.62/motor/wave.jpg >=20 > Are you using hall sensors or the back-EMF for position feedback? If it's=
hall sensors you'll also have to decode the sensor inputs to find the prop= er output. in that case you do not actually need registers. Just a look up = table, actually. Yes, there will be hall sensors feeding the micro, and the micro can adjust= the CLK and ENB timings.
> Or are you using some fancy hybrid BLDC/stepper thingy...? All that varia=
ble frequency stuff would then actually make sense....
> > ---------------------------
> >> What is the logic behind that?
>
> > I am using the GAL22V10 for BLDC Johnson state decoder, need 3 register=
s and 6 outputs GAL26V12 for 7-segment BCD decoder, need 4 registers and 7 = outputs. up to 9999 RPM 20mA x 7 x 4 =3D 380mA (too much for PIC32MX1)
>=20 > > Plan B: GAL26V12 x 4 + PIC32MX1 +++++++++ 3' +++++++++ GAL22V10 > > > Plan C: XC9536 x 4 + PIC32MX1 +++++++++ 3' +++++++++ XC9536
Actually, might be able to do it with 2 chips rather than 4.
>=20 > I believe 7 segment decoders can also be bought.
But one chip for a 4 bits shift register or BCD counter and another one for= the decoder.
On 09/23/2014 05:58 PM, edward.ming.lee@gmail.com wrote:
> On Tuesday, September 23, 2014 8:42:48 AM UTC-7, Johann Klammer > wrote: >> On 09/23/2014 03:38 PM, edward.ming.lee@gmail.com wrote: >> >>>>> With the block commutation that you seem to be doing, you can >>>>> try to add another input to the GAL for PWM and combine that >>>>> signal with the driver outputs for the upper FETs. Using a >>>>> small uC is probably a better Idea. you just need power and >>>>> UART lines... > >>>> Actually, you can get all this fairly integrated, with >>>> predrivers and Hall comparators already inside. @See >>>> NJM2624A... but there are others too... depends on the features >>>> you need... >> >>> Not sure how you can control the speed with this chip. >> >> I believe by PWM'ing the enable input and using a lo side output as >> tacho... Oh, it won't do the speed regulating by itself, but that >> GAL will not do that either... > > So, it's no better than the GALs. The sensor needs to be feed to the > controller 3' away anyway, not the power module.
I just remembered that those Hall sensors produce a somewhat glitchy signal, so the thing with using the lo-side fet drive as tacho for the uC would not work. you'll need a state sensitive tacho instead, then you can get away using 1 wire PWM from the uC for setting the power and 1 tacho wire the other way. The state transition detection requires registers, so you'll need a clock input to the GAL. Your tacho-FF will go from 0 to 1 when it sees state change from S1->S2 and down to 0 when it sees the state transition S4->S5. (commutation states S0-S5) You could try closing the speed control loop locally but you'd need at least a bunch of OP amps for the PWM generation and voltage compare as well as some chicken food for the F->V converter for the (analog) PWM control voltage. Those small GALs do not have enough bits to fit a complete digital PWM stage in there. -- "By 'Senile' have I been called.. 'Dickhead' and 'Useless'.. many more.." Yado <sourceforge.net/p/ire/code/378/tree/trunk/tfm/people/misc/yado.txt>
> >>>>> With the block commutation that you seem to be doing, you can try t=
o add another input to the GAL for PWM and combine that signal with the dri= ver outputs for the upper FETs. Using a small uC is probably a better Idea.= you just need power and UART lines...
> =20 > >>>> Actually, you can get all this fairly integrated, with predrivers an=
d Hall comparators already inside. @See NJM2624A... but there are others to= o... depends on the features you need...
>=20 > >>> Not sure how you can control the speed with this chip. >=20 > >> I believe by PWM'ing the enable input and using a lo side output as ta=
cho... Oh, it won't do the speed regulating by itself, but that GAL will no= t do that either...
>=20 > > So, it's no better than the GALs. The sensor needs to be feed to the c=
ontroller 3' away anyway, not the power module.
>=20 > I just remembered that those Hall sensors produce a somewhat glitchy sign=
al, so the thing with using the lo-side fet drive as tacho for the uC would= not work. you'll need a state sensitive tacho instead, then you> can get a= way using 1 wire PWM from the uC for setting the power and 1 tacho wire the= other way.
>=20 > The state transition detection requires registers, so you'll need a clock=
input to the GAL. Your tacho-FF will go from 0 to 1 when it sees state cha= nge from S1->S2 and down to 0 when it sees the state transition S4->S5. (co= mmutation states S0-S5)
>=20 > You could try closing the speed control loop locally but you'd need at le=
ast a bunch of OP amps for the PWM generation and voltage compare as well a= s some chicken food for the F->V converter for the (analog) PWM control vol= tage. Those small GALs do not have enough bits to fit a complete digital PW= M stage in there. I don't need to fit all the intelligence into this power module, just enoug= h to minimize the connections. I need at least two wires: CLK and ENB dri= ven by the micro. In case Mr. Johnson is stuck in 010 and 101. I need to = send a wake-up signal CLR to bring him back to 000. CLR is infrequently needed, so we can modulate it on the CLK or ENB signals= . For example, we can send a higher voltage and/or frequency signal with t= he ENB off. If not, just hookup one more wire.
On Sat, 20 Sep 2014 06:48:52 -0700 (PDT), edward.ming.lee@gmail.com =
wrote:

>>Actually, this is too unstable. The FSM would work if it's already in =
one of the 6 states, out of 64. But if it's not, it won't drop in. I am= switching to decoding a 3 bits Johnson counter:
>>=20 >> > Q0 :=3D Q1 >> > Q1 :=3D Q2 >> > Q2 :=3D /Q0 =20 >> > AHI =3D Q2 * /Q1 * /Q0 + Q2 * Q1 * /Q0 >> > ALO =3D /Q2 * Q1 * Q0 + /Q2 * /Q1 * Q0 >> > BHI =3D /Q2 * /Q1 * /Q0 + /Q2 * /Q1 * Q0 >> > BLO =3D Q2 * Q1 * /Q0 + Q2 * Q1 * Q0 >> > CHI =3D Q2 * Q1 * Q0 + /Q2 * Q1 * Q0 >> > CLO =3D /Q2 * /Q1 * /Q0 + Q2 * /Q1 * /Q0 >>=20 >> >> You might also think about whether you need any "dead time" at the =
clock transition to prevent currents flowing in unexpected ways...
>>=20 >> >In that case, it would be 6 bits 12 states Johnson, with alternating =
rest state. The Johnson counter should work in theory, but the open = source galemu is not showing the right output. The emulator could be = wrong. I am still digging up old books and web pages to verify the = design by hand.
>>=20 >> I know it is a test book nit, but guard against 010/101 states. > >It should transition to a valid state within one or two clock pulses. =
As long as the outputs are zero during the invalid states, we are OK. But it does not. Check it out. Then talk. ?-) =20