| View previous topic :: View next topic |
| Author |
Message |
kbb
Joined: 01 Jun 2007
Posts: 180
|
 Posted: Tue Feb 23, 2010 10:30 pm Post subject: |
 |
|
| jharvey wrote: | | Hmmm, perhaps the brain board could be the normal OpenServo board, capable of driving standard sized servo's. It would need to include some vias or similar attachment options for a separate power upgrade board. |
This is the most satisfactory solution: for any new design it reduces the manufacturing strain, the carrier board will be easy to construct “at home” - with a bit of fiddling, the existing OS board could be used that way now. Note that, if the user wants “temperature” and “current” sensing with a such a setup, they will also need to be provided by the carrier board.
| jharvey wrote: | | I know the layout is currently tight, but we are also talking about simplifying it. So perhaps that will decrease the cost of real estate, and make room for some vias that could be used to attach add-on modules. |
This option has been discussed above; I too think it is a good solution if space permits. |
|
| Back to top |
|
 |
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Fri Feb 26, 2010 12:48 am Post subject: |
|
|
gotta say i'm not a fan fan of stacking boards for a default config. Mechanical failure between them coupled with extra cost rule it out for me. Use a GPIO pad (which we have decided on) with PWM available. the xmega has a more flexible pwm pin assignment scheme that should help there.
I am also not a fan of the hirose connector.
I think what we need is 2 connectors, not one. We need a very small connector for driving logic level signals, and also a 2 pin heavy duty power connector. These take space away from the board, meaning we can't add too big a FET, but we have some scope to uprate the current.
We should first calculate how big if a current we are likely to want to source to the motor, and decide from there. As kbb pointed out, there is a limit to how much current you can shove throug the tiny board. You can do things to improve your prospects, such as thicker weight copper traces, and really thick traces, but generally you are squeezing a few more ma out of it and not hundreds.
So.... I ask you all these questions.
How much current a top end, off the shelf servo take?
What connectors, if any, are we going to use?
How much smaller does the PCB need to be to fit in *all* standard servos?
If you have some thoughts or answers to these, please add to this discussion. I will do some research to find out as much as possible.
My XMega dev kit arrives soon, so I am going to start looking at a port of v3-dev to the new platform.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 352
Location: Maine USA
|
| Posted: Fri Feb 26, 2010 11:02 am Post subject: |
|
|
About connectors, I've been a fan of CPC connectors. They are probably to large for being PCB mount in this application, but they have some nice features that I'll note here.
They are circular, so routing them through circular holes is easy. After you route the wire, it's easy to back fill any stressed areas with a grommet. They offer both solder cup, or crimp style connectors. This allows for a variety of options that both have pros and cons, and you can choose what you want. They offer weather sealed or not sealed. This allows for upgrades if your application is water bound, or low cost if you application doesn't require it. The also offer twist lock, which is nice because you get a detent that indicates you have full penetration, and its very hard to make it fail. A .01 ohm resistance can be a real bugger to deal with. I once saw an application with a stepper motor, where a non locking connector was used which caused a mild resistance likely in the .01 ohm range that caused a resonance issue with the stepper. This caused the voltage internal to the stepper to increase to the point where it kept burning traces in the motor. But only after the connector came apart slightly, so very hard to diagnose in the lab.
My plan is to run my wires directly to the PCB, then use up stream CPC connectors when interfacing with the rest of the system.
That's a good note, about separating the high power PCB from the normal servo board. It's unlikely you'll start with a small servo, then decide to upgrade. So if you're using a larger motor, why not just get a completely different board that uses the same firmware, but has larger components.
Also about the increased drive capability, if you increase your drive capability, you typically decrease Rds (or equivalent) which decreases the power dissipated by the PCB board. Just because you have great power, doesn't mean you have to use it. Perhaps we should look at cost and or physical size when determining a good chip for the drive silicon. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Fri Feb 26, 2010 10:52 pm Post subject: |
|
|
| ginge wrote: | | gotta say i'm not a fan fan of stacking boards for a default config. Mechanical failure between them coupled with extra cost rule it out for me. |
I suspect one would want to use “posts” (soldered) rather than connectors (wafer) in a multi-board scenario, which I think would make it safe against mechanical failure. I agree that the potential to inflate the manufacturing cost is a good reason to rule it out. Having said that, tho, it is probably the only way to get a “higher current” H-bridge into a standard servo case – esp given the physical size of the ATxmega32/64/A chips (more of which later).
| ginge wrote: | I am also not a fan of the hirose connector.
I think what we need is 2 connectors, not one. We need a very small connector for driving logic level signals, and also a 2 pin heavy duty power connector. These take space away from the board, meaning we can't add too big a FET, but we have some scope to uprate the current. |
The current method used to mount the hirose connector is a “neat” solution to keep, as it reduces the amount of usable space removed from the board.
| ginge wrote: | | You can do things to improve your prospects, such as thicker weight copper traces, and really thick traces, but generally you are squeezing a few more ma out of it and not hundreds. |
Another option is the “busbar” approach (i.e. thick copper wire); to be “installed” by those end users who want to try and push more current than the PCB traces can take.
| ginge wrote: | How much current a top end, off the shelf servo take?
What connectors, if any, are we going to use? |
Looking into it...
| ginge wrote: | | How much smaller does the PCB need to be to fit in *all* standard servos? |
For “standard sized” servos (as apposed to “micro/mini” servos), I suspect it is just a tad off the width and a less thick board. I will measure up the ones I have here and we can also see what info might be found on the net. I imagine, for a good fit, it may be worth having a “standard width” board, but with a scope for 1mm to be sanded off to accommodate some servos?
| ginge wrote: | | My XMega dev kit arrives soon, so I am going to start looking at a port of v3-dev to the new platform. |
Is it the STK600?
I have also been pressing forward...
Talking of which, do we know who is onboard for EDA? I have, for my own purposes, started a schematic in KiCad based around the ATxmega32/64A... and using the existing V3 design of course - I am half way though plonking the components on (had to “build” some of them, including the ATxmega...). But obviously an expert at such things would be more efficient.
Last edited by kbb on Sat Feb 27, 2010 12:03 am; edited 1 time in total |
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 352
Location: Maine USA
|
| Posted: Fri Feb 26, 2010 11:59 pm Post subject: |
|
|
| kbb wrote: | | Another option is the “busbar” approach (i.e. thick copper wire); to be “installed” by those end users who want to try and push more current than the PCB traces can take. |
I have seen creative use of a solder mask for this type of thing before. Where the trace was masked off, which allowed for solder to be built up on the trace making it thicker, and more capable of transferring current.
| Quote: | | Talking of which, do we know who is onboard for EDA? |
I could find some time to work on a PCB layout with KICAD. I can also offer some help in working with KICAD. The ability to edit the source file by hand in a text editor can be really power full. I'm willing to share some of the odds and ends I've learned along the way. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sat Feb 27, 2010 11:30 am Post subject: |
|
|
| ginge wrote: | | How much smaller does the PCB need to be to fit in *all* standard servos? |
Size of V3 PCB used for comparison (mine are from Jay):
Overall width: 18mm
Overall length: 23mm (just the PCB, not including the Hirose connector)
Inner length (to inside of motor “bay”): 19.5mm
Thickness: 1.8mm Which matches what we see here:
http://www.openservo.com/forums/viewtopic.php?p=2065#2065
Comparing the fit/potential fit of this V3 PCB to the following servos
Hitec HS-645MG
TowerPro MG996R
TowerPro MG995
SuperTec S03T/2BBMG
Futaba S3001 seems to show that the “nuisances” are likely to be the same for all “standard” servos:
Width: the width seems to fit on the “shelf” fine in all cases. However, there is an issue because the SMD components at the edges of the PCB bind against the inside of the case below the “shelf”. This is exasperated by the thickness of the PCB (see below). When I was mounting the V3 boards, I had to pare-back the insides of the cases to accommodate the board.
Thickness: it is too thick. This results in the insides of the servo case having to be pared back even further to accommodate the board and the SMD components on the edge. The original boards that I have removed from various servos are all between ~1.2 and ~1.3mm thick.
Recommendations?: Keep the board width as it is, but ensure all components are moved away from the edge of the board 1mm further than they are on the V3 board. If possible reduce the thickness of the board (or main board!) to 1.2mm. If possible make it so that end-users can sand off up to 1mm from the width of the board without risk of damage (to traces and so on).
Width of the “neck” at the Hirose connector: it tends to bind with the hole-structures that accept the screws that hold the servo together, requiring them to be pared back. However, the board does not interact with the screws themselves. When mounting the V3 boards I had to pare these back to accommodate the board.
Length: Could probably do with being reduced by 1mm to 1.5mm, to help with the binding against the screw hole-structures, as it pushes the board into those. Reducing the length will make it less of a tight against the motor and connector end of the case. Alternatively, once there is a design, reduce the length to “as short as possible”, see below for the rationale.
The shelf: doesn’t extend all the way back to the motor in most of the servos, therefore extending it when installing OpenServo PCBs will be required for most servos: but I see that as a satisfactory state of affairs given how much needs to be packed inside.
| ginge wrote: | | *all* standard servos |
We can see the case sizes of lots of servos at
Note: Alan's comment here http://www.lynxmotion.net/viewtopic.php?f=31&t=5632!
Here we can see there is a lot of variation in size for “standard” servos. We could assume that the wall thickness of most standard servos is the “same” for all practical purposes. Width seems to be the most consistent dimension for “standard” servos, implying that if the width is assumed to be okay, then reducing the length of any new PCB is the most accommodating thing that can be done. I am willing to suggest that the size of a “Hitec HS-645MG” is usable as the size of a “standard servo”.
If we can make V4 a reality soon, I am dumping the MG995s/ MG996Rs for HS-645MGs (or similar). |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Sat Feb 27, 2010 5:20 pm Post subject: |
|
|
| kbb wrote: | | Is it the STK600? |
Yes, also the XMEGA adapter boards. I also ordered a few XMEGA32D4 chips along with the A4. THese have a few less features, such as the DMA, some timers, speed on ADC, but seem to be usable for our purposes. Obviously it is cheaper too. Results will follow.
| kbb wrote: | | Keep the board width as it is, |
Ok, I see what you are saying. seems fine to me. We could have a pcb mask to mark to the limit of the trimming available.
Re having to trim the mounting pillars. This is an annoyance, and another reason why I don't like the Hirose.
All of your other points are well received. The thickness of the v3 comes from the fact it is 4 layer and the thicker the cheaper. I have a feeling the the v4 is going to need a 4 layer board, if only because the TQFP44 is quite large. I was going to look at this later. Kbb, would you mind sending me the schematics and the xmega lib files once you hsve them done. I have some ideas for the PCB that I would like to independently investigate. 
I wouldn't mind some sory of mounting lug integrated into the pcb. I am working on a servo from scratch idea at the moment, and it would be nice to accommodate the openservo into it.
| jharvey wrote: | | I have seen creative use of a solder mask for this type of thing before. Where the trace was masked off, which allowed for solder to be built up on the trace making it thicker, and more capable of transferring current. |
I like the idea of this. We can expose the thicker traces to allow solder fills. We should (if possible) try and get this into the design somehow.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sat Feb 27, 2010 5:40 pm Post subject: |
|
|
| ginge wrote: | | How much current a top end, off the shelf servo take? |
Few of the servo datasheets/info I have found specify what the stall currents are. However, some of the Hitec servo datasheets do, and so far I have seen stall currents as high as 4.2A at 6V for some “standard sized high-torque” servos (for example: HS-7955TG). I haven’t looked at all of them of course.
I can make the HS-645MG go to 2.2A by trying to force it out of position, it’s datasheet does not give a stall current, just a much lower “running current” of 450ma (no load maybe). Most of the other servo’s I have here are “similar” in what they draw. An MG996R can draw 2.5A. The tests showed the answer seems to be similar for both the original servo and the OSv3 version. I know that an MG995 will take ~3A (and trash the gears/case doing it). The Futaba S3001 (low power servo) never reaches 1A.
But what current to support?
Here are some observations, thoughts and notes. Then a conclusion.
Examining my OpenServo V3 boards I see that they have Fairchild FDS9934C NP MOSFETs, which have a maximum drain current of 6.5/-5A. The V3 schematic asks for IRF7307, which has a maximum drain current of 5.2/-4.3A. I haven’t found any info on the forum in regards to the difference between schematic and the boards I have. What do the RobotFuzz boards use? So far, then, the answer is at least “5A” (existing implementations in the field).
Ideally retain the same SO-8 package or something with a similarly sized footprint.
End users who need to go beyond what the PCB traces can take, will need to install some sort of “busbar” solution. The MOSFETs may be rated higher than the PCB - not an ideal design if the difference is large enough to encourage people to use the extra headroom, as it is not “failsafe”, but we have very limited room. Although we can specify that OpenServo supports a defined current (“busbars” to be installed where needed).
End-users wanting even higher currents than whatever is decided must be (famous last words?) using physically bigger servos and should therefore go the “use the OpenServo board as a brain route” described elsewhere.
Looking at the MOSFET devices currently available from Farnell (there are a large number), if we stick with the NP design for the H-bridge, you can easily find devices up to -7A (limit imposed by the P channel). If the H-bridge was redesigned to use only N channel FETs then even larger currents can be easily supported. For example: the IRF9910 (SOT-8 ) goes to 10A (note: max for Q1 @VGS of 10V), there are many devices at around 8A in SOT-8. There are others in similar A ranges.
Amps drop off as temperature increases.
Obviously it isn’t quite that simple, the specification of each potential MOSFET needs to be examined in detail. There is also the price, but this doesn’t look like too big an issue.
If the higher power available is used, then something needs to be done to dissipate the heat: clearly it won’t be possible to have a copper area on the OpenServo PCB to meet this need, so it is down to the end user again. See:
http://www.openservo.com/forums/viewtopic.php?p=3020#3020
http://www.openservo.com/forums/viewtopic.php?p=3520#3520
So, my conclusion?
So at the moment I am tempted to suggest 8A (at the MOSFETs), because it is possible: it is large, almost extravagant, but not too extravagant, and also hopefully not extra costly. It leaves plenty of headroom. It is comfortable compared to what some standard sized servos need. Anything beyond that seems to be getting really silly given the size of the PCB and where it is intended to go. And the unit costs would start to escalate, just to support uncommon use.
All the previously mentioned caveats about actually using the extra capacity apply. I am tempted to think about the use of the IRF9910 (10A) in a redesigned H-bridge - it leaves a really good error margin (for example: as opposed to using something rated at 8.2A to support 8A).
Questions:
What is the current safe current limit for the PCB traces?
What can we support in the new one (current thru PCB traces)?
Should provision be made to ease “bolstering” the power supply from the input socket to the MOSFETs such as providing a route for the user to add copper wire (a bit fiddly to achieve at the moment)? |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Sat Feb 27, 2010 5:40 pm Post subject: |
|
|
You know, the more I look at alternative connectors, the more I wonder if there IS an alternative that would work out.
What are everyone else's thoughts on the connector?
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Sat Feb 27, 2010 6:00 pm Post subject: |
|
|
| Quote: | | What is the current safe current limit for the PCB traces? |
I burned one out at 4.2A so it is between 3.5 and 4.2A as an upper limit.
| Quote: | | What can we support in the new one (current thru PCB traces)? |
If we use 8A as a target value, the (external) traces are going to be about 2.8mm wide. (1)
if you coat the traces to be 4oz/ft^2 you are looking at half that value
Either way, 8A is large Realistically we could cope with 6A with soldered traces we only need just over 2mm width. without the extra solder you could get just under 4.0A at 2mm
If you think you could squeeze 2.5mm traces in, for the whole bridge, then lets try it.
Also I don't think we could find a connector large enough to support 8A comfortably. see below:
| Quote: | Should provision be made to ease “bolstering” the power supply from the input socket to the MOSFETs such as providing a route for the user to add copper wire (a bit fiddly to achieve at the moment)?
|
we can try this, but I don't think it would be worth it.
(1) http://www.desmith.net/NMdS/Electronics/TW1.html
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sat Feb 27, 2010 6:05 pm Post subject: |
|
|
| ginge wrote: | | if only because the TQFP44 is quite large. |
The ATxmega64A4 (etc) appear to be available in three packages.
The TQFP44 is the largest (12mm by 12mm, including leads), and I suspect the most accessible to anyone who wanted to solder it up at home. But as you say, the large size uses up lots of PCB space. Depending on how the pins need to be used, rotating it by 45 degrees may help - if this doesn’t cause it to overlap the sides.
The others are the leadless VQFN44 at 7mm by 7mm and the VFBGA at 5mm by 5mm, however these may be less accessible for home builds? Also, I didn’t see any suppliers offering them.
I may well prototype with the TQFP44 at home (i.e. on a “SchmartBOARD” - I have one here and an ATxmega64A4 is in the post, let us see how steady my hands are), but hope that pre-built boards will be available for in-application use! |
|
| Back to top |
|
|
jharvey
co-admin
Joined: 15 Mar 2009
Posts: 352
Location: Maine USA
|
| Posted: Sun Feb 28, 2010 12:43 am Post subject: |
|
|
Another feature I think would be handy is a larger input voltage range. I seem to recall that lead acid battery when discharged below 10.2v will significantly decrease their usable life. Using that ratio for a 7.2 volt pack, would be 5.76. Currently we can't really drain a battery pack below 6V or a bit more. So perhaps a 3.3V CPU would help prevent brown out issues. Just a thought.
About the current draw, I know I was pushing for high current to decrease Rds and dissipated power in the servo case. Lets also not forget that higher current also tends to slow down the transitions, this can also cause an increase in dissipated power. So perhaps we should spec it as 6 amp min, with lowest power dissipated either by naturally low Rds, or fast transition times. |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Feb 28, 2010 10:54 pm Post subject: |
|
|
| ginge wrote: |
| kbb wrote: |
“Option pads”
If possible some unused pins or other functionality should be brought out to spare pads on the PCB, thus allowing experimenters to easily connect other things...
|
Ok, I see what you are thinking here. I think it would be reasonable to break out 8 pins in total, HSUART (2), SPI/I2C (3), ADC (2), GND (1)
It would be a tight squeeze, but not unreasonable given potential space savings. We could have them as thin edge wafer connectors to save space.
|
I was thinking literally in terms of “pads” (or plated thru holes maybe) to which the experimenter can connect their stuff by soldering on link wires.
I assume you mean connectors mounted in an upright position (rather than flat), so that the experimenter can close up the servo with the board installed? The connector would have to be back from the edge slightly, so that it does not bind with the servo case. The possible advantage of pads is that it doesn’t matter where they are, and there is no worry about finding an “inexpensive” connector that is small enough? |
|
| Back to top |
|
|
kbb
Joined: 01 Jun 2007
Posts: 180
|
| Posted: Sun Feb 28, 2010 11:56 pm Post subject: |
|
|
| ginge wrote: | Ok, I see what you are thinking here. I think it would be reasonable to break out 8 pins in total, HSUART (2), SPI/I2C (3), ADC (2), GND (1)
|
HSUART: 3 if we include the clock
SPI: needs 4 (!SS, SCK, MOSI and MISO)
There is also a request that both SPI busses appear on the host connector.
For experimenter access and/or the host connector we could actually share some pins if we want. For example: only 4 pins are needed if you want both the HSUART and SPI, but not both at the same time. This is safer if the HSUART and SPI buses from port D are used, for example. If we mix things up even further we could get an HSUART, SPI and I2C on just 4 pins: as long as only one is used at a time, however, this may be “less safe” (see note below). In some cases there may be no choice but to share (from using functionality that is already shared on the MCU pins).
For the host connector (in the schematic I am working on) I am currently assuming that it is best to keep the number of pins down, so the options there are currently using the “safer” approach to sharing giving the following “channels” for chatter with the host:
1: Is either I2C, SPI(1) or USART(1)
2: Is either SPI(2) or USART(2)
3: Is PDI (the programming and debugging port) - maybe this should be moved to a 2-pin mini-header on the PCB?
Sidebar: I am thinking about this - I cannot see anything that suggests that the ATxmegaNNA4 does SPI daisy chaining, so 8 pins (plus ground) are needed at the host connector to have both ports exposed to allow one OpenServo to daisy chain to another (it would have to be done as Barry suggested: in software, with the code forwarding on requests that do not belong to it, and, it should be noted, returning data that has been requested). However, maybe with some complex coding and behaviour it would be possible to reduce the number of pins and/or make proper daisy chaining possible. If I get time I will write about what I am thinking, unless someone redirects me to a solution. Or one could try to “bit bang it” 8-(.
There are only two SPI ports on the ATxmegaNNA4, so onboard SPI will need to be shared with SPI(2) on the host connector. Which is less “safe”. On board there could be “option pads” for separate USART and SPI.
Currently “on board access for experimenters” is heading towards:
2 ADC channels (2 pads)
USART (3 pads)
I2C (2 pads)
SPI (which is also a USART, 4 pads)
1 DAC?
Of course, the pins can be used for various other purposes. This is also true of the host connectors (although there is no analogue input).
The “safety” issues are (to be looked into more thoroughly):
1: In some pin sharing configurations, it might be possible to turn two connected pins on as outputs at the same time in the software (or course, this would be considered a coding error).
2: In some configurations, someone might forget they had things cabled in a way that drives a pin that is then turned on as an output.
Any thoughts, suggestions or preferences? |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Mon Mar 01, 2010 5:43 pm Post subject: |
|
|
| kbb wrote: |
There is also a request that both SPI busses appear on the host connector.
|
This I am not sure about. You can daisy chain many SPI devices on a bus, but each much have an ENable signal sent to it. This sort of defeats the purpose of the bus nature if you need to run a wire to each servo.
Otherwise, pins permitting, I don't see why not.
| kbb wrote: | For experimenter access and/or the host connector we could actually share some pins if we want. For example: only 4 pins are needed if you want both the HSUART and SPI, but not both at the same time. This is safer if the HSUART and SPI buses from port D are used, for example. If we mix things up even further we could get an HSUART, SPI and I2C on just 4 pins: as long as only one is used at a time, however, this may be “less safe” (see note below). In some cases there may be no choice but to share (from using functionality that is already shared on the MCU pins).
|
There is a sweet spot here for pins and features. In terms of the host header, I would like to see nearly all protocols able to be supported. I2C, dual SPI, dual UART and possibly PDI. I am not against doing solder bridge jumpers or such to enable/disable certain combinations.
Even if we keep the Hirose it would be tight to accommodate 2x of any of the above protocol.
Some of this is going to come down to how much pcb space we have to route certain features to the header. You can't access all features from port, so the more we route, the harder it gets. I am eagerly awaiting your PCB so Ican get a feel for it.
| Quote: |
3: Is PDI (the programming and debugging port) - maybe this should be moved to a 2-pin mini-header on the PCB?
|
I could live with that. If you need PDI, then you are doing "advanced stuff" and should be okay with soldering some wires.
| kbb wrote: | | Sidebar: I am thinking about this - I cannot see anything that suggests that the ATxmegaNNA4 does SPI daisy chaining |
Yes, it would have to be chained this way. (or see above). The XMega A range can make this happen mostly in silicon. A brief scan of the datasheet says we can hook SPI modules directly though DMA. It would require 1 interrupt per packet to check the destination, but otherwise you DMA from SPI1 to SPI2.
The same goes for nearly all of the new dual peripherals, so in theory we could implement daisy chained HSUART in a similar fashion. This is appealing to me.
| kbb wrote: | | , so 8 pins (plus ground) are needed at the host connector to have both ports exposed to allow one OpenServo... |
We currently have 6 free on the Hirose. If we moved power to a separate connector, then we have 10 to play with.
| kbb wrote: | | However, maybe with some complex coding and behaviour it would be possible to reduce the number of pins and/or make proper daisy chaining possible. |
Personally I wouldn't waste any effort on this endevour.
| Quote: | Currently “on board access for experimenters” is heading towards:
snip...
1 DAC?
|
I can't see any use for the DAC. Anyone else?
| Quote: | 1: In some pin sharing configurations, it might be possible to turn two connected pins on as outputs at the same time in the software (or course, this would be considered a coding error).
|
Slap on the wrist for someone if that happens. (It will probably be my fault  )
| Quote: | 2: In some configurations, someone might forget they had things cabled in a way that drives a pin that is then turned on as an output.
|
Hmm... not much we can do about that one. If we want to be more flexible with protocols and expansion, then we are inevitably going to be adding slightly more complex configuration if changed from the "default". If you are changing from the default then you have a good idea of what you are doing.
| Quote: | | Any thoughts, suggestions or preferences? |
This is really tricky. I would like to say that we should keep the hirose and try and work around the 6 remaining pins. Problem is I can't find a good alternative connector with higher pitch but with some current carrying grunt.
In other news I have started the port to the XMEGAD4 if only because I can't get any Ax chip at the moment.
I am writing some unit tests that replicate the OpenServo core functionality to get a feel for the new hardware configuration.
The PWM generation is the trickiest, not only because it has a HiRes 16 bit resolution, but has a built in dead band insertion unit which I am trying to get working... This mens we can remove the tricky delays from the pwm code for shoot-through and crowbarring protection.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
