ezuk's dashboard

Edward - I see what you're saying, and how it can be frustrating. It's not because we've got our priorities backwards -- it's because it's different parts of the company doing these things. We know this is a problem, and we're working to find a better solution so that it doesn't keep happening (i.e, firmware is released and docs lag).

Tony - we may not have this exact thing, but we've got something really pretty close with the AggreGate Agent implementation. Did you play with it? Try it at http://aggregate.tibbo.com/agg-downlo....

Just get the the Agent itself, you don't need the whole AggreGate solution. Check out the code, see if it's a good starting point for what you need.

Also, I don't know if you tried this new demo I wrote about above, but it actually works with our standard DS Manager. It's got all the Tibbo BASIC code you need for making your device visible to DS Manager and exposing settings.

Serial Upload.

Connect it via serial port. Then upgrade is using the serial tab of the DS Manager.

http://docs.tibbo.com/soism/dsm_mode_...

No worries, it happens to the best of us. ;)

Did you try a serial upload?

I don't know what exact EM1202 board you've got, but it should have a "Setup" button.

Disconnect the board from the power source. Connect it via a serial cable to your computer. Run DS Manager, go to the "Serial" tab and try uploading firmware - it will tell you what to do (you select the correct firmware file, and start the EM1202 board while pressing the "setup" button on the board itself).

The best complete application demo, in my view, would be a complete emulator of the non-Taiko firmware (for the EM202, for example). One that can be setup via the DS Manager just like the regular firmware. (If this was done, there would be no need for separate firmware for normal/Taiko use. All units would come preloaded with Taiko and that default application.)

Then, each of us can add the features we want that Tibbo won't add for us (even after repeated nagging).

For example, I want XON/XOFF control in the data steam (since many existing hardware didn't have provision for hardware flow control), but I'm not willing to become a Taiko expert just to add that little functionality to the original firmware's otherwise good behavior!

As another example, I would like to add the ability to retrieve time from a time server and set my access control's clock automatically, during times of inactivity or at fixed intervals.

Now, you've been given some more ideas to work on.

The demo may be great, but I think the time would have been better spent updating the documents so that people could actually use some of these new objects like the LCD, KP, FD etc etc. Every time I ask when the docs will be released I get told it will be in a few days... that was months ago!

Well, that's a little discouraging. I'm pretty interested in the EM1000, but don't want to have to reinstall XP --- I wiped it off my laptop a long time ago. But if I have to, I have to. Guess I'll order an EM1202 starter kit, hoping it saves me development time. It has been 3 months since the last comment; I'll let you know if I can run TIDE with WINE under Ubuntu 8.04. – Tom Herrmann, on July 02, 2008 05:09

Perhaps, when I get my next unit I will be able to check that one out. I will post my results once I have worked through that.

yea, I did run it out of the TIDE, I even had the project closed (not that this should matter once you are not using the debug mode). I did even disconnect for a prolonged period of time before reconnecting the cables and power back on. Maybe it is something with that particular module?

I found that the code does run fine when running in the TIBBO IDE, but has trouble stand alone. Did you drop out of the IDE, power down the unit, power back up again - say 10 seconds later, then try opening the port with whatever application requires the serial port?

I am running ...
TiOS code version ...2.05.01
TIDE ... 2.6.22 Beta Built on March 26th 2008, 18.11.16

I will be getting another unit in the next few days. I will run the same code in that and do another test on the bench. I get around the problem for now by sending the restart comand over the net whenever I lose comms, but I would like to get to the bottom of this one if I can.

Thanks in advance

I just tried your code here David, and I can run it fine? What version of TIDE and TiOS firmware are you using? It shouldn't matter but might be something to look into. Do try the latest to see if the problem goes away.

Here you go - I am basically using your "net_to_ser_1.tpr" project with a ser.rxclear, and a sock.rxclear just before data is grabbed from buffers.

'***********************************************************************************************************
' THE SIMPLEST DEVICE SERVER (WITHOUT ACTIVE OPENS, WITHOUT BUFFER REDIRECTION)
'***********************************************************************************************************
'This project can run on EM202 and EM1000 platforms. Select platfomr in Project->Settings. If your
'platform is EM1000 then uncomment the code below marked as "EM1000 ONLY". After that do
'Project->Rebuild All.
'***********************************************************************************************************

' This project implements the simplest "serial device server" possible. There is a single TCP
'connection (passive opens only). Once this connection is established, whatever is received
'through TCP is sent out via the serial port and vice versa.
'
' ATTENTION! READ THE COMMENTS IN CODE! YOU MIGHT NEED TO CHANGE THE PROGRAM! For example,
'you may need to set correct IP address, baudrate, etc.

'=============================================================
sub on_sys_init
'This event is always generated first. We use it to setup everything- a socket for TCP
'connection, serial port, etc.
'ATTENTION! Read this code- you might need to do some parameter changes!

dim w as word
dim debug1 as word

'---------- EM1000 ONLY (uncomment if you are using EM1000) ----------

'io.num=PL_IO_NUM_0 'RTS line of serial port 0
'io.enabled=YES 'we configure this line as output

'---------------------------------------------------------------------

net.ip="192.168.1.95" '<<<<<<<<<< IP-address of this device. CHANGE AS NEEDED!

'Next, we request memory for the only socket we need. This is a simple allocation-
'we ASSUME that we have enough memory for what we request.

sock.num=0
sock.rxbuffrq(4) 'we ask for 4*256-16=1008 bytes for the RX buffer of socket 0
sock.txbuffrq(4) 'we ask for 4*256-16=1008 bytes for the TX buffer of socket 0

'Now, we request memory for the serial port. This is a simple allocation- we ASSUME
'that we have enough memory for what we request.

sock.num=0 'Good practice (but, actually, redundant)
ser.rxbuffrq(4) 'we ask for 4*256-16=1008 bytes for the RX buffer of the serial port
ser.txbuffrq(4) 'we ask for 4*256-16=1008 bytes for the TX buffer of the serial port

sys.buffalloc 'And now ACTUAL buffer memory allocation

'We need to setup our socket for TCP/IP.

sock.num=0 'Good practice (but, actually, redundant)
sock.protocol=PL_SOCK_PROTOCOL_TCP 'We set TCP
sock.localportlist="1001" '<<<<<<<<<< Listening ports. CHANGE AS NEEDED!
sock.inconmode = PL_SOCK_INCONMODE_ANY_IP_ANY_PORT 'Accept connection from any host

'Serial port also needs setup (we leave parity and bits/word at default- NO and 8)

ser.num=0 'Good practice (but, actually, redundant)
ser.flowcontrol=DISABLED '<<<<<<<<<< Flow control ON. CHANGE AS NEEDED!
ser.baudrate=ser.div9600 '/4 = We want to run at 38400bps
ser.bits = PL_SER_BB_7
ser.parity = PL_SER_PR_EVEN
ser.enabled=YES 'The serial port is now ON!

'It is nice when your device provides some visual status of what it is doing.
'After we boot, let's play a "power-on" pattern on the LEDs!
pat.play("B-B-B------",YES) 'Blink Red & Green 3 times. <<<<<<<<<< CHANGE IF YOU WISH!
end sub

'=============================================================
sub on_sock_data_arrival
'This event is generated whenever there is an incoming TCP data to process.
'All arriving TCP data is sent out through the serial port.

'You may feel that the code below is a bit cryptic but, actually, it is very simple!
'We use sock.getdata() to extract a portion of data from the socket's RX buffer. We plan
'to put this data into the TX buffer of the serial port. Therefore, we should be mindful
'of the free space in the TX buffer. We only extract as much data from the RX buffer
'of the socket as available free space in the TX buffer of the serial port. This is achieved
'through the use of the ser.txfree property. The ser.setdata() method stores the data into
'the TX buffer of the serial port.

ser.rxclear
ser.setdata(sock.getdata(ser.txfree))
ser.send

end sub

'=============================================================
sub on_ser_data_arrival
'This event is generated whenever there is an incoming serial data to process.
'All arriving TCP data is sent out through the TCP connection.

'The code below is like the code for the on_sock_data_arrival event (see above), only in
'reverse. It copies the data from the RX buffer of the serial port and into the TX buffer
'of the socket.

sock.rxclear
sock.setdata(ser.getdata(sock.txfree))
sock.send

end sub

'=============================================================
sub on_sock_event(newstate as pl_sock_state,newstatesimple as pl_sock_state_simple)
'This event is generated whenever socket status changes. We are only using a single socket (#0) so
'we can be sure that this event is related to it.

'Here is what we do: we don't check the socket state here, we just play a very short
'LED pattern which momentarily dims bot Red and Green LEDs. When this pattern is done playing
'the on_pat event will be generated and we will check socket state there!

pat.play("-",YES)

end sub

'=============================================================
sub on_pat
'This event is generated each time previously loaded LED pattern has finished playing. We load
'new pattern basing on the current state of socket0 connection.

sock.num=0 'Good practice but also redundant for our project

'We just recognize 2 states: connected/not connected

if sock.statesimple=PL_SSTS_EST then
pat.play("GGGGGGGGGGGGGGGG",NO) 'Connection established- Green LED steadily on
else
pat.play("-------------G-G",NO) 'Connection is not established- Green LED double-blinks
end if

end sub

sub on_sock_inband()
' TODO: place "on_sock_inband" event handler code here...
end sub

I see...

I guess maybe writing Support directly would be a good idea for this one. Of course, you can leave it in the forum, but using Support directly would probably get you faster results.

If you do get this resolved, I would love to hear about it in the forum. :)

Hi David,

Sorry for not replying for so long - this got buried in my inbox.

Can you paste your code here?

Well, generally we will send this data more frequently, say every 30-50ms. One second interval is just for testing purposes only, to check 115200 baudrate.

I'm just wondering -- if you send just 100 bytes once every second, why do you have to use 115200 baud?

(Sorry I don't have any useful advice at the moment, but I just saw this in the forum and got curious...)

Seems like some sort of a firewall problem. Why wouldn't you get a reply to a simple ping? Must be a connectivity issue.

(And thus, of course, you can't see it in DS Manager... The computer can't reach it.)

Problem solved by a.babel. Supplied voltage was too low.

Great! Thanks for reporting, and well done! – ezuk, on June 19, 2008 06:45