p.alex's dashboard

The DS1206 and the EM1000 both use the same IC, the T1000. According to the EM1000 specs, current capability is 10mA - as it is a CMOS device, sink and source capabilities will be the same.
BTW, in my projects I often use EM1000 I/O pins to drive status LEDs, no problem :)

Hello, Leandro!
I had that same problem too.

The sad fact is: the EM1000 doesn't run its code directly, all instructions have to decoded and executed by a Virtual Machine. This way, the system becomes more stable and controlable. The Vm takes care of all the details regarding sockets (sock), wireless (wln), serial ports (ser), etc, so programming becames much easier.

The disadvantage is that simpler instructions may take 1 to 2 orders of magnitude more time to execute, ie, 10 to 100 times slower!!!

More complex instructions, such as the ones regarding the sockets, take only a little more time to execute, no problem there.

The PIC executes its code directly, so a typical instruction in a 8-bit PIC @8MHz takes only 0.5us! Much less than the 186us you reported...

It's not a defect, it's a feature, with its pros and cons :-)

Sugestion: why not use an EM1000 and a PIC? The EM1000 takes care of the high-level processing (eg: Ethernet), the PIC takes care of the simplest but fastest signal processing (eg: pulse counting). These two together make a very powerful system! Think about it.

Good luck :-)

PS: A few years ago I had to count pulses from a motor encoder, with a PIC16F628. Running at 1400rpm, the pulses arrived to the PIC at 26KHz!!! The PIC handled it perfectly, running @4MHz from its internal crystal and consuming only about 50% of the available time - in a word, perfect!

Downloaded and installed version 2.20.2 beta:
worked OK, total link time now is 1-2 seconds :-)
(app size= 181KB, ram= 10KB, stack= 60B)

Thank you for your help!

Just one more hint:
1- When TIDE is (slooowly) linking, I exit TIDE
2- Then I press Ctrl-Alt-Del to enter Windows Task Manager
3- In the process list, "tlink.exe" is still running, using all available CPU time! CPU usage peaks at 100%
4- I click on "tlink.exe" and end the process: everything turns to normal! CPU usage returns to 5-10%

Is this normal???

Thanks, T-bone.
1- I downloaded the new version of TIDE, 2.20.1 and installed it.
2- Then I rebuild the whole project - compile times were normal, 1-2 seconds each file.
3- Unfortunately, link time remains ULTRA-SLOW, about 4-5 minutes (and growing...). FYI, application size= 181KB, stack size= 60 bytes

There must be a solution to this issue, today I had to fix a few bugs and each time I rebuilt I had to wait 5 minutes, instead of seconds!!! This is really annoying :-(

Hi Ezuk,

Thanks for the bug fix - it worked, so it seems. I uncommented the error causing lines and no error happened :)
However, you still haven't answered my questions about TIDE's limits - number of variables, number/size of types, sub/functions call depth, etc :(
I think that could be helpful - TIDE has such limits, hasn't it??? Or TIDE's perfomance is just limited by available RAM?

Thanks for the bugfix. Just one issue - the long linking times still remain, current version of our application takes 20 seconds to link. TIDE reports:

-> Application file size: 157824 bytes
-> Required variable memory (RAM) size: 10114 bytes
-> Stack size: 48 bytes

Is this time normal? Are executing too many nested sub/function calls?

*** Just among us, what was causing the "Internal Compiler Error"? I promise not to tell anyone... ***

Thanks.

One more clue:

My application calls this function once only. So, I commented the call and I copied the whole function code to the place where the call took place.
The result? It worked Ok - the application still has its own bugs, but TIDE compiled and linked everything perfectly.

Can this help?

Just a few more questions:

1- Is there a limit to the number of Functions, Subs, Types (structures), Variables, Arrays, Constants, etc, one can declare in a whole project - all modules and include files included? TIDE's manual doesn't mention these.

2- Is there a limit to the number of variables a Type can contain? idem

3- Is there a limit to the number of nested calls the program can execute? idem

4- In this same application we had a problem when the application grew - more or less at application size= 100KBytes and Stack size > 50 bytes - the linking time grew to more than 10 MINUTES!!! We had to duplicate code to avoid more levels of function/sub calls - a terrible way of coding!!! The linking time now is 20 seconds - not very good, but a lot better than 10 minutes! Smaller applications I developped link in almost no time - 1, 2 seconds maybe.

That's all.

Dear Ezuk,
Here's the offending portion of code, I marked the line with "-->"
(of course I remove that mark before compiling!)

...

Function OpenSky2_StrToCounters( CountersStr as string(sizeof(TOpenSky2_Counters)), byref CountData as TOpenSky2_Counters ) as ok_ng
dim i as byte

if len(CountersStr) <> sizeof(TOpenSky2_Counters) then
OpenSky2_StrToCounters = NG
exit function
end if
CountData.CardCap = asc4(left(CountersStr, 4))
CountData.CardIss = asc4(mid(CountersStr, 5,4))
CountData.CardLoad = asc4(mid(CountersStr, 9,4))
CountData.CardRej = asc4(mid(CountersStr, 13,4))
CountData.CardRet = asc4(mid(CountersStr, 17,4))
CountData.Receipts = asc4(mid(CountersStr, 21,4))
CountData.VouchCnt = asc4(mid(CountersStr, 25,4))
CountData.VouchVal = asc4(mid(CountersStr, 29,4))
for i= 0 to BILL_TYPES-1
--> CountData.BillStacker(1)= asc2(mid(CountersStr, i*2+33, 2))
next i
OpenSky2_StrToCounters = OK
end function

...

Notes:
* when compiling, the compiler crashes with the message "Internal Compiler Error"
* no linking took place
* when I comment the marked line, everything compiles and links perfectly
* FYI, this function extracts data from a string into a structure - a simple task
* asc4() is similar to asc() but works with a 4-char string - fully tested
* sizeof() seems to be an undocumented Taiko function - we discovered it in the latest version of TIDE, works Ok
* just to be on the safe side, we replaced sizeof(...) with 42 - the actual size of the structure - same result
* TOpenSky2_Counters is a structure, as follows:

type TOpenSky2_Counters
BillStacker(BILL_TYPES+1) as word
CardIss as dword
CardRet as dword
CardCap as dword
CardRej as dword
CardLoad as dword
Receipts as dword
VouchCnt as dword
VouchVal as dword
end type

* BILL_TYPES equals 4, I replaced BILL_TYPES+1 with 5, same result.
* I tried moving the offending line to the top of the function, same result
* A similar piece of code, placed in another module, produces no error.

Of course this is a very small piece of a large project, envolving a few modules and libraries currently, the size of the compiled binary is 154880 bytes - pretty good.

See what you can do with these clues.
Thank you.

Very nice indeed :)
And the fact you used 'pre-cooked' libraries is very interesting, it means we can make it too. i'll give it a look, thanks!

I think other users will be interested in a quick and dirty browser interface, for easy device setup and configuration. Like someone said, the browser is the UI of the future!

Hello! I had that problem before. The solution was to hard-code the parameters into the application itself - using a Resource Text File.

I inserted a 10-char string as a header for the parameters data. Every time I change version, I change the header to current date+time "YYMMDDhhmm".
When the application runs, it checks if it the parameters in EEPROM need updating or not: if the string in EEPROM is different, write the new string and file parameters into EEPROM, otherwise just read them.

It worked for me :)

Hi, everybody!
Here's a bonus to you: the FD object help file draft!
(not complete, but a very good advance):
Get it at http://robalo.net/files/fd_help.htm

Now my project is moving again... :)

Hi, everybody!
The support team sent me an HTML file with the FD object help!
(not complete but almost... :)

Why don't they post it in the Tibbo Knowledge Base?
It sure would save us a lot of time and work!