Particle Build is throwing several errors like this:
error: ‘uint8_t’ does not name a type
I’m sorry to say that this is not a new topic, I’ve read through the other posts on the same problem. But I have #include “application.h” in the .ino and .cpp files. This is what is prescribed in most of the replies. Still getting this error.
These type are listed in the Reference > Data Type section.
This is a port of an Arduino project to Particle Electron. Any further suggests would be appreciated.
What code are you trying to port?
Sometimes, this might be useful with porting projects. It might yield some more clues. This particular command disables the pre-processor.
#pragma SPARK_NO_PREPROCESSOR
I can reproduce this using:
#pragma SPARK_NO_PREPROCESSOR
uint8_t alpha;
void setup() {
}
void loop() {
}
$ particle compile electron
Compiling code for electron
Including:
testCode.ino
attempting to compile firmware
Compile failed. Exiting.
Processing testCode.ino
Skipping .ino file
make -C ../modules/electron/user-part all
make[1]: Entering directory '/firmware/modules/electron/user-part'
make -C ../../../user
make[2]: Entering directory '/firmware/user'
Building cpp file: testCode.cpp
Invoking: ARM GCC CPP Compiler
mkdir -p ../build/target/user/platform-10-m
arm-none-eabi-gcc -DSTM32_DEVICE -DSTM32F2XX -DPLATFORM_THREADING=1 -DPLATFORM_ID=10 -DPLATFORM_NAME=electron -DUSBD_VID_SPARK=0x2B04 -DUSBD_PID_DFU=0xD00A -DUSBD_PID_CDC=0xC00A -DSPARK_PLATFORM -g3 -gdwarf-2 -Os -mcpu=cortex-m3 -mthumb -DINCLUDE_PLATFORM=1 -DPRODUCT_ID=10 -DPRODUCT_FIRMWARE_VERSION=65535 -DUSE_STDPERIPH_DRIVER -DDFU_BUILD_ENABLE -DSYSTEM_VERSION_STRING=0.6.2 -DRELEASE_BUILD -I./inc -I../wiring/inc -I../system/inc -I../services/inc -I../communication/src -I../hal/inc -I../hal/shared -I/rtos/FreeRTOSv8.2.2/FreeRTOS/Source/include -I/rtos/FreeRTOSv8.2.2/FreeRTOS/Source/portable/GCC/ARM_CM3 -I../hal/src/electron -I../hal/src/stm32f2xx -I../hal/src/stm32 -I../platform/shared/inc -I../platform/MCU/STM32F2xx/STM32_USB_Host_Driver/inc -I../platform/MCU/STM32F2xx/STM32_StdPeriph_Driver/inc -I../platform/MCU/STM32F2xx/STM32_USB_OTG_Driver/inc -I../platform/MCU/STM32F2xx/STM32_USB_Device_Driver/inc -I../platform/MCU/STM32F2xx/SPARK_Firmware_Driver/inc -I../platform/MCU/shared/STM32/inc -I../platform/MCU/STM32F2xx/CMSIS/Include -I../platform/MCU/STM32F2xx/CMSIS/Device/ST/Include -I../dynalib/inc -I -I./libraries -I -I -I -I -I. -MD -MP -MF ../build/target/user/platform-10-mtestCode.o.d -ffunction-sections -fdata-sections -Wall -Wno-switch -Wno-error=deprecated-declarations -fmessage-length=0 -fno-strict-aliasing -DSPARK=1 -DPARTICLE=1 -DSTART_DFU_FLASHER_SERIAL_SPEED=14400 -DSTART_YMODEM_FLASHER_SERIAL_SPEED=28800 -DSPARK_PLATFORM_NET=UBLOXSARA -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -DLOG_INCLUDE_SOURCE_INFO=1 -DPARTICLE_USER_MODULE -DUSE_THREADING=0 -DUSE_SPI=SPI -DUSE_CS=A2 -DUSE_SPI=SPI -DUSE_CS=A2 -DUSE_THREADING=0 -DUSER_FIRMWARE_IMAGE_SIZE=0x20000 -DUSER_FIRMWARE_IMAGE_LOCATION=0x8080000 -DMODULAR_FIRMWARE=1 -DMODULE_VERSION=4 -DMODULE_FUNCTION=5 -DMODULE_INDEX=1 -DMODULE_DEPENDENCY=4,2,108 -D_WINSOCK_H -D_GNU_SOURCE -DLOG_MODULE_CATEGORY="\"app\"" -fno-exceptions -fno-rtti -fcheck-new -std=gnu++11 -c -o ../build/target/user/platform-10-mtestCode.o testCode.cpp
testCode.cpp:3:1: error: 'uint8_t' does not name a type
uint8_t alpha;
^
../build/module.mk:267: recipe for target '../build/target/user/platform-10-mtestCode.o' failed
make[2]: *** [../build/target/user/platform-10-mtestCode.o] Error 1
make[2]: Leaving directory '/firmware/user'
../../../build/recurse.mk:11: recipe for target 'user' failed
make[1]: *** [user] Error 2
make[1]: Leaving directory '/firmware/modules/electron/user-part'
../build/recurse.mk:11: recipe for target 'modules/electron/user-part' failed
make: *** [modules/electron/user-part] Error 2
When I add the #include "application.h" then all is well.
“Background” information:
The problem here seems to be the fact that only .ino files undergo the Wiring preprocessing which implicitly adds the #include <Particle.h> (= more recent version of application.h) statement which in turn includes the required headers, including types.h
While the #pragma switches off the preprocessor for .ino files and hence the explicit #include is required, for .h & .cpp files this explicit `#include’ is always required (direct or indirect).
BTW, from 0.6.2 on, porting Arduino libraries should be a fair bit simpler - as long there is no hardware specific code but standard Wiring code.
By not including Particle.h but Arduino.h a different set of #includes will be pulled in to enable a direct build with no alterations at all (in many cases).
Knowing which library you’re trying to port, might help to tell whether this needs “proper” porting or might just require some minor tweaks.
Thank you for responding.
The goal is to integrate this SeeedStudio multichannel gas sensor with an Electron. They communciate via I2C. The Arduino code for reading the sensor runs out-of-the-box on an Arduino Uno R3.
I have attempted to compile on both Particle Dev and Particle Build. Currently I'm compiling with Build, and flashing with CLI.
Changes made to the code so far:
> //#include <Wire.h> > #include "MutichannelGasSensor.h" > #include "application.h"
There are several Arduino programs included with the sensor. For example, GetVersion.ino compiles and runs. This short program obviously uses the same .cpp and .h files. Yet all of the compile errors are thrown from the .h file.
Have you added #include <Particle.h> (or <Arduino.h> if targeting 0.6.2+) to the .h file?
What system version are you targeting?
Try:
#include "application.h"
#include "MutichannelGasSensor.h"
@cermak, this might work (or not depending on module build order which is non-deterministic in the online build farm), but it is bad practice to rely on the order of include statements.
It would be better to have each individual file and module to be selfcontained by having the required include statements directly inside their own body.
Hence the question above
The current target is 0.4.8. That’s for an Electron purchased last week. Do they normally ship with a lower build version? Is 0.6.2 overall stable?
Yes 0.6.2 is stable - far more than 0.4.8.
But Electrons do still ship with 0.4.8 and hence you should upgrade them ASAP after purchase (best via CLI)
Update to 0.6.2 did it. Everything is working now!
BTW not require the <Arduino.h> include.
Many thanks for all the help.