-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP32, NMEA2000_esp32: Half speed (125kbps)? #10
Comments
Could this have something to do with peripherial clock frequency, which should be 80 MHz for proper dividers? If you changed speed(CAN_SPEED_500KBPS), didn't it change bus speed on oscilloscope? Setting effects directly to the prescaler setting. Setting MODULE_CAN->IER.U = 0xef; enables all interrupts, but leaves bit4 to zero. So setting this to 0, disables all interrupts and it will not work for sure. I could not find anything from technical reference. |
Can you point some test module with ESP32-Wroom-DA |
Hi Timo,
Thanks so much for considering this for me... I tried to fake it out with
the 500kb speed declaration, but it seemed to ignore it. It then dawned on
me that the default pins for the CAN interface are not where the files
direct it to be by default (GPIO16 and 4 - Tx/Rx). I have the serial
output streamed on UART 0 pins (GPIO1 and 3 - Tx/Rx) on the processor, but
I misinterpreted this as the CAN output. Changing the serial port baud rate
from 115200 to 250000 changed the output to 250k confirming that I'm
looking at the wrong pins. I remember not finding the output on the default
pins (GPIO16 and 4 - Tx/Rx) when I first migrated to this ESP from the
Mega. I think I hunted the Tx signal with my scope and found it on GPIO1
just attached it there; I should have looked to see that this was also the
serial output used for streaming the output to a PC. I thought this was
just a doc error as I could not find a Tx signal on any other pins. I
think my problem is really that I don't have CAN output on the expected
pins and it seems to ignore assignments to other pins...
My hardware set-up was pretty messy, so I have mounted the boards and
cleaned up the wiring so I can compare my functioning Arduino Mega set-up
with the ESP32-Wroom setup in question; I should have the improved set-up
running today. It is possible that the Arduino Utility is simply
identifying the ESP32-Wroom as a name not recognized by the software. You
have provided a way to force the board assignment and I intend to do this
first when I get the improved hardware set-up finished later today.
I will let you know the results and I will give a better detailed report.
THanks so much for your help!
Best Regards,
Randy
…On Sat, Jul 23, 2022 at 11:56 PM Timo Lappalainen ***@***.***> wrote:
Can you point some test module with ESP32-Wroom-DA
—
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2B7AESGZ4N6OS4RVBAT2ODVVS5FHANCNFSM53TKWPOA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
As stated in commenst on NMEA2000_CAN.h you can set nearly any pins by setting e.g.,: With this you override default pins 16/4 |
Hi Timo, I think the root cause of my issues was that I was using a wrong piece of pin assignment documentation for the ESP32-Wroom-DA... It turns out that there are several of these modules with the same chip, but different pin assignments on the PCBs. I noticed the markings on the board didn't align with the pin assignment chart when I was rebuilding my test set-up. After getting through the document issue, everything worked exactly as you stated, including the ability to re-assign the pins from the default to the ones I needed to use. Sorry for the false alarm on the baud rate issue and thanks for helping me through this! Best Regards, Randy |
Hi,
First let me start by saying how much I appreciate the NMEA2000 project and I have already used it successfully with a couple of Arduino MEGAs although way through to talking with a Garmin display -- This is a great project! The MEGAs worked fine on the NMEA side, but I needed more processing power on the hardware control side so I upgraded to an ESP32-Wroom-DA. This worked fine with the temperature sample as well as my application code when streamed to the serial port and an Actisense reader (brilliant instrumentation method BTW). However, it didn't work with my Garmin display and I determined that the but rate was half speed with an oscilloscope. I think I found the reason -- The chip manufacturer changed added a bit that toggles the CAN bus to half speed by default. I also think I found where this is dealt with by the NMEA2000_esp32.CPP:
I changed this by what I thought was the correct bit, but the speed didn't change on my scope. I even set it 0x00 and 0xff and it did not change. Didn't seem to affect it either way...
I then tried to force the speed to 500KPS by changing the CAN speed in the following and I did not see it affect the output either..
tNMEA2000_esp32::tNMEA2000_esp32(gpio_num_t _TxPin, gpio_num_t _RxPin) :
tNMEA2000(), IsOpen(false),
speed(CAN_SPEED_250KBPS), TxPin(_TxPin), RxPin(_RxPin),
RxQueue(NULL), TxQueue(NULL) {
}
I think the fix is already in the files, but I'm just not seeing what is probably right before my eyes.. I'm more of a hardware guy, so I can use all the help I can get!
Please let me know if anyone can provide guidance...
Thanks!
Randy
The text was updated successfully, but these errors were encountered: