Seeeduino XIAO - invalid conversion error

Certainly not helping with your question, but asking my own:  are GPS devices allowed in rally computers?

Tom

#H&WTR

#ModelRailroad

The use of GPS depends on the propositions of the organizer of the race of old cars.

In general, however, GPS-based devices are much less accurate than those that calculate parameters based on wheel speeds.

Given that accuracy (measured in centimeters and seconds) is very important in such competitions, the measurement of parameters is much more reliable based on the counting of wheel revolutions.

To illustrate, I give an example of a calculation: the circumference of a wheel is 2 * 3.14 * radius. At a radius of 30 cm the circumference of the wheel is 188.4 cm, at a radius of 31 the circumference of the wheel is 194.7 cm. So a radius difference of 1 cm means 6.28 meters at 100 revolutions of the wheel.

The stages on which the driving accuracy is measured can be several kilometers long, which means that the difference at the finish of the stage can be huge only due to a small change in radius. In serious competitions, therefore, the organizer allows the calibration of rally computers due to the difference in tire pressure

Thanks, @nemo!  I remember a lot of this - calibration with substitute gear ratio mechanisms selected when the tires were hot and so on.  I remember old rally cars with add-on odometer cables running outside the body to the wheel hubs - of course to a non-driven driven wheel.  (Cars were all two-wheel drive then.)  When I was involved GPS had not been contemplated.  And now I do not believe that the mechanical modes will be more accurate than GPS for rally navigation - not to mention the fact that the mechanical modes do not tell you where you are or where you have been.  But I asked if they were allowed because of the navigation fun and challenges without.

Posted by: @nemo

I made a rally computer. Its purpose is to measure time, distance and speed (current, average ...) and display values on three LED tubes. The rally computer is based on the Arduino Nano. Based on the hall sensor, it counts the wheel revolutions and calculates the driving parameters. It happens that an individual pulse is missing, which leads to an incorrect speed calculation. I assume the lack of pulses is due to the low speed of the Nano's processor so I will try with a faster XIAO microcontroller.

Here, however, the problem of a small number of pins arises. To solve the problem, I plan to connect two XIAOs. I looked at “I2C Communications Part 1 - Arduino to Arduino” and tried to connect the two XIAOs. When compiling the slave part of the sketch, I got an error message:

invalid conversion from 'void (*) ()' to 'void (*) (int)' [-fpermissive].

Compiling into Arduino Nano is error free.

Help please!

Thank you!

I redid all the Uno I2C demos from the video you mentioned and they worked for me on the Xiao.  All I did was add the board files for Seeeduino in Preferences and then select the right board and Port for serial.

thank you @jfabernathy for your effort!

I still failed to load the "Slave" application without error. I studied the compile log and found that I have two versions of the "Wire" file on disk.

One is on: "/ Users / Documents / Arduino / libraries / Wire"

and the other is at: "/Users/Documents/ArduinoData/packages/Seeeduino/hardware/samd/1.8.1/libraries/Wire".

Second version was used for Compilation.

Which version of the Wire file did you use?

Posted by: @nemo

thank you @jfabernathy for your effort!

I still failed to load the "Slave" application without error. I studied the compile log and found that I have two versions of the "Wire" file on disk.

One is on: "/ Users / Documents / Arduino / libraries / Wire"

and the other is at: "/Users/Documents/ArduinoData/packages/Seeeduino/hardware/samd/1.8.1/libraries/Wire".

Second version was used for Compilation.

Which version of the Wire file did you use?

OKAY, figured out why it would not complie.

You need to define the receiveEvent to match the Wire.h library definition exactly.

void receiveEvent(int howmany)

Posted by: @nemo

I made a rally computer. Its purpose is to measure time, distance and speed (current, average ...) and display values on three LED tubes. The rally computer is based on the Arduino Nano. Based on the hall sensor, it counts the wheel revolutions and calculates the driving parameters. It happens that an individual pulse is missing, which leads to an incorrect speed calculation. I assume the lack of pulses is due to the low speed of the Nano's processor so I will try with a faster XIAO microcontroller.

Here, however, the problem of a small number of pins arises. To solve the problem, I plan to connect two XIAOs. I looked at “I2C Communications Part 1 - Arduino to Arduino” and tried to connect the two XIAOs. When compiling the slave part of the sketch, I got an error message:

invalid conversion from 'void (*) ()' to 'void (*) (int)' [-fpermissive].

Compiling into Arduino Nano is error free.

Help please!

Thank you!

Compilers are pretty smart these days, and as such they show you the exact error:

    'void (*) ()' represents a pointer to a function taking NO arguments

    'void (*) (int)' represents a pointer to a function taking one integer as an argument

These types of pointers are used to implement 'callback' functions.

I can explain them a little more, if you like to know more about them and how they work.

Cheers.

 Thanks for the reply @frogandtoad,

I would really appreciate a more detailed description.

Perhaps I should first describe how I envision communication between the two XIAOs:

as I described in the first post, the problem is too few pins to connect three LED trumpets, 6 switches, a hall sensor, maybe even a flash memory card module. I plan the XIAO master to calculate the driving parameters and send the results to the XIAO slave to print data on the LED tubes.

For a start, I am studying how to connect two XIAOs, and later I will think further about how to perform the transfer of all data to LED tubes.

I would very much appreciate any hint on how to optimally organize the operation of the device

@nemo

Posted by: @frogandtoad

Compilers are pretty smart these days, and as such they show you the exact error:

    'void (*) ()' represents a pointer to a function taking NO arguments

    'void (*) (int)' represents a pointer to a function taking one integer as an argument

These types of pointers are used to implement 'callback' functions.

I can explain them a little more, if you like to know more about them and how they work.

Cheers.

Posted by: @nemo

Thanks for the reply @frogandtoad,

I would really appreciate a more detailed description.

Perhaps I should first describe how I envision communication between the two XIAOs:

as I described in the first post, the problem is too few pins to connect three LED trumpets, 6 switches, a hall sensor, maybe even a flash memory card module. I plan the XIAO master to calculate the driving parameters and send the results to the XIAO slave to print data on the LED tubes.

For a start, I am studying how to connect two XIAOs, and later I will think further about how to perform the transfer of all data to LED tubes.

I would very much appreciate any hint on how to optimally organize the operation of the device

My apologies if you misunderstood me... I was focusing on your errors, and referring to how function pointers are implemented and used in callback functions.  I do not have any XIAO's to be able to test anything out at this stage to help you in your particular situation using I2C.  If you're still interested in function pointers and callbacks however, please let me know and I will be happy to explain how they work.

Cheers.

I solved the problem regarding the communication XIAO Master to XIAO Slave. Thanks @jfabernathy!

The app is organized in such a way that the Master calculates the driving parameters and sends them to Slave. Slave displays data on LED display. However, there are some interrupt functions in the program that make communication difficult. So I decided to run app on ESP32. 

However, there is a problem with writing to the LED. I will open a new topic...