search

grblHAL / iMXRT1062

grblHAL driver for NXP iMXRT1062 (Teensy 4.x)
Other
51 stars 39 forks source link

Question: Why is it an error to use a pin other than 12 or 13 for SPN PWM? #63

Closed ByronAP closed 1 year ago

ByronAP commented 1 year ago

Why is it an error to use a pin other than 12 or 13 for Spindle PWM?

https://github.com/grblHAL/iMXRT1062/blob/0b109fbf186890b9e1febedc92b650062ee97734/grblHAL_Teensy4/src/driver.h#L187C10-L187C10

terjeio commented 1 year ago

Because there is no code support yet for other pins. This may change but it takes time to implement support for more pins - and this may include shuffling other timers around. Recently generic code was added for auxillary analog output, similar code could be used for the spindle PWM.

ByronAP commented 1 year ago

ok, thank you and thank you for all your hard work, guess I will change my design around a bit. Any other pins that are inflexible at the moment that I should be aware of?

terjeio commented 1 year ago

Any other pins that are inflexible at the moment that I should be aware of?

The serial (UART) and I2C ports.

IMO you should consider adding at least a footprint for an I2C EEPROM (or FRAM) if you have not done so already.

ByronAP commented 1 year ago

I have CAN, IIC and Serial broken out I also had SPI but I might need to ditch that (need more pins). I am not sure what the point of adding an EEPROM is though since we already have USB and SDCard? Please excuse my ignorance I am new to your project.

terjeio commented 1 year ago

I2C (or IIC) EEPROM or FRAM for settings/parameter storage is IMO preferable to using flash as flash wears out faster than EEPROM. FRAM practically never wears out. For hobby use likely not an issue - but it is nice to have the option to add one.

ByronAP commented 1 year ago

Ahh yeah good call, flash is very limited in write cycles and shouldn't be used for that. Thank you so much for all the information. Wish I had asked about this stuff before I ordered my first version prototypes lol but hey that's what protos are for. I'm thinking I'm going to have to use maybe an expander over IIC to make more ports but that is probably going to require a ton of code to deal with. Do you have any suggestions in that area, perhaps I missed something where this or something similar was already done?

BTW I hope you don't mind that I'm working on remaking IOSender using AvaloniaUI.

ByronAP commented 1 year ago

YUP PITA, I'm looking at PCAL6408A and similar chips the issue I see is reliability and all the code required to detect an error and issue a reset which would clear the chips buffers and lose data which could be a disaster.

ByronAP commented 1 year ago

Yeah looks like the transfer error/failure rate of these kinds of chips > 1 in 1M which is really bad IMHO so I will toss that idea in the ether. Again, thank you for everything you do.

terjeio commented 1 year ago

I'm thinking I'm going to have to use maybe an expander over IIC to make more ports but that is probably going to require a ton of code to deal with.

An expander is not needed unless you are adding a lot of I2C peripherals or there are address clashes. To avoid address clashes I have a 10K pullup on the EEPROM A2 line and the the option of a solder bridge to ground for it.

Do you have any suggestions in that area, perhaps I missed something where this or something similar was already done?

What I have done for my CNC breakout boards is to add a level shifter (TCA9406) with selectable voltage (VCCB) so I can connect external 5V devices.

image

BTW I hope you don't mind that I'm working on remaking IOSender using AvaloniaUI.

No, the code is written in a way to make it reusable. E.g. the core project has no UI. Are you able to reuse any code at all?

ByronAP commented 1 year ago

Yes, well sort of. I am new to GRBL, I was on mach3 for something like 20 years. I didn't like GRBL at first, seemed completely foreign. However, after learning more about it and looking at the ecosystem I am starting to understand it and why it has gained so much traction despite limited software. So being new I don't fully understand the protocol and all the params which IOSender is really helping me learn and those are the major pieces I am reusing. There are some issues that are on my list that will be a problem such as cross platform preview. I am working on cross platform com ports which is unreliable at best, but I think I am close to stable. Hopefully Linux/MAC people will understand what /dev devices are since I can't seem to think of a nice way to sugar coat the actual address unlike windows which you have the com port # and a friendly name. I do think since AvaloniaUI provides access to SKIA I can use that to render the preview by building it as a vector drawing but parsing the g-code to to actual paths will be a challenge for me since I don't understand the way arcs and stuff are done. All in all though even if I don't have a previewer / view window I still think the rest will be a lot more robust in terms of reliability. I started this because I can only get IOSender to behave somewhat properly by running it from visual studio and disabling some of the startup machine status checks. Even doing that it still hangs and doesn't reconnect to the controller automatically if the WS gets disconnected even for a split second and closing the app usually requires a force stop. Anyway you get the idea. Would you mind if I run my board design past you to get your thoughts? I am a software guy that just dabbles in hardware and like everything the more eyes the better,

terjeio commented 1 year ago

parsing the g-code to to actual paths will be a challenge for me since I don't understand the way arcs and stuff are done.

Arcs are rendered as small straigth line segments similar to how it is done in the controller. Parsing and tokenizing is handled by the core so it is fairly straigthforward to render a 3D view.

Would you mind if I run my board design past you to get your thoughts?

That is ok, but may take some time as I'll be away for a few days.