jmkasunich: next you'll be wanting C++ exception handling in HAL
oh, the error handling stuff?
I'm just looking at pages and pages of the same 5-6 lines repeated, and wondering if there isn't a better way
even if its "if (functioncall() != SUCCESS ) goto errorhandler;"
btw, how familiar are you with the mega8 thingies?
[02:08:19] <jepler> http://www.nicemice.net/cexcept/
I'm not particularly familiar with mega8. I have been playing with AVRs for a year or two, though.
re the exceptions, I'm not so concerned about errors deep in a call tree
just the size of the code
especially with your new API, one line does the work
you mean how many lines of code there are
not the size of the object file
and 4-5 check for/report errors
although there is probably a relation between the two ;-)
a real review of errorhandling would be something for later
there's always the data-driven approach
you know, the existing error print code won't work with the new api anyway
because it prints the pin name, which isn't availabe outside the new functions
the case I looked at, in hal_parport, didn't use the name in the error message
take a look at blocks.c, its more typical I think
maybe the new API is no good
I wouldn't go that far
maybe it's not completely baked
what if we had something like errno, only its errstr
and the new api fills it in with a reasonable error message when something fails
then the return can just goto something that prints the string (or not) and cleans up
anyway, I tend to agree with the not completely baked thought
its part way to a cleaner interface
before we change all the components, I'd like to see if we can get farther toward a clean interface
I dunno if data driven is too far or not
even data driven needs to handle errors
"I couldn't register all my pins/parameters" seems like something that will always make a module want to exit.
so there's no need for individualized error reporting -> put it in hal_new_pin
I dunno if it is usefull to print the name of the one that failed
oh, you mean put the print inside hal_new_pin....
in one error case (which I'm not sure I checked for) you would: if the name was too big to fit
also if the name was a duplicate, as opposed to an "out of memory" condition
right, and you'd really like to report _why_ it failed
which the pin_new function is certainly more likely to know
error reporting in rtapi/hal probably needs looked at
what wouldn't benefit from being looked at?
in some cases, a module calls hal which calls rtapi, and if the rtapi call fails, rtapi prints a message, then hal prints a message, and then the calling module prints a message
I suppose that could be good or bad depending on your point of view
duh... hal_pin_new already complains if there is a problem
the individual components don't really need to print at all
or at worst, they should all goto a single point that prints a generic "<blockname>: init failed" message and exits
you did check for name too long (or any other vsnprintf error), but you don't print anything if it happens
the reason I was asking about the mega8 (change of subject alert)....
I'm looking at this board and limitations of the parport
(we need 7 inputs, which means we have to run the parport in input mode, and there are only 4 outputs available)
that means no spindle control, for example
and I think "we got this uC, can't it count the pulses, and generate the PWM, and...."
for a lathe you want 3 channels of encoder (X,Z, spindle) and 3 channels of PWM (X, Z, spindle)
plus a few inputs for limit and home switches
* jmkasunich is talking to himself again
I think cradek was just figuring on using another parport
but now that he has a uC on it.....
at what point do you go to a pico type board?
pico is overkill
$200 _without_ the power amps
thanks by the way for the explaination. very rusty
more reading for me.
I mean using the uc for more than just encoder divide by - maybe actual comunication between emc and the encoders/servos/
but I would assume that would be too much for the one cradek is using.
yeah, I was thinking of something like read 4 bytes: encoder X count, encoder Z count, encoder S count, home/limit/index
and write three bytes, X PWM, Z PWM, S PWM
if you do that every mS, you can handle count rates to 128KHz
(if the AVR code is fast enough)
so I want to think about the AVR code that would be needed
not much (realy none) experience with embedded up
heh, I don't want to admit how long its been for me
Z80 and 8051 era
I have one of those kits from best buy :) when I am bored at work I play with it.
I had some z80 in college
jmkasunich: sorry, I got distracted
I found a doc with the avr instructions set, now I'm distracted too
which kit from best buy?
does that sound righ
oh -- the basic stamp people?
I didn't know best buy sold anything like that
wonder how fast of a polling loop I can write that would count 3 encoders and generate 3 PWMs
I was dissconnected when I corrected my self
* SkunkWorks phones are on the same freqency as the wireless.
so emc would send a number in relation to what the uP wanted for pwm output?
not emc itself, this widget would have its own HAL driver
just like the ppmc does
right - thats what I ment. instead of outputting pwm from freqgen - there would be a hal driver that would output a number in relation to the duty cycle.
does anyone have a number for swp? could check up on him?
I just remembered that I have his cell number
I hate leaving messages, so I didn't
you want the number?
I sure he will show up - Just seems odd he hasn't been on for so long. even during vacation I would check in to see what is going on. but that is just me. :)
jmkasunich: don't know if you got my reply - but thanks.
(about the pm)
jmkasunich: you're going to make the "simplest servo drive ever" not so simple?
I don't know what I'm doing
simplest ever would have encoder PPR that matches the software count rate
once you add the uC to divide things down, all kinds of other ideas appear
the avrs can generate pwm by themselves
jepler already did the simplest ever anyway
even the cheap one?
looking at mega8 data sheet now
I think so, not sure if there are two channels though
I want 3
either X,Y,Z for mill, or X,Z,spindle for lathe
ditto for encoders
why not 4 then - 3 axis and one spindle - that would almost cover everything.
actually I overlooked something
the mega16/mega32 has a full 4 bytes of IO and is still available as dip
lathe needs 2 PWM and the L298 for axis, and one PWM with an RC filter for spindle
mill needs three channels of L298...
just need another one, no problem they're cheap
yeah, but 4PWM plus 4 encoders starts to get iffy in terms of speed
seems it's easy to run out of cycles even at 16MHz
yestarday (with little real knowledge, I may be over-optimistic) I thought we were at 9 or 10 cycles per encoder
that was to divide, not to count, have to see how they compare
I think it's also possible to run that chip at 20 or even 24 MHz
night - maybe tomorrow I will be playing with the drive. Might like to look at your hal file cradek. at some point. or jeplers for that matter. (servo etch-o-sketch)
I was using jepler's modified only for pinout
trying to understand addressing modes now
to get an idea how the connections work with the freqgen
I see it in the hal pdf but seeing it in a working machine helps :)
right, me too
there's a confusing scale parameter that you have to figure out, but that's the only hard part
ok - night. Thanks
thats right, I keep talking about making a non-confusing pseudo-PWM module, and never actually do it
that would be cool
maybe I should be doing that instead of reading AVR datasheets
so far I've been able to write even timing-critical stuff mostly in C
I wouldn't worry too much about the instruction set
when I was generating ntsc I inlined just a bit of asm
I count cycles
the entire program I have in mind is a single loop
base period = 20uS, servo-period = 1mS, so 50 bits per servo period
could send 50 bits to/from each of 8 AVRs at once, that would be kinda cool
why not use the entire bidir byte and a strobe to send a byte each time? there's plenty of IO on the uc
thats actually what I had in mind
I'm just paging thru the data sheet and I saw the SPI
ah I see
there isn't plenty of IO if you start talking about 4 channels
8 bits of PWM, 8 bits of encoder, plus at least 1 index
mega16 (dip-40) is still not expensive
with a full 4 bytes of IO
8 data plus a couple handshake to talk to the PC
thats 3+ ports already
the real issue comes down to speed
how short can an encoder counter routing and a pwm routine be
and how painfull is it to interleave the PC comms stuff
sample encoder A, check PC, sample encoder B, check PC, sample encoder C, check PC, do PWM A, check PC, etc
total loop time sets the PWM freq and the max encoder count rate
might use interrupts for the PC side instead, but the ISR still needs to be short, because it delays the main loop
was just thinking about that
it might only read the byte and put it somewhere
if all the key stuff can live in registers then the counting and PWM code can be fast
encoder count would be 8 bits only, the PC would handle overflow/underflow
you need a state variable and the count, per encoder
thats 8 registers
(for 4 chans)
the lpm? instruction is a little slow (lookup in a constant array)
thats something I was trying to look up, but I didn't know what I was looking for
I have an instruction set listing, but its missing some notes
what is Rd and Z
Rd is a register in the bank of 32, right?
Z is a constant? that won't help
Z is a special register maybe?
yeah, thats it
X, Y, and Z are used for indirect loads and stores
only Z can be used for code space
that means I compute my lookup "key" and then I have to move it to Z before I can do the lookup
LUTs don't need to be in program memory, they could be copied to ram on boot
there's not much ram
but still looks like you need to use X,Y, or Z
LUT for encoder will probalby be 16 bytes
64 worst case
here's gcc's generated code for the equivalent of a=b[c]
632: 80 91 64 00 lds r24, 0x0064
636: e8 2f mov r30, r24
638: ff 27 eor r31, r31
63a: ea 5e subi r30, 0xEA ; 234
63c: ff 4f sbci r31, 0xFF ; 255
63e: c8 95 lpm
640: 80 2d mov r24, r0
642: 80 93 69 00 sts 0x0069, r24
I want 2-3 clocks,
duh, X,Y, and Z are simply 6 of the 32 bit general purpose regs
so if Z hi always points at the table, Zlow can be manipulated at will
Z must be r30,r31 looking at the above listing
and lpm puts the result in r0
and then it gets stored in ram
lpm is 3 clocks
ld reg, (X) is only 2
so store the table in ram
how much ram does the mega8 have?
512 I think
ok, that's a ton
no it has 1k
looks like 10 instructions to read the A and B pins, and inc/dec/do-nothing an 8 bit count
the avr I usually use has only 128
4 are to read the IO bits, 4 to inc/dec/nothing the count
theres gotta be a faster way
! units 11/16MHz microsec
isn't that fast enough?
times 4 channels plus PWM generation and PC comms....
aiming for 100KHz+ count rates here
PWM is probably faster then encoder
the pc does a good job of pwm already
but the PC parport pins are busy doing comms
I wonder if the flags register is one of the general purpose ones
so you can do "skip if bit clear" where "bit" is a flag
duh, you can use branch for that
I thought branch would cost more than skip, but it doesn't
so a one-byte count would be enough?
sure, +/- 128 counts in 1mS
ok I see how that would work
the hal driver would handle extending it to 32 bits
you reset at every read so you're constantly sending deltas?
could do that, or the hal driver could subtract
the latter is probably easier to make foolproof
ok, I get it
actually not sure there'd be much difference
sorry I'm slow, I hadn't thought about this before
PWM is actually very easy, but the direction bit is messy
want to PWM one of two output bits based on the state of a register bit
damn, PWM looks like 10 clocks too
although there seems like more chance of a better way
how many levels of pwm are needed?
that basically determines the max PWM freq, but nothing else
I'm assuming a 8 bit value that is getting incremented, and each channel of PWM compares to it
if higher, output on, if lower output off
for lower resolution and higher PWM freq, increment by more than 1
there is a single incrementing value that serves all channels, so that overhead is shared
ha, got it down to 7 per channel
plus about 5 overhead
784=28+5=33 or so for the PWM
44 for the encoders (not counting index)
the PC interface would also be a state machine
with luck it could be kept to 10-12 clocks
and it really only needs to run once per main loop
so figure 33+44+12 = 89
at 16MHz that is ~5.5uS
not quite 200KHz sample rate for the encoders
only 800Hz PWM if 256 levels
true PWM ain't gonna fly if the base period is 5.5uS
pseudo-PWM like freqgen would be better, but messy to code I think
wonder how many levels are really needed
256 is almost certainly overkill
64 would work I suspect
16 is getting kinda course
how much program memory is there again?
duh, there are 3 hardware PWM channels.....
talking to myself again
after midnight again
my "rain detector" (flaky net connection) is working again
hey steve - you ok?
mostly. just got rear-ended. my trusty van isn't doing so well
its been a week or two - people where getting worried.
sorry about that.
I was trying to get my LabView peoject done
the only way was to mot run chatzilla ;)
SWPadnos: we can understand that :D
also wanted to say - It was nice meeting you at the workshop - didn't get to shake your hand before we left.
crap, sucks about the van
now the project is done, because I can't drive the computer over to the customer site for updates ;)
cradek, yes, it does :(
I hope this is where "I have lots of insurance" comes into play for you
SkunkWorks, yep - good to meet you too. That's 50%+ of the reason I go to these things
lots 'o insurance, but a 10 year old van
right - I was just about to look up book value
insurance on an old car in good shape is the worst deal ever
I feel for you
I got rid of my favorite car ever because of that
SWPadnos: welcome back
(instead of fixing it up at great expense)
it sucks that there's such a financial penalty to using things a long time
and taking care of them
w00t! $4350 value
cradek: I just restarted the compile farm after a power outage... is there anything that needs to be restarted on cvs2?
* jmkasunich goes to the grocery, back later
jmkasunich: I don't think so, it should be fine