IDE Limitations

I have around 52K of embedded C code I would like to convert to Squirrel.  The goal is to dramatically reduce the hardware footprint I’m dealing with and get away from arrays and strings in C (damn them).  I have been working through the examples, modify them for my own purposes and the IDE appears to be, to put it lightly, very light.  So, for instance, I don’t get any compilation errors despite code being egregiously incorrect.  Am I missing something here?

On a more strategic level, working with the online development environment over the last week raises many questions.  For instance, it appears that the only debugging support that there will be (assuming I get my compilation problems fixed) is printing out error messages to the system logs.  This is tolerable for short programs but becomes onerous for larger programs. Code reuse is also a big question for me.  If I successfully build code enabling me to work with a third party IoT service (e.g., Nimbits), it is unclear to me how I would reuse this beyond copying & pasting and the inherent evils therein. A corrolary to reuse is integrated version control and code sharing which are missing.  I use Github for this today and in the absence of some sort of integration the Imp team will have to reproduce some subset of this functionality.

So what does the flight path look like here?

I don’t believe the Imp is designed with large embedded applications in mind. For a start 52K of C converted to Squirrel almost certainly won’t fit right now (although this will change when code execution from flash is implemented).

There’s a lot still to come in the development environment. At the moment you won’t get any errors reported at all if you work on a code unit in isolation (you’re simply using a text editor). You’ll get errors if you enter the code from a node to which it is assigned. Syntax errors will show up under “errors” while run time faults will show up in the log. I know there’s work going on in this area.

Code control and reuse is another matter. The Imp guys pushed back even when I requested header support, for philosophical reasons which they may be willing to share and discuss. I suppose the perceptions may be different depending on whether you see the imp as something to run a few dozens lines of code, or hundreds/thousands of lines.  I’m quite sure they see it in the former sense right now, their big selling point to manufacturers being that there’s very little technical work required to integrate with a product. However the point at which they moved to Squirrel (Lua was used in early alpha releases) code development became a lot more object oriented and re-use of classes would seem to be a fairly fundamental requirement.

Fen Consultants, UK

Thanks for the response.  As for code size I had it in my head that the Imp had a hardware enabled byte code interpreter on it and that the server was streaming byte code to it and the Imp was streaming state changes streamed back to the server.

The source is compiled into byte code on the server and downloaded to the imp from where it executes (out of RAM). By all accounts Squirrel byte code is very space inefficient, and there’s only 128KB of RAM on the CPU which needs to hold the heap and stack for the OS as well as user code.

Better code density and execution from flash are in the works I hear.

Fen Consultants, UK

Part of the idea of being cloud-based and always-connected, is that if you’ve got anything really complicated to do, you can do it at the server end. If your code does anything much more than reading sensors and telling the server about it, or activating outputs when told to by the server, then perhaps that functionality doesn’t belong at the imp end.

Version control of Squirrel programs is something we know we’re going to need to do better than at present. We have some ideas in that area but no firm plans as yet.


What about the idea of producing a Squirrel library that people could use in the SQDEV Eclipse plugin - -

This would provide users with a debugger and development environment they are likely comfortable with.  Next enable users to provide a link to a file in GitHub.  Now you have a kick-butt version control system and you support code sharing among your user community.  You could support this further with a registry where users could post code that they find particularly useful.


The IDE is being significantly upgraded, but as Rob says - 52k of C code is not the idea here at all. If you have heavyweight stuff to do, you do it server-side, not imp-side, where power and space are at a premium.

Github integration in some way is on the wishlist, but we’ve not worked out the most convincing way to implement it yet.

Thanks for the reply.  There is a hole in my understanding on what “the server side” is.  One of the most attractive ideas of the Imp to me (aside from the ability to punch through WEP) is that I could move large swaths of cantankerous C code to the Imp server where I could instead use a much more powerful and safer Object Oriented language (aka, Squirrel).  I kept looking for a place where I could write my own code that would execute exclusively on the server and fed data from Imps, effectively private vimps.  Instead I found a static list of public vimps and the code I do write is relegated to an Imp.  I assume this will change, yes?  Alternatively I might just be missing something.

Yes, this will change. You will be able to write vimps yourself - it’s just that’s not quite ready yet, hence the limited menu.