mbed Compatible

[TopherMan]

In another issue thread you mentioned the possibility of making it mbed-compatible. I think this would be handy, but the pin counts for the mbed boards are kinda low. The LPCXpresso is pinout-compatible with the mbed for the top 20 pins on either side (pins 1-20 and 28-47). If you look at the LPCXPRESSO_GENERIC_HEADER component in the schematic, I drew it with a horizontal line where the mbed ends. It's possible that you could re-arrange things to make it work, but I don't think there's enough pins for all the steppers and mosfets and inputs. If you want to try tying together some more enable lines and eliminating some expansion headers, you might be able to make it work. I may take a whack at it later, but it may be a bit before I have the free time to try it myself.

[Noobman]

Yes i think it could be done, with more or less compromise. If i get it right, there are 12 pins that lpc has extra, that means moving there something like the following: -3 endstops -3 pins from B step en dir -2 mosfets -1 card detect -4 from the lcd header (1aout and 3 others, i think can ones can be used as gpio) -1 perhaps set en for A common to xy-en

So i think it can be done one size fits all at least for pincount, but with minimalistic features on mbed. But to fit them both, we probably loose the lcd header and other stuff like 2 mosfets and B-driver will go unused, and also would mean a lot more vias and stuff. So if it has to fit mbed on same board, it would end up being less optimal for lpc.

As alternative, we could do a different board that would just be mbed only, with some features cut down, and slightly different pin allocation. Dunno which route would be better tbh, but usually when there is something that tries to do two things, it ends up being less good than a similar thingy which only tries to do one thing. At least from my experience. But atm i think need to give it some time and more thought to settle either way. Will try to give it a try these days and see what it ends up like.

[TopherMan]

I agree that it might be better to do a separate board. I'll ponder it as well, and hopefully something clever will occur to me, but for now I'm probably going to order the board as it is, and think of this as a future development.

[Noobman]

From master I created a new branch called mbed_compat. To preserve the lcp format at this stage while we further play with pin allocation for mbed compatibility.

Update: I wanted to use stash command to preserve the master and work in another branch, but thought of kicad way of updating files from each other. Probably safer to not use git trackers for branches. I think it seems simpler to just use another directory inside master, so ill make directory mbed_compat directory instead, and delete the branch.

[TopherMan]

Aaah, I was wondering why you did that. Makes sense.

[TopherMan]

Okay, just made a few tiny changes to the board for fabrication. Unless you have any pressing concerns, I'm going to make the gerbers and send it off for fabrication tonight.

[Noobman]

I made an initial pin allocation and layout for mbed compatibility. Check it out first.

I didnt wanted to loose the expansion header, so i moved all endstops in extra section, with card_detect, and had the mbed use alternate headers for endstops and mosfet 4.

Basically machine can run without endstops, with software limits, but mbed can use the 3 pins for endstops. Mechanical ones just use low detect with its own pin internal pullup. Mechanical switch NC keeps it low, when disconnects line raises up by its own pullup. Added gnd near the expansion for that.

Mbed can use also a jumper in expansion header to set Aout pin to drive fet 4.

Also mbed users will need to have XY enable tied together with extruder A enable. This is not a concern coz usually its like that, when xy are disabled position is lost, and extruder also disabled and further extrusion pointless. Also from start to end print extruder needs to be on, to keep the pressure. So this only limits in the case when the user would make some moves before started printing, then extruder will be enabled also for such moves. Z enable is kept separate so will be mostly disabled except layer changes. Lpc users will have the A-enable and XY-enable separate if they dont use the jumper.

I did it like this to have minimal compromise while still allowing mbed use, but thats more like a secondary, and needs to use 2 jumpers. Also Mbed wont have B stepper and no hardware card detect (will have to use software detect).

Not finished yet, needs checking and polishing and i have to go now till tomorrow, did this kinda in a rush.

[Noobman]

Just realised power4 line is not pwm pin anymore, so i will try fix it, inc soon.

[Noobman]

I changed the non-pwm pin to mosfet 1, which is bed. This is good because the bed must not be pwm-ed, so this is rather welcome change for the bed function. The mosfet 4 is presumably a fan and can better benefit from pwm. Also now there are 2 jumpers to fix, i think its more clear where the jumper is.

Still needs checking and perhaps a little polishing labels for jumpers etc.

With this change i think the mbed_compat version has no disadvantage for a normal Xpresso board user, should be no difference, so i think its better to move this to master, and delete the directory.

[TopherMan]

Couple of thoughts:

First, I found manual homing annoying back when my endstops weren't working right, so at least 3 would be nice for mbed users. I was looking over the schematic again http://www.embeddedartists.com/sites/default/files/docs/schematics/LPCXpressoLPC1769revB.pdf and it looks like 0.27 and 0.28 are also I2C lines, so you could move the I2C expansion and one of the Expansion GPIOs to the Xpresso-only pins (or do something similar with the jumpers), and then the mbed would get 3 endstops.

Second, the VIO pin on the Xpresso appears to be an output only pin on the mbed. I don't know what sort of protection is on that pin, or what would happen if we connected a power source to that pin. Though it does have the VIN pin connected (4.5V to 9V) so maybe some jumpers or a switch to change from 3.3v at VIO to 5 V at VIN.

I'm tempted to tag the non-mbed-compatible one as Rev 0, send it out for fab, and then switch over and delete the directory like you said. That way we can keep tinkering, and I can find out how well the board works as an expressly LPCXpresso solution.

[TopherMan]

Oh, and the PWM probably doesn't matter. I think that smoothie uses its own simple pwm control that doesn't require hardware pwm. It's best to leave them there if we can, but in a pinch it probably doesn't matter.

[Noobman]

About pwm, at least its good that bed cant pwm anymore.

Endstops for mbed = 3 pins from expansion header, one GPIO and one gnd pin. Mechanical endstop does not need any voltage, coz it uses pin internal pullup to raise to vcc as endstop is disconnecting then line when triggered.

[TopherMan]

Yeah, I think that is a fair compromise. The only other thing I can think of doing is getting the endstop pins on the far end with 5V on the far rail instead of 3.3V as it is now, since electrical endstops are more likely to work with 5V and we know the LPC chip is 5V tolerant.

[Noobman]

Oh the optoendstops work identically the same, by grounding the internal pin pullup. Normally there is no way to get 5v into the gpio either. The 5v is only used for the emitter to send the light to activate the grounding of the opto transistor. So 5v is galvanically isolated from gpio. The only way to get 5v into the pin is by user's fault, thats why protection is for. In case user will make a shortcircuit, but otherwise we dont abuse the pin clamping. Yes i am thinking of something like that, and even to have emitter and receptor better separated.

[Noobman]

The 5vout only needs connection to our usb, no need to put it in Vin, its already sort of there, it will just create a loop. Instead, to make the mbed board run independently from usb, can feed 3.3v into its Vbat. Took 5v to endstops but that poor track has 3 vias alone. Completed some kind of layout atm. Vias and jumpers flourished.

Is the width of the modules the same, i mean LPC and mbed modules have exact same width yes? Looks very different in pictures but picture sizes can be deceiving ofc. About endstops i am thinking of putting here the components that usually are on opto boards. So if optoendstops are used, they wont need a board, just 4 wires directly to opto-part thats all. And maybe with separate supply. But i dont think there is room now.

[TopherMan]

Hmm, the 3.3V to Vbat is probably not necessary. I think that the battery is for an internal real time clock only, it doesn't power the whole board.

The two boards have pins at exact same distances apart, 0.9". They look different sizes because the mbed board ends right at the pins, and the Xpresso has a little bit of an overhang.

Opto electronics would be nice, but I can't imagine where they'd go. The board is getting a bit crammed.

[Noobman]

I have changed the structure and moved the mbed_compat to root / master. Old root version is archieved in _old_archieve. Made directories for _current_release and _old_archieve so that if there will be some versions manufactured, then have to be saved for reference. Set up optoendstops directory, havent done anything there yet, but just to save the directory structure like that and i will do optoendstop boards asap.

[Noobman]

Latest changes added 2 pullups for 3 of the endstops, this allows direct connection of opto parts. Values are for TCST1103 or 2103 and 3.3v. I'll fix up some endstop board in the endstop directory, nothing done there yet. However if those 3 headers are used, separate opto-boards wont be needed. A good doubt i have about this latest change is that if the resistors are on the board, the current passing through wires is small, no decoupling on lines, and then might pick up all sorts of noise - cables must be shielded. This should be tested. If something is wrong, will use separate opto boards.

Beware, with latest endstops change the Ymax and Ymin have been switched to each other - pls update configs. Headers and labes in endstops area become a bit more intricate.

I think im done with the board for now, so i'll close this issue about mbed. Please review everything and polish a bit, and if you think its all ok then this version can qualify for release.

[TopherMan]

Sure thing. I'm going to make a a small tweak with power--Vbat is an external connector for a battery to keep a real-time clock ticking when the board is unpowered. Since we aren't using the real-time clock, and it would be unpowered when disconnected anyways, I'm going to remove that jumper.

[TopherMan]

Okay, one last question about power. Right now the mbed 5VOUT line is connected right to the USB 5V. If the mbed is powered on and a usb cable is connected to our board's usb, will that be an issue? Should we throw a jumper in there, or do you think the mbed is properly protected that this won't be an issue?

[TopherMan]

Okay, I lied, one more question. It was suggested to me that we eliminate the SD_detect line, freeing up that pin to be a Y-enable. Smoothie (and most other firmwares) use software card detection, so it seems that it would be advantageous to allow independent enabling/disabling of the X and Y axes. I am not bothered by tying the axes together, but as non-cartesian solutions become more popular, maybe fully independent control of the separate axes is desirable? Or is there some advantage to the SD_detect line I'm not getting, even though Smoothie doesn't use it?

If you think we should eliminate it (I'm leaning that way personally), I can adjust those paths and then add jumpers so that X, Y and A are all tied together for mbed, because I don't think there's any way around that. If a user wants independent control, they'll have to get the Xpresso.

[Noobman]

About 3v3 vbat i thought it could work entirely if the 3v3 is supplied there, but now i see it wouldnt. I would of liked source files, this is i love open source, can check things much easier. Btw RTC may be a good topic, i think we may have room underneath module to put a battery socket there, if needed. But will probably be inaccessible after the module is mounted.

Yes a jumper on 5vout may be wise, or perhaps a schottky diode. I thought of it the other way, like mbed powering our usb, not the other way around. Ex. if our board usb if it has to read a usb stick or some device which wants power. The mbed 5v is regulated with an "intellipower" sort of protector / boost regulator so its safe to use for that. Meaning 5v from our onboard usb wont power the other usb instead. From what i get from schematic, only mbed will power our usb, if needed. Thats what i thought.

There is no scenario when X is enabled and Y is disabled or viceversa. If X is enabled and makes a move and Y is disabled, then Y will move anywhere it wants to, its position is not secured. That never happens. Its ilogical for example to make a X move if you dont keep Y steadily in position, coz then Y is free to move by hand and can be pushed either way, and the movement will be diagonal instead of being straight. Whenever X makes a move, in order to ensure a coordinated move in both X-Y space, then Y must hold its position. This means that Y doesnt move, but its output have to be enabled so motor holds its position. Any firmware enables X and Y together, all the time, and even when one isnt moving it has to be enabled to hold position for the other to be able to make a correct movement. Even with non-extrusion movements. So if we change the xy separate thats guaranteed to be more of a 100% wasted pin, whereas card detect is less so :) Sort of speaking. Again, X and Y are never disabled separately, when one is enabled and moving the other is also enabled, even if it doesnt move, it has to be enabled and hold position. Movement of one of them doesnt make sense if the other is free to shift in any other position.

Mechanical card detect is the primary detect method in the uSD manual specifically stressed out repeatedly that its primary method and preferred to be used over the software one. The mechanical one is permanent state and can be interrogated at any time. The software one means watching one pin being high for a very short time after card insertion, then nothing. For software, its harder to keep watching that pin irq infinitely and perhaps even miss that signal window. Much easier and more reliable with mechanical card detect. I think this is why they are still making it like that.

• Thumbs up for taking vbat jumper out, and perhaps you decide if its any use to add a battery socket for rtc
• Yes to adding a jumper from mbed 5vout to our usb, nice spotting that along with vbat issue
• Imho i think we should keep the card detect line and keep xy-en together

[TopherMan]

Eh, not really concerned about the RTC. It wouldn't really add any functionality to the system, as far as I can tell.

I'll add in the jumper for the 5V and see where I can cram it.

I guess the switch is the way it should be done, but Smoothie currently doesn't use the detect line, and most other firmwares don't either. I'm not likely to make a bunch of changes to the firmware to support it (my programming skills are crap), and I don't think anyone else will either, since the Smoothieboard itself doesn't even have the detect line connected. Personally, I'd rather leave each axis fully independent so that users can reassign axes or use totally different configurations and not have to worry about combined enable lines, since the detect switch isn't supported in software. But if you think it's likely to be supported, I can add it back in.

I have to quit for the night, but I think tomorrow I should have a few big chunks of time to finish off my laundry list of issues. I'll reopen this to remind myself to add that jumper for the 5V to usb and make up my mind about the detect line.

[Noobman]

Ok look, i think i wasnt able to explain it better before. Its coz words and grammar and tone and place of a word in sentence isnt the same for me.

I have some trouble explaining things sometimes, so you also have to make an effort and meet me half way.

First, the person who suggested you to replace detect with distinct enable was wrong, and didnt understood it right. The cartesian space of these printers is called 2.5D, because use 2 dimensions, and sometimes Z does some work interactively (Z motor can be disabled at times). Some systems are true 3D, if they dont use layers but use true 3d motion, and in such case Z can not be disabled. If there are more axes, it can be 4D, 5D, perhaps even more. As extruder can be interpreted as an axis and can be multiples.

But the very minimum is 2D. Things like these doesnt exist in "1D". Letters you read now on screen are 2D, thats why you can read. There is no LCD screen with 1D in the world. It could not be read. Exactly the same way, the printer can not be 1D. This is why X and Y are enabled together. Represents the minimum useful dimensions.

There is absolutely no firmware that would have X enabled while Y is disabled. Nor viceversa. There is no situation where that could deliberately happen. There is no useful thingy that can be done in 1D. Even a lathe has an XY table and while one direction moves, the other direction needs to hold position otherwise the object would reflect back the cutter.

Now please understand that, it doesnt matter who, and for what will use this board, even with separate pins, the X and Y will always be identical state. The rest, Z, A, B, yes could be different deal, but x will always be identical. If x and y enable line is common, it doesnt mean that they are not "independant". The enable line is its dimension, not its ability to move or stay. By all intents and purposes, x and y with common enable are independent.

When an axis is disabled, the dimension that it represents ceases to exist. Permanently. You cant enable it later to get the dimension back, because the "positional information" is already lost when you cant be sure the axis havent moved either way because it was free to move from any vibration or notch. The Z is an exception as can be disabled and re-enabled coz we assume it holds position because its vertical and gravity doesnt let it go up, and its mounted on screws which wont let it dropping low. But the X and Y are not like that, ideally these move easy so its the opposite. Again, X and Y represent 2D, which is bare minimum for anything to happen. Anything useful.

If you look at other boards like ramps, it has distinct enable coz it has more pins than it knows what to do with them. Other boards have distinct enables if driver chips are soldered, and if one burns out, then user may need to reassign pin definition to another. In our case, neither is the case.

All the firmwares have enable definitions distinct per axis, but thats a configuration thingy. One line of code and copy paste. But thats not how they actually work in practice. The X, Y, E, are enabled at the start of the print and disabled after the completion. If they would be disabled in between, it could result in layer misalignement or missed out extruder coz the filament pushing back the extruder rotor. In our case 3d printers, only Z gets disabled from time to time during the print, thats all.

• But, after all i said above, in interest of open mind and learning, i will agree to separate enables if you can only justify it. So try make a justification and one scenario where you would actually want them to have different state. For example: when and why you would want to have one enabled and the other disabled. I am telling you before hand, AFAIK such situation does not exist. As far as i know. And as far as i can understand and imagine things. But on the other hand, during my pity life so far, i have to admit i have been wrong before ... quite some times ... so lets see if i am now too :)

Oh this ended up quite a wall of text. Starts to feel like a pity coz i got a feeling you will just skip it :)

[TopherMan]

Your English is better than you give yourself credit for, I understand what you mean. I know that in a standard Cartesian system you wouldn't ever need to keep X enabled while disabling Y or vice versa. I just know that I've seen people reassign axes because of broken parts on a board or just because they can. And, with the advent of SCARA and delta bots and other crazy configurations it seemed like a good idea to leave each axis separate for use cases that hadn't occurred to me yet. It's not totally necessary, I just figured that since the SD detect doesn't have software support it freed the pin up, and I liked the symmetry of each stepper being controlled independently. I didn't expect such strong feelings ;-). If you're not convinced I'll switch it back later today.

On Sat, Jun 1, 2013 at 11:17 PM, Noobman notifications@github.com wrote:

Ok look, i think i wasnt able to explain it better before. Its coz words and grammar and tone and place of a word in sentence isnt the same for me.

I have some trouble explaining things sometimes, so you have to meet me half way.

First, the person who suggested you to replace detect with distinct enable was wrong, and didnt understood it right. The cartesian space of these printers is called 2.5D, because use 2 dimensions, and sometimes Z does some work interactively (Z motor can be disabled at times). Some systems are true 3D, if they dont use layers but use true 3d motion, and in such case Z can not be disabled. If there are more axes, it can be 4D, 5D, perhaps even more. Even extruder can be interpreted as an axis.

But the very minimum is 2D. Things like these doesnt exist in "1D". Letters you read now on screen are 2D, thats why you can read. There is no LCD screen with 1D in the world. It could not be read. Exactly the same way, the printer can not be 1D. This is why X and Y are enabled together. Represents the minimum useful dimensions.

There is absolutely no firmware that would have X enabled while Y is disabled. Nor viceversa. There is no situation where that could deliberately happen. There is no useful thingy that can be done in 1D. Even a lathe has an XY table and while one direction moves, the other direction needs to hold position otherwise the object would reflect back the cutter.

Now please understand that, it doesnt matter who, and for what will use this board, even with separate pins, the X and Y will always be identical state. The rest, Z, A, B, yes could be different deal, but x will always be identical. If x and y enable line is common, it doesnt mean that they are not "independant". The enable line is its dimension, not its ability to move or stay. By all intents and purposes, x and y with common enable are independent.

When an axis is disabled, the dimension that it represents ceases to exist. Permanently. You cant enable it later to get the dimension back, because the "positional information" is already lost when you cant be sure the axis havent moved either way because it was free to move from any vibration or notch. The Z is an exception as can be disabled and re-enabled coz we assume it holds position because its vertical and gravity doesnt let it go up, and its mounted on screws which wont let it dropping low. But the X and Y are not like that, ideally these move easy so its the opposite. Again, X and Y represent 2D, which is bare minimum for anything to happen. Anything useful. All the firmwares have enable definitions distinct per axis, but thats a configuration thingy. One line of code and copy paste. But thats not how they actually work in practice. The X, Y, E, are enabled at the start of the print and disabled after the completion. If they would be disabled in between, it coul d result in layer misalignement or missed out extruder coz the filament pushing back the extruder rotor. In our case 3d printers, only Z gets disabled from time to time during the print, thats all.

• But, after all i said above, in interest of open mind and learning, i will agree to separate enables if you can only justify it. So try make a justification and one scenario where you would actually want them to have different state. For example: when and why you would want to have one enabled and the other disabled. I am telling you before hand, AFAIK such situation does not exist. As far as i know. And as far as i can understand and imagine things. But on the other hand, during my pity life so far, i have to admit i have been wrong before ... quite some times ... so lets see if i am now too :)

Oh this ended up quite a wall of text. Starts to feel like a pity coz i got a feeling you will just skip it :)

— Reply to this email directly or view it on GitHubhttps://github.com/TopherMan/XpressoSmoothie/issues/11#issuecomment-18801212 .

[TopherMan]

Okay, got that jumper in there. It's sorta crammed, and I don't like that it's close enough to the 3.3V jumper that an inattentive person could cross them, but I couldn't make it fit any other way. If you see a better way to lay it out, feel free to give it a try.

[Noobman]

Oh, ok im not emo :) I'm just like that when trying to explain best i can. I wanted to point out that having xy-en together has no disadvantage at all, not for us anyway: for us its even better.

Doesnt matter the type of machine, cartesian, scara, rostock, etc, doesnt matter if coordinates are polar or cartesian or else. This is more fundamental matter, before all that. Any machine type needs at least two actuators to work in 2D space.

If the card detect is not worthy of a pin and we would drop that, we could shift all the pins there to the left, and have the freed pin moved in the expansion header.

Also if the jumpers do not fit in acceptable way, for the jumpers that are specific to LPC or mbed, we can use solder pads. Coz those are presumably set only once, depending on the module used, and that shouldnt change much. But solder pads would need to be accessible, e.g. put on the bottom layer so the user can just flip the board and have easier access to solder or de-solder them.

[TopherMan]

I have it squeezed in there, so take a look at it and tell me if you think it's worth replacing with solder pads (I forgot about them in our jumper-frenzy). I don't know how likely it is for someone to put the jumpers wrong.

On Sun, Jun 2, 2013 at 2:01 PM, Noobman notifications@github.com wrote:

Oh, ok im not emo :) I'm just like that when trying to explain best i can. I wanted to point out that having xy-en together has no disadvantage at all, not for us anyway: for us its even better.

Doesnt matter the type of machine, cartesian, scara, rostock, etc, doesnt matter if coordinates are polar or cartesian or else. This is more fundamental matter, before all that. Any machine type needs at least two actuators to work in 2D space.

If the card detect is not worthy of a pin and we would drop that, we could shift all the pins there to the left, and have the freed pin moved in the expansion header.

Also if the jumpers do not fit in acceptable way, for the jumpers that are specific to LPC or mbed, we can use solder pads. Coz those are presumably set only once, depending on the module used, and that shouldnt change much. But solder pads would need to be accessible, e.g. put on the bottom layer so the user can just flip the board and have easier access to solder or de-solder them.

— Reply to this email directly or view it on GitHubhttps://github.com/TopherMan/XpressoSmoothie/issues/11#issuecomment-18810568 .

[Noobman]

Just looked at them now and i think the jumpers look great, so i think its good like that, no need for solder pads.