This is awesome; sorry I started the other thread I have 2 RPI’s I want to make an integrated O2 headphone amp and personal music player for my brothers 50th birthday with one. Was hoping to make a nice milled alloy or brass case for it.
Printable View
This is awesome; sorry I started the other thread I have 2 RPI’s I want to make an integrated O2 headphone amp and personal music player for my brothers 50th birthday with one. Was hoping to make a nice milled alloy or brass case for it.
I've been up to my ears in the ARM Coretex Tech Ref manual for the last few days and I think I have the hang...Quote:
Originally Posted by irving2008
The snag with accel decel is terminal velocity on a movement which very much depends on it's intersection angle with the next movement.
You don't want to be forever slowing to zero.
You don't want to work that sucker out inside the interrupt.
You have to be able to brake and recover when you hit the PAUSE button.
Looking at it I have a notion that I save the movements with a target max velocity and a desired terminal velocity, I can figure out accelerations and decelerations starting from current speed on the fly using a look-up table. If I bung in a Gig or two of Micro SD card memory I should be able to store the entire cut and simply exchange status data with the host computer while cutting. I think the USB connection becomes a weak link when the motors start turning. Also it would be nice simply to unplug the lap top and take it with me if I wanted to cut "lights out".
I am starting with TIM2 set as a down counter with interrupt on update and a big fat delay in the reload register. That way I can figure out what the delay should be, see how far the timer has got and write the counter register directly with what remains.
The interrupt looks at a status byte and decides what to do. That way my base program can simply tinker with the status byte and everything happens automatically.
Two interrupts per step, one of variable length to control the speed, one of set length, just enough to trigger the step after the DIR and STEP lines have had a chance to settle.
I've been thinking of getting me a slice of Pi .... I need to have a better read through this thread though, as it seems other options were suggested ?Anyone going ahead with the Pi or did you decide on arm ?
I think Pi is ARM based. Haven't got one myself, I'm using the STM32F103V development board because it's cheap and comes with a dinky full colour touch screen I want to play with.
I'm wondering if ST is a new funky name for what was Signetics Thompson? Perhaps I've been around too long :very_drunk:
ooh ... now you got me thinking ... Atari ST , or Amiga 1000 :) ... I wonder ...
I had a bit of a leap backwards when I discovered the STM32F103 doesn't take ARM instructions, it's all THUMB-2 and relative, icky pooh, so I'm now writing in C.
I had a bit of a leap forward when I discovered the port bit set reset register GPIOx->BSRR
It's a 32 bit register for a 16 bit port, set a bit in the top half and you set a pin, set a bit in the bottom half and you reset the pin. Fiendishly useful if you are sharing the port with other peripherals you don't want to touch.
The port control registers come in Low and High GPIOx->CRL GPIOx->CRH with 4 bits per port which is conveniently one digit in Hex so you can see what you are getting in the way of inputs and outputs at a glance. For example:-
GPIOB->CRL = 0x22222222; Gets you 8 push pull outputs b0-7 on Port B
Much easier to see what is going on a glance.
I have a rudimentary 4 axis stepper written, now I need to get data in to it. I've bought a 4Gb micro SD card. If I can dump the entire cut into it then I can stop worrying about drip feeding and comms errors, just have it send reports on a timer tick so I can do fancy graphics on the PC. Watch out, SD cards come with a "Class" number which is the transfer rate in MHz, if you don't see a Class number assume it's slow, I got a Class 4.
Running my Pi(s) on 16Gb class 10s now (yes my second Pi arrived), courtesy of SavaStore, cheap and improves performance and memepory issues are a thing of the past. 2.9Gbyte for the OS and 12Gb+ for a step buffer - can't see any job needing more than that! But other things are taking my time now so this is stalled a while.
Took me a while but I now have it stepping :yahoo:
Not usefully stepping, just moving back and forth in 4 axes at 4 different speeds, over and over again. Looking good.
I am running everything on one timer interrupt. The interrupt collects 4 absolute co-ordinates from the buffer, along with a couple of speeds. It moves there. It comes back for more. Simples.
I was thinking to make the Z and W axes optional but there is no point it's so blooming fast. 40kHz step rates look easy, I could probably wind it up to 70kHz mid line. I usually run at 3kHz top whack.
These ARM Coretex processors may have a bit of a vertical learning curve but are well worth the effort. They have so many built in goodies I am barely scratching the surface.
:) The only progress I have made is to put Pi #1 into a nice CNC'd case from Pimoroni
Attachment 7076
That is sexy !Quote:
Originally Posted by irving2008