**** BEGIN LOGGING AT Thu Jan 14 02:59:57 2010 Jan 14 06:18:21 holtmann: So I managed to get 4 AT ports on the Telit board, looks like straight forward AT modem with almost calypso like call handling Jan 14 06:18:51 holtmann: Supposedly it supports CMUX too, but can't make that work Jan 14 06:19:02 That would be nice. Jan 14 06:19:36 holtmann: I'm giving up on that, it is listed in the AT command spec but simply returns error Jan 14 06:20:32 Once I get a 2.5mm headset I can even test audio ;) Jan 14 06:33:19 Nice. Jan 14 10:19:19 I was thinking of testing ofono this month... I'm guessing I'll have to get new HW though: Jan 14 10:19:36 What I now have is a "Huawei E620" integrated in my Eee. dmesg mentions loading the Option driver... Jan 14 10:20:41 any comments on whether I should try that or just buy something already supported (and if so, what)? Jan 14 12:28:20 well, the huawei plugin does does seem to work at least to some degree (just didn't notice the udev dependency first) Jan 14 12:29:01 I see that the modem doesn't return cellid or lac in NetworkRegistration properties Jan 14 12:29:31 is that a missing feature in ofono or just a problem with the plugin/hardware? Jan 14 12:30:32 I mean LocationAreaCode and CellId in NetworkRegistration interface Jan 14 13:02:59 it seems the at result does not include lac or cellid, there's only mode and status Jan 14 15:07:09 ok, I think I found a bug in drivers/atmodem/atutil.c:at_util_parse_reg* Jan 14 15:08:15 lac and ci are not quoted strings (not from my Huawei anyway :)) but those funcs treat them as they were Jan 14 15:44:56 jku_: That is not a "bug". The spec does mandate that lac and ci are quoted Jan 14 15:45:44 jku_: You can create a new quirk specifically for the Huawei modems and try to parse the unquoted lac/ci when the quirk is set Jan 14 15:46:00 denkenz, ok Jan 14 15:46:22 jku_: For an example grep for VENDOR in plugins/ and drivers/ Jan 14 15:46:37 thanks Jan 15 00:36:08 denkenz: modem_path is used to record real modem path, like '/atgen0' Jan 15 00:46:20 denkenz: in received_data, i am reading whole buffer and then check s3 terminator. do you want to check it in the while loop? then you should parse the whole buffer at all, not just the buffer in single while loop. Jan 15 01:45:15 zhenhua: modem_path is irrelevant to at_server Jan 15 01:47:04 denkenz: i can get rid of it first. Jan 15 01:47:12 not sure if we still need it. Jan 15 01:47:44 denkenz: received_data is the major part i want to discuss Jan 15 01:50:49 zhenhua: Problem is the whole buffer might contain 2 commands Jan 15 01:51:02 zhenhua: E.g. AT+BAR\rAT+FOO\r Jan 15 01:53:11 right Jan 15 01:53:37 then i can parse them when i received the first \r Jan 15 01:54:09 yes, but you don't as far as I can tell Jan 15 01:55:08 i don't catch u yet. are u mean i will lose AT+FOO\r? Jan 15 01:56:25 You will not handle it until the next time something comes in from the other side Jan 15 01:56:37 ok, let me think about your suggestion, what if i got "AT+" in the first loop Jan 15 01:56:47 and then got "BAR\r" in the second loop Jan 15 01:57:04 No no no Jan 15 01:57:04 and the write ptr will point to BAR\r Jan 15 01:57:25 You strchr for S3 once Jan 15 01:57:32 You should do it in a loop Jan 15 01:58:11 once we have S3, then we write buffer and advacne? Jan 15 02:00:14 > + if (strchr((char *) total_buf, v250->s3)) { Jan 15 02:00:15 > + parse_buffer(server, total_len); Jan 15 02:00:16 > + Jan 15 02:00:17 > + total_len = 0; Jan 15 02:00:19 > + } Jan 15 02:00:27 You have a buffer that possibly contains AT+FOO\rAT+BAR\r Jan 15 02:00:44 You check \r once, so you process AT+FOO\r, but don't process AT+BAR Jan 15 02:01:42 ok. i will fix it Jan 15 02:02:28 the problem is when the have write ptr advance Jan 15 02:03:05 Also readup on how a circular buffer actually works Jan 15 02:03:41 Your code will go past the buffer edge in certain circumstances Jan 15 02:04:43 i have realized that but not quite sure Jan 15 02:05:18 because the buffer might warp around Jan 15 02:05:25 The way I did it is efficient but bloody hard to understand Jan 15 02:05:35 I probably couldn't explain it now :P Jan 15 02:07:08 actually we also can use an simple array like bluez does Jan 15 02:07:31 but i don't, rather use your ring buffer and make me headache Jan 15 02:07:51 http://en.wikipedia.org/wiki/Circular_buffer Jan 15 02:10:17 unsigned char *total_buf = ring_buffer_write_ptr(server->buf) Jan 15 02:12:24 Yeah, you want to be using ring_buffer_read_ptr and checking for wrap Jan 15 02:13:48 Then don't use strchr, but instead find s3 char directly knowing the bounds Jan 15 02:13:50 i am really confused about that part Jan 15 02:13:59 use while loop? Jan 15 02:14:12 Yes Jan 15 02:14:30 what if no s3 in recieved_data Jan 15 02:15:01 Then wait until more data arrives Jan 15 02:15:23 check logic in new_bytes in gatchat.c Jan 15 02:15:55 i read them already, read them again today... Jan 15 02:16:35 Heh Jan 15 02:16:57 Basic gist is, you know how many bytes you have in the ring buffer for reading Jan 15 02:17:16 You process it in two parts Jan 15 02:17:26 You grab the chunk until the buffer's end Jan 15 02:17:41 And if the buffer wraps, the chunk at the buffer's beginning Jan 15 02:18:09 which chunk is at beggining? Jan 15 02:18:37 oh, the last read one is at the beginning Jan 15 02:18:44 Yep Jan 15 02:19:00 anyway, i will try it then Jan 15 02:19:01 The concept is pretty simple actually, think on it some more Jan 15 02:19:09 i know Jan 15 02:20:15 i plan to add one server_watcher_destroy_notify Jan 15 02:20:58 but i don't see at_chat g_io_channel_shutdown(io) in cleanup, why? Jan 15 02:21:16 because it already shutdowned? Jan 15 02:21:42 in g_at_server_shutdown Jan 15 02:21:51 shall i remove below code? Jan 15 02:21:56 > + if (server->server_io) { Jan 15 02:21:56 > + g_io_channel_shutdown(server->server_io, FALSE, NULL); Jan 15 02:21:56 > + g_io_channel_unref(server->server_io); Jan 15 02:21:56 > + server->server_io = NULL; Jan 15 02:21:56 > + } Jan 15 02:58:15 denkenz: the problem is not whether parse_buffer in loop or not, the problem is strchr. **** ENDING LOGGING AT Fri Jan 15 02:59:57 2010