Because of a significant "brain trust" [British: a group of experts who give impromptu answers to questions in front of an audience or on the radio; US: a group of experts appointed to advise a government or politician; Urban Dict: a group of smart advisors. Used sarcastically to refer to a bunch of decision makers who are not wise] existing behind the retro scene (currently resting, waiting on pic32mzda), I dare myself to ask for a help of any kind (except pointing me to K&R book ).

I have about 2kB free space and looking for an "femto readline parser" called from my C source (not from an OS), which will:

1. read a line with a command and up to say 4 params2. command - up to 3 chars like: ou, in, pr, lop; number of commands will be small3. params - up to 4 numbers4. numbers - hex32bit ie xDEADBEAF or shorter, decimal signed 32bit (cannot use scanf)5. I will then, based on the command, make some actions with params6. All I have is a function readchar(*buf, numberofchars) which reads numberofchars from uart into a char buf[], which does not help me much here, fortunately I can read 1 char too 7. cannot use heavy lib functions as they do not fit.

You can hardly circumnavigate around the globe with that precision, but it is fast..

Attachment:

Errors Cordic 16bit on Xilinx.PNG [ 101.07 KiB | Viewed 15960 times ]

I must admit the Xilinx'es tools are so easy to use today.. And it simply works.I wish the bigger chips (Artix, Kintex) will get available cheap soon Retrobsd/LiteBSD on Spartan6 SLX9 is still doable I guess - uBlaze + MMU + SDRAM/DDR,but the chip will be most probably full.. Btw, do we have a uBlaze simulator handy

You want to do it with a simple FSM instead of manipulating a buffer. I'm sure that would be simpler and use less code than string manipulation.

If you have specific characters that each byte of a command can be you could then pack them into a byte or word.

For instance:

"o" in the first byte is 0x0001"i" in the first byte is 0x0002"t" in the first byte is 0x0003"l" in the first byte is 0x0004

"u" in the second byte is 0x0010"n" in the second byte is 0x0020"m" in the second byte is 0x0030"o" in the second byte is 0x0040

"p" in the third byte is 0x0100

You then have numeric commands of

ou = 0x0011in = 0x0022tm = 0x0033lop = 0x0144

And unlisted, but potential:

to = 0x0034im = 0x0023top = 0x0143

Simpler if you can restrict it all to exactly 2 character commands. That would reduce your processing by a third.

Just read a character at a time and decide what to do with that character depending on what has gone before (how many characters have been read). If it's a space or EOL then do whatever the command tells you. Otherwise you place the numeric equivalent for the character (a small LUT or switch statement) in the right location in the word (just OR it).

The reason for working numerically like that is so that the final decision is:

if (command == 0x11) { .. whatever ... }

instead of complex things like:

if (!strcmp(cmd, "ou")) { ... whatever ...}

or:

if ((cmd[0] == 'o') && (cmd[1] == 'u')) { ... whatever ...}

Processing the numbers can be done in a similar way by reading each character and multiplying by powers of the selected base and adding them to the running total for that number. Multiply itself can be a little costly, so if you can force just hexadecimal it gets much lighter, since you can just use left shifts and ORs for building up the finished number.

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Interesting, thanks. I run currently single core, but plan 2 or more.There is 8/16/32/64kB per core selectable (mem = rom and ram), total 64kB in my LX9.I target 16kB, now I am at 27kB with the code, it works as I set core mem to 32kB.Without the splitter and conversions (simple atoi and long long mul/div/add/sub - mimicking float range) my code is about 13kB.Still the big chunk there (in 13kB) is the special xil_printf() which is quite large even it is stripped down.20y back I packed something similar with single precison fp into a 16f88, but that was long time back I do not want mess with that mcu inside too much as that is not my goal, I want use it as a simple connectivity towards internal blackboxes (ie the above cordic box) and other fabric I simply bitbang via a configurable 4x input and 4x output ports (each of them 1..32bit wide). It works..

My first PIC experience was with the 16F84A since that is all that Maplins had in stock locally

I had to bit-bang all my UART comms, and I only had 1024 words of flash and 68 bytes of RAM to do it in

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

Hehe, 16f88 was a big advanced machine. My first pic was the basic stamp - the smallest one with a header at single side, it cost me 35E. 15y before basic stamp I built an 8085 system, it cost me less (btw parts purchased in London, '82, the catalogues at that time were aprox 10cm long adds with a list of 20 components in electronics magazines).

25 bytes of RAM is a bit excessive, isn't it? Couldn't you make do with a RAM-less chip and just use the CPU's registers?

_________________Why not visit my shop? http://majenko.co.uk/catalogUniversal IDE: http://uecide.org"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum