I2C IO? #6
Comments
|
And I wasn't the first one either.
If you don't do code I think you will struggle with this, after the pcb is
made it is all about programming.
In the first pcb I did include connector J4 for access to the second I2C
bus, haven't used it but should be straight-forward I think.
There are many examples on how to program I2C so the function as such
should be possible.
Just keep in mind that everything works in cycles of 1 millisecond, and one
can possibly spend 300-400 microseconds doing things like checking i2c bus.
Or make it interrupt-driven in the background.
I haven't put up a video for a while now. Still stuck in step generator. It
works but not good enough, and I thought I should make it work fine first.
The PCB seems to work fine so you can take that as basis for you own design.
Den tors 28 mars 2024 kl 21:49 skrev ShadeTechnik ***@***.***
…:
Came across this whole project as I was actually in the middle of working
on almost the exact same thing, then realized I wasn't the first one to
have the idea which is good cuz I can't code to save my life lol.
Anyway once I get finished with my PCB I hope to be able to use this code.
One thing I was curious about is if you thought about adding support for
I2C IO expanders. I created a keypad a little while ago that has 4
MCP23017's that I'm eventually going to have to work into my
project.....but like I said, I don't do code lol.
—
Reply to this email directly, view it on GitHub
<#6>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7HWRIROKKQK5MLKRWHGTY2R66XAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTIMJSGA2DOMY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Yeah it'll be a bit of a chore for me to get it going but I've got a friend that can hopefully help me out. The PCB isn't really a concern, I'm just EtherCAT-izing an existing PCB. The one I'm currently working on is a bit more simple, it's for a control panel so it doesn't need the stepgens. From what I'm looking at so far (please correct me if I'm wrong) you used the timer based encoder peripherals. I need like 4 encoders, but much lower performance. The timer peripherals cause conflicts with other peripherals so I was just going to use an interrupt based encoder library. Once I get this sorted out and working maybe I'll do something for higher performance encoders and stepgens, this one's hopefully going to solve some other issues I had and just get me into the world of EtherCAT. Do you have an email or some way to contact in case I have questions if you don't mind? |
|
I think four of the timers have quadrature counting built-in and that's
what I was using. I am aiming for 100 kHz at least, that should be no
problem.
If you look in the source code I think tim1, tim2, tim5 and tim8 are
prepared for in the stm32encoder,cpp file. Those pins are fixed position
but often other pins can be moved around. On the other hand it shouldn't be
a problem to use interrupt based encoder counting.
Just be aware that if you attach an interrupt to, say, pin PB9, you can not
attach interrupts to PA9, PC9, PD9, PE9. This goes for all numbers.
And you need to handle the counter overflowing when turning many revs, but
that's kind of standard.
The interface to the LAN9252 is pretty clean. SPI(data, clock, chip
select), INT, SYNC0, SYNC1 (and RESET, but I don't think LAN9252 has that
line, the ax58100 does) are the lines you need to
work with on the MCU. Possibly make changes for those pin numbers in the
SOES library code. Place SPI with hardware support, you want to run SPI at
40 MHz or above.
Most of the functions are not that extremely timing dependent, stepgen
stands out there. I'll try to get some time now during eastern to make it
work.
Den fre 29 mars 2024 kl 13:40 skrev ShadeTechnik ***@***.***>:
… Yeah it'll be a bit of a chore for me to get it going but I've got a
friend that can hopefully help me out.
The PCB isn't really a concern, I'm just EtherCAT-izing an existing PCB.
The one I'm currently working on is a bit more simple, it's for a control
panel so it doesn't need the stepgens. From what I'm looking at so far
(please correct me if I'm wrong) you used the timer based encoder
peripherals. I need like 4 encoders, but much lower performance. The timer
peripherals cause conflicts with other peripherals so I was just going to
use an interrupt based encoder library.
Once I get this sorted out and working maybe I'll do something for higher
performance encoders and stepgens, this one's hopefully going to solve some
other issues I had and just get me into the world of EtherCAT. Do you have
an email or some way to contact in case I have questions if you don't mind?
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7HWSMRJY2X33G3QCUDO3Y2VOKXAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGE4DQNZWGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I'm actually using a smaller STM32 than you did, mine is just for a control panel and I'm using some of the GPIO from the LAN5952. I use STM32cubeIDE to check the peripherals for conflicts. I was only able to squeeze 1 timer based encoder out but that'll just be for an MPG, the others will be for like feedrate OR knobs and such so they don't demand any performance. I was able to get them all on interrupt lines without issue. I think I managed to get my code wizard friend involved, I've asked him set me up a repo with the code arranged in a more idiotproof manner so hopefully I can follow it well enough to make necessary adjustments. He's not a machine/ethercat guy but he does do embedded programming. I know you didn't really mention a reason for switching ESC chips but did you have some problem with the LAN9252? It's readily available and has what I need so it seems like my best bet, just curious if there's some reason I should not use it. LAN5952 does have a nRST line. I'm debating tying it to the STM32 nRST and running them both to the same reset button. |
|
You can't mix digital IO from the LAN9252 with MCU access using SPI. It's
either or. Check PDI MODE SELECTION, first byte in the eeprom.
One can use any MCU, not only one of the STM32s. I had it working on an
esp32 and it worked just fine, don't think I saved that "port".
It's not that much to do, mainly to get SPI working and then it works.
No I don't really have a problem with the LAN9252. I saw somewhere that
there is a bit of SPI communication overhead and that guy got
some disappointing reaction times. Not that it matters for linuxcnc. I have
had a number of issues and I sometimes suspect the LAN9252
and at one point I thought I should at least try to eliminate that factor.
So far it has turned out that LAN9252 works just fine and I haven't
come to work the AX58100 yet. Another big plus for the LAN9252 is the data
sheet. The LAN9252 has all details documented, the ax58100 does not.
Yes use one button for both, I have that on the ax58100 design. On the
LAN9252 design nRST is constant pulled-up, doesn't seem to be a problem
that it can't be reset.
I do download new code and reset the MCU regularly during development and
linuxcnc takes a few seconds pause and then its work with the new firmware.
Den sön 31 mars 2024 kl 03:02 skrev ShadeTechnik ***@***.***>:
… I'm actually using a smaller STM32 than you did, mine is just for a
control panel and I'm using some of the GPIO from the LAN5952. I use
STM32cubeIDE to check the peripherals for conflicts. I was only able to
squeeze 1 timer based encoder out but that'll just be for an MPG, the
others will be for like feedrate OR knobs and such so they don't demand any
performance. I was able to get them all on interrupt lines without issue.
I think I managed to get my code wizard friend involved, I've asked him
set me up a repo with the code arranged in a more idiotproof manner so
hopefully I can follow it well enough to make necessary adjustments. He's
not a machine/ethercat guy but he does do embedded programming.
I know you didn't really mention a reason for switching ESC chips but did
you have some problem with the LAN9252? It's readily available and has what
I need so it seems like my best bet, just curious if there's some reason I
should not use it.
LAN5952 does have a nRST line. I'm debating tying it to the STM32 nRST and
running them both to the same reset button.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7HWTQRS3MIVOSKZ4RMP3Y25ODVAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYGUYTMMRSHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This I wasn't sure about. I initially thought this but the illustration on page 10 of the the datasheet suggests this is possible "Microcontroller Mode (via SPI)" appears to show the GPIOs being active. I could not find anything that states it either way definitively but from what I gathered the GPIOs are disabled using parallel HBI or "expansion mode" as those 2 modes used the GPIO pins for either host communication or the 3rd Ethernet port. Have you actually tested this? I haven't picked up a LAN9252 dev board to test, it's actually easier for me to just produce a prototype PCB and tinker with that so I can't test it but it would be nice to be certain that you can't do this before I bother. |
|
You are right, it can be mixed. Didn't see that.
I wonder how that should be configured in the esi file. Are they on their
own sync managers? Maybe that is best.
Afaik SOES reads and writes the entire syncmanager contents for the RxPDO
and TxPDO. Can't have the GPIOs there.
There is an example esi file for pure Digital IO. I guess one can merge
that with an esi file for the MCU part.
Those are things that comes to mind when using the GPIOs.
Den sön 31 mars 2024 kl 16:29 skrev ShadeTechnik ***@***.***>:
… You can't mix digital IO from the LAN9252 with MCU access using SPI. It's
either or. Check PDI MODE SELECTION, first byte in the eeprom.
This I wasn't sure about. I initially thought this but the illustration on
page 10 of the the datasheet suggests this is possible "Microcontroller
Mode (via SPI)" appears to show the GPIOs being active. I could not find
anything that states it either way definitively but from what I gathered
the GPIOs are disabled using parallel HBI or "expansion mode" as those 2
modes used the GPIO pins for either host communication or the 3rd Ethernet
port. Have you actually tested this?
I haven't picked up a LAN9252 dev board to test, it's actually easier for
me to just produce a prototype PCB and tinker with that so I can't test it
but it would be nice to be certain that you can't do this before I bother.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7HWXYQETCS6LERB5UUPTY3AMUVAVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYG43TENZWGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Well I'm hoping my friend can sort most of that out, what I have found in the datasheet:
|
|
Have a look at this MicroChip HBI+ evaluation board. It combines GPIO with
a PIC32.
I checked in the software support files. There is an esi file that at a
quick glance seems to combine GPIO with MCU data.
https://www.microchip.com/en-us/development-tool/evb-lan9252-hbiplus
Den tis 2 apr. 2024 kl 17:10 skrev ShadeTechnik ***@***.***>:
… Well I'm hoping my friend can sort most of that out, what I have found in
the datasheet:
12.5 Host Interface PDI
The value in the Extended PDI Configuration Register is used if GPIOs are
enabled (SPI w/GPIO).
12.14.30 EXTENDED PDI CONFIGURATION REGISTER
The bit definitions of this register are dependent on the selected PDI
mode (Process Data Interface field in the PDI Control Register): Digital
I/O Mode or SPI Mode.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACY7HWXKOJESEABRMRTJPJ3Y3LC75AVCNFSM6AAAAABFNO2CQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSGMYTQOJSHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Came across this whole project as I was actually in the middle of working on almost the exact same thing, then realized I wasn't the first one to have the idea which is good cuz I can't code to save my life lol.
Anyway once I get finished with my PCB I hope to be able to use this code. One thing I was curious about is if you thought about adding support for I2C IO expanders. I created a keypad a little while ago that has 4 MCP23017's that I'm eventually going to have to work into my project.....but like I said, I don't do code lol.
The text was updated successfully, but these errors were encountered: