Arduino command to verify code - Jenkins testing

[raquelalegre]

Find how to verify (i.e. compile) arduino code in the command line so that it can be tested in Jenkins.

[Jimbles]

hello - this should be ok to do following the guide here

Jenkins is another story

[raquelalegre]

Does the command work for you, @Jimbles? I haven't tried very hard, just typed:

arduino --verify /full/path/to/ScouseTom_Control.ino

and it displays errors for all the clock stuff, plus other things like:

ScouseTom_Control.ino:211:2: error: 'Serial1' was not declared in this scope

Maybe I need to add a flag or something to import the clock stuff? But what about Serial1? I'll have a look, I haven't spent much time on it yet, to be honest.

The biggest problem with this at the moment is no matter how you run the command, it always displays the IDE window. This is a problem in Jenkins, which doesn't like windows, and there is no way yet to prevent arduino from prompting a window.

This might be a workaround, but I'm not very hopeful.
I've also been pointed out this other solution could work, so I'll try if I can make the arduino command line tool work for ScouseTom at least on my own machine!

Another thing I tried was Arduino Ino, which is not supposed to open any windows, but it's so outdated... It doesn't look for the necessary config files (like boards.txt) in the right places, because the folder structure has changed in the latest Arduino versions. After some hacking, if finds some of the files it needs, but then can't parse them, because their format has also changed since Ino was developed. This takes more time to hack, and makes me suspect there'll be more problems popping up even if I can fix this one. So I won't waste more time on it.

Last hope is bii hive. See a video of how it's run here and some info here. Even more info here.

Sigh.

[raquelalegre]

Bii hive was presenting itself as the very best option, because it was easy, command line build and upload worked well, plus it also handled dependencies, and then it turns out it doesn't work for Arduino Due, it only supports the following:

Enter board (/o list supported options): /o
Available options:
--------------------------
  LilyPadUSB
  atmega168
  atmega328
  atmega8
  bt
  bt328
  diecimila
  esplora
  ethernet
  fio
  leonardo
  lilypad
  lilypad328
  mega
  mega2560
  micro
  mini
  mini328
  nano
  nano328
  pro
  pro328
  pro5v
  pro5v328
  robotControl
  robotMotor
  uno
  yun
  zum

Any chance I'm wrong and you use some of the listed Arduino boards instead?

[Jimbles]

Hi Raquel!

The Serial1 bugs are because you need to tell it that it is an Arduino Due - the serial1 library is for Arduino Due. Its likely you have to pass more things to the cmd line to make it work. Sadly a lot of the code only works on Arduino Due as I had to use low level commands (all those undocumented ones we spoke about)

This is irrirating! Why the f- does it need to open an IDE window?

[Jimbles]

there is a bit in the biicode description which describes how to use the yun http://docs.biicode.com/arduino/howto/arduino-yun.html
The "Yun" was in a similar "beta" stage of development as the "Due" for a long time, is a bugger in a similar sense. So maybe this could be altered to work with the Due?

The Xvnc sounds like something that would be useful though, people must test Guis on jenkins?

[raquelalegre]

Hiya,

I've been working on this and there is some progress, plus more ideas to try stuff, although I'm not done yet:

• I figured out the command args needed for Arduino's command line utility to know we are dealing with Arduino due. This works

  arduino --verify /full/path/to/ScouseTom_Control.ino

  ONLY if you manually select beforehand in the Arduino IDE Tools->Boards->Arduino Due (Programming Port).
  My intention was not to depend at all on the interaction with the GUI, so that no matter what board is selected, you could still verify Arduino Due code. The command in theory to do this would be:

  arduino --verify --board arduino:sam:due /full/path/to/ScouseTom_Control.ino

  However, I can't get this command to run and it returns this error. I've tried to fix it following the indications in that forum message, but another error pops up since it doesn't seem to be able to find <avr/io.h>, although it is there. Also, the way to "fix" the TWBW error message, limits your clock speed, which might be important to you. This is probably not the way to go. The least worse for now is to manually log in the Jenkins node where Arduino is installed and manually set the board to Arduino Due.

  I'd like to try a couple other things, since the command also takes a fourth argument for the board related to the microchip (I think), but I'm a bit clueless as to what values give to it, and it's better we see about that together. I also wanted to try it on your machine and see what happens, and have a look at your config files and see if there is a workaround that saves us fiddling manually with GUIs.

  And added problem here is that to install the Arduino Due board to the SDK, it also needs you to go in the IDE and do it manually. It'd be nice to automatise this somehow - challenging, but doable. Just not yet.

• biicode's developers are very active. I talked to them via their forum about one bug I found that won't let users install Arduino > 1.5 and they're looking into it, and also about the problem not listing Arduino Due as one of the boards they support. They said even if it's not listed, it does support Due, but to this moment, I haven't been able to make it understand it. it helps if I can plug one in my computer and hope for automatic recognition, so we'll try next day I'm there. If this works, it would be better for Jenkins, although not for you and other users, since it needs downloading extra stuff (it's very easy to install, though).

• My colleague Jens just made a Windows node work in Jenkins, so now we can start testing Windowsy stuff. I think Visual Micro might have a command line utility that works better than Arduino's, only not cross-platform obviously.

• Made some research on Platform IO - haven't got very far since there are other options, but I thought I'd just list it here since it might help at some point if everything else fails.

[raquelalegre]

I've been working mainly trying to set up Jenkins to run

arduino --verify /full/path/to/ScouseTom_Control.ino

I've created a new job here. Not sure you have access to this, @Jimbles?

The challenging thing about this is the need for Arduino to prompt windows even when using the command line. Our Jenkins Mac node is headless, so I found a workaround that I've been testing today. I installed this Jenkins plugin I mentioned earlier, then configured a new job to verify the Arduino code in this repo. Since the plugin is designed for Unix and I'm testing this on a Mac node, I had to create a wrapper and got to a stage where the plugin works when you type the commands directly in the Mac node, but won't work when Jenkins is executing them, which is very annoying.

I'll keep on working on this on Friday. Chances are one of the windowless solutions works tomorrow and I don't need to do this. There's also the option to do everything on one of the Unix nodes, since the plugin was built for that, but I'll have to ask my colleagues what this implies.

See you tomorrow!

[Jimbles]

Hi Raquel,

That link doesnt work for me sadly, the connection times out. Is this the thing I need tot be able to connect to in order to make the Arduino Traffic light system? haha

Im sorry this is proving such a hassle, bloody arduino!

James

[raquelalegre]

Hi,

Just to keep track of what we just said, you'll have access to the production Jenkins server to see your jobs once someone grants permission - need to find out how this works :-)

So the link to the production Jenkins server is this.

[raquelalegre]

I've just given permissions to you, @markusjehl, @keydawg, @zhouzhouforever and @mayofaulkner to log in the production Jenkins server.

Please, let me know if you all have access now.

[raquelalegre]

Some progress finally happened!

I was about to abandon the idea of testing the compilation of Arduino's firmware for ScouseTom on Monday when I tried one last thing and it worked! It's PlatformIO, mentioned last on my list of options above. Instructions are quite simple. The commands to run are:

platformio init --board=due
platformio run

The project needs to be configured in a certain way for this to work, though. This is the preparation that is being run in the Jenkins job at the moment:

cd src/arduino/ScouseTom_Control
mkdir src lib
mv *.ino *.h src/ 
cp ../../../config/arduino/platformio.ini .
platformio run    

There is a new job in Jenkins I've configured that you will be able to see working once my colleagues who manage the production Jenkins approve my changes and install the necessary libraries. This will probably be ready by the end of this week.

While fiddling with Jenkins, I've also tidied up the jobs we have so far, so you can see three new jobs in Jenkins:

• The Head-Tanks job doesn't work yet, because there is nothing in the repo.
• The Reconstruction one is the test I had running before as EIT_imaging.
• EIT_imaging is still being shown there, but we can remove it unless you want to keep the history for some reason.
• The ScouseTom job is the one that'll do the Arduino stuff. It's working well in the staging Jenkins, so it should also work once it's approved in production later this week.

I'll make a summary of what I've gone through until I found this solution, in case it helps in the future:

• The Arduino IDE command utility won't work in Jenkins since it always has to prompt a window and the Mac node I'm using to test it is headless. None of the workarounds I tried worked (Xvcn, x11vnc, etc). There was one solution left to try that consists on starting the node with Java Web Start.
• Arduino Ino is very outdated.
• biicode was presenting itself as the best option, but it won't work for SAM boards. See some of my adventures trying to solve/debug the problem here. The problem is related to the compiler, which is gcc-avr for AVR boards, which biicode understands, but gcc-arm-none-eabi for SAM boards like Arduino Due. I solved partially a problem in biicode, but another bigger problem came up. That problem would take too much of my time, and I had spent too much on debugging it already, so the biicode developers said they'd look into it.
• Visual Micro claims to have a command line utility. I checked it out, but if doesn't do the verification, just the upload once the firmware has been manually built from the IDE...
• gcc-arm-none-eabi as being run under the scenes by Arduino IDE was a good option, but required me to write a tool that'd prepare the ScouseTom code in a way the compiler understands, i.e.. putting all tidily together in a single file. Too hacky.
• PlatformIO, which I didn't consider initially as I had other options that looked better seems to be the best solution: cross-platform, updated, works on different boards, easy to use, easy to run, and does both verifying and uploading code, so you can use it too.