Small victory in embedded hardware
pedward
Posts: 1,642
11 years ago Motorola released the Nitron chips, the family of 68HC908 chips in 8 and 16 pin variants, with between 1KB and 4KB of flash memory. At the time this was a big deal because the chips were $2 and ran at 3.2Mhz. These are really neat and capable chips, with timers, ADC, and interrupts. The architecture is missing the serial modules, but that isn't such a big deal.
My minor victory was actually getting to use these after 11 years!
I got one of the QT4 demo boards, but the little flash bootloader didn't work right. I also have an ICSGP20 programmer/ICS tool for the 40 pin and 44 pin variants, so I made an adaptor board to program the QT and QY chips.
The entire reason I purchased the QT4 and QY4 chips is to do simple and mundane things, basically an ASIC chip for certain tasks.
My renewed interest has been to write some software that can interface with quadrature encoders and interface with the Propeller as a co-processor. The QY4 chip has 14 I/O, which would be good enough for 6 encoder channels, pluse CLK/DATA for communication with the Propeller.
I've been playing with an old ball mouse for positional feedback to the Propeller, but I want to interface with high resolution optical encoders, like used in inkjet printers, and have control over the software that does the interfacing.
A while ago I posted a simple approach to interfacing with a quadrature encoder, that turns the process into a state machine using the last bit input and the current bit input as array indices to a 0, +1, and -1 value.
In essence you do something like: count += gray_code[old_value][new_value]
It's as simple as that.
I will probably put the code into an ISR and make all of the input pins fire one ISR, and just process all input every time.
It wasn't straightforward to get the development tools working on 64bit windows either, but I got Codewarrior 6.3 running on Vista x64 inside VMWare 8, talking to a USB serial adapter, all running on Linux.
Once I'm done writing the firmware (it will be C, possibly with inline ASM), I'll release the source code and binaries. I may even offer pre-programmed chips for sale.
The interface with the Propeller will either be by emulating a mouse, or via SPI. I could use the mouse driver as a structure and modify it to support additional channels.
Q&A
Why do this when the propeller has 8 cogs?
Well the answer goes back to the original purpose I bought these chips, to make custom ASICs, in this case it's a multi-channel quadrature encoder co-processor. Let the co-processor handle the I/O and keep track of the counts, then the Propeller can periodically ask for the count in a motion control loop. My testing has shown the model actually seems to work well, I just have little faith that a mouse controller chip will handle high resolution encoders.
Why do this at all?
I want to make a PnP machine or PCB mill with the Propeller as the controller. I've wanted to make an embedded motion controller for 7 years, this is a start.
Steppers are so easy, with step/dir inputs, Why?
Steppers are expensive and step/direction does have limitations at higher speeds. With encoders you have positional feedback and it opens up the possibilities of using a servo loop instead of open loop steppers. You could do closed loop stepper control too. I'm toying with hobby RC servos right now, there isn't any reason you couldn't scale up the control protocol for a hobby RC to something more capable.
My minor victory was actually getting to use these after 11 years!
I got one of the QT4 demo boards, but the little flash bootloader didn't work right. I also have an ICSGP20 programmer/ICS tool for the 40 pin and 44 pin variants, so I made an adaptor board to program the QT and QY chips.
The entire reason I purchased the QT4 and QY4 chips is to do simple and mundane things, basically an ASIC chip for certain tasks.
My renewed interest has been to write some software that can interface with quadrature encoders and interface with the Propeller as a co-processor. The QY4 chip has 14 I/O, which would be good enough for 6 encoder channels, pluse CLK/DATA for communication with the Propeller.
I've been playing with an old ball mouse for positional feedback to the Propeller, but I want to interface with high resolution optical encoders, like used in inkjet printers, and have control over the software that does the interfacing.
A while ago I posted a simple approach to interfacing with a quadrature encoder, that turns the process into a state machine using the last bit input and the current bit input as array indices to a 0, +1, and -1 value.
In essence you do something like: count += gray_code[old_value][new_value]
It's as simple as that.
I will probably put the code into an ISR and make all of the input pins fire one ISR, and just process all input every time.
It wasn't straightforward to get the development tools working on 64bit windows either, but I got Codewarrior 6.3 running on Vista x64 inside VMWare 8, talking to a USB serial adapter, all running on Linux.
Once I'm done writing the firmware (it will be C, possibly with inline ASM), I'll release the source code and binaries. I may even offer pre-programmed chips for sale.
The interface with the Propeller will either be by emulating a mouse, or via SPI. I could use the mouse driver as a structure and modify it to support additional channels.
Q&A
Why do this when the propeller has 8 cogs?
Well the answer goes back to the original purpose I bought these chips, to make custom ASICs, in this case it's a multi-channel quadrature encoder co-processor. Let the co-processor handle the I/O and keep track of the counts, then the Propeller can periodically ask for the count in a motion control loop. My testing has shown the model actually seems to work well, I just have little faith that a mouse controller chip will handle high resolution encoders.
Why do this at all?
I want to make a PnP machine or PCB mill with the Propeller as the controller. I've wanted to make an embedded motion controller for 7 years, this is a start.
Steppers are so easy, with step/dir inputs, Why?
Steppers are expensive and step/direction does have limitations at higher speeds. With encoders you have positional feedback and it opens up the possibilities of using a servo loop instead of open loop steppers. You could do closed loop stepper control too. I'm toying with hobby RC servos right now, there isn't any reason you couldn't scale up the control protocol for a hobby RC to something more capable.
Comments
Mouser has them at some what more, than newer small processors like
FCM8531QY 1: $1.72 (2,658 In Stock) 12KF 1KR Dual Core Motor Control uC ADC/DAC/PWM TQFP32
or
Z51F0410 100+ $1.02 4KF 256R, small uC 1.8-5,5V
or
ATTiny1634 100+ $1.02 16KF 512R 1.8-5.5V