i have several parsers I've written using Flex/Bison, but don't know how to go about integrating them into an Arduino application, or even it that's practical to do. They do build and run just fine with gcc on a PC, so I'm hoping they will compile with the Arduino compiler as well.
Has anyone done this yet?
Regards,
Ray L.
Well, it seems far from hopeless. It does compile with the Arduino compiler. There are a handful of undefined symbols, most should be straight-forward to work around, as most/all are not needed in my application:
_exit
_sbrk
_isatty
_write
_close
_lseek
_read
_fstat
Regards,
Ray L.
Those are mainly functions for file access. The Arduino does not have the 'stdio.h' and not the functions for file access like on a computer. If you can translate them to the SD library, it might work.
There is a "iostream.h" for the Arduino, would that help ?
You didn't tell which FLEX/BISON library or code you are using.
Koepel:
Those are mainly functions for file access. The Arduino does not have the 'stdio.h' and not the functions for file access like on a computer. If you can translate them to the SD library, it might work.
There is a "iostream.h" for the Arduino, would that help ?
You didn't tell which FLEX/BISON library or code you are using.
I don't need file I/O at all, since the input will be coming from other devices over serial or Ethernet. So, I expect all those functions can be simply stubbed out.
What do you mean "which FLEX/BISON"? I'm using WinFlex-Bison, but the version should not matter - the output is the same regardless, and follows the model created by lex/yacc.
Regards,
Ray L.
I was wondering what it is and why those file access functions are used.
You are using this one : Win flex-bison download | SourceForge.net ?
It uses the console and file a lot. Perhaps only the macros for those needs to be changed.
Koepel:
I was wondering what it is and why those file access functions are used.
You are using this one : Win flex-bison download | SourceForge.net ?
It uses the console and file a lot. Perhaps only the macros for those needs to be changed.
Yes, that's exactly what I'm thinking. Those functions cannot be getting called in my code, since I'm over-riding the file input and passing in a string instead. It is using stdout, but I can easily re-direct that as well. In fact, perhaps once I do that, those references will go away on their own...
Regards,
Ray L.
Define serial as stdin and stdout, isn't that how it was when we worked on terminals?
I'd be interested on how much RAM and flash the generated code uses and whether or not dynamic allocation is part of running it.
GoForSmoke:
Define serial as stdin and stdout, isn't that how it was when we worked on terminals?I'd be interested on how much RAM and flash the generated code uses and whether or not dynamic allocation is part of running it.
Serial is not type FILE *....
Worst case, I just have to swap out or modify a few of the I/O interface functions, which seem to all be implemented in macros.
The parser is large-ish - about 90K for the PC executable. I would guess adding more syntax would not grow that terribly much.
I'm running on a Due, with plenty of unused FLASH and RAM, so size is not an major issue. My application is using a bit less than half of the 512K of FLASH, and only about 30K of the 96K RAM. Dynamic allocation also does not worry me, as long as it cleans up after itself (which is easy enough to verify). My code already does tons of dynamic allocation within its messaging system, and it's not a problem as long as you're rigorous about cleaning up after yourself.
Regards,
Ray L.
GoForSmoke:
Define serial as stdin and stdout, isn't that how it was when we worked on terminals?I'd be interested on how much RAM and flash the generated code uses and whether or not dynamic allocation is part of running it.
Serial is not type FILE *....
Worst case, I just have to swap out or modify a few of the I/O interface functions, which seem to all be implemented in macros.
The parser is large-ish - about 90K for the PC executable. I would guess adding more syntax would not grow that terribly much.
I'm running on a Due, with plenty of unused FLASH and RAM, so size is not an major issue. My application is using a bit less than half of the 512K of FLASH, and only about 30K of the 96K RAM. Dynamic allocation also does not worry me, as long as it cleans up after itself (which is easy enough to verify). My code already does tons of dynamic allocation within its messaging system, and it's not a problem as long as you're rigorous about cleaning up after yourself. The ridiculous ease of changing/extending the "language" is the major selling point. I have the first parser, which understands about 20 command sequences, each consisting of 3-10 tokens. It took well under an hour to write the Flex/Bison code to generate the parser, and it worked perfectly pretty much on the first try. Even a very rudimentary parser would've taken FAR longer to hand-code.
Regards,
Ray L.
#define FILE StreamDoes that fix it?
MorganS:
#define FILE StreamDoes that fix it?
Not a chance....
Regards,
Ray L.
Actually, I thought Due used newlib, which does implement a lot of stdio.h?
It may be one of those things where you have to provide the low-level primitives to match whatever device your filesystem actually resides on...