Welcome, Guest. Please login or register.

Login with username, password and session length
ArdweeNET forum

 
Pages: [1]
  Print  
Author Topic: Protocol analyser software  (Read 8598 times)
0 Members and 1 Guest are viewing this topic.
captcha
Newbie
*
Posts: 7


View Profile
« on: January 30, 2011, 03:52:07 PM »

Hi Rob,

Great to see you've got the forum running. Makes it even easier to search through all the posts at once.

On 20 October 2010 12:56, Rob Gray wrote:
> I mean that the GUI should run on a PC/iPod/whatever
> (but not your application PC) and talk to either the MCU or a clever node to
> get the network information. So Java won’t have to run on an AVR. The reason
> I say "not your application PC" is that many systems won’t have one, and
> also test equipment should be independent of the thing it's testing. That's
> not to say you shouldn’t do it on yours as long as the code is portable and
> we can later move it to another device, obvious choice iPad/Pod I guess so
> you can have a handheld debugger as you described.

I was already looking at JVM's and embedded hardware like Gumstix and FriendlyARM. Great platforms to have a play with one day but perhaps a bit too much sidetracking for now..

My next step will still be to write a java application that interfaces to the serial port and display incoming data inside a window. When that's done we can have a closer look at what kind of values it should pick up from the network and how to interact with the MCU and (possibly self-detect) any existing nodes on the bus.

Sorry for not yet knowing the full busnet protocol specs, but what kind of handshaking is there between nodes? I read on one of your pages that one node could send out serial and another node puts it on an lcd. Where can I find the 'protocol header information' (if such a description exists)?

Cheers,
marcel
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #1 on: January 30, 2011, 03:53:09 PM »

Check out the Core Protocol manual (BUSnet-dg-protocol-v0-1.pdf)

Page 8 shows the frame format. An MCU will send a frame to a Node, the Node must respond immediately with a response frame, even it it's just an ACK.

Page 15+ shows some typical "transactions". A transaction can involve any number of frames but most typically 2, "do this" then "OK".

So a Node might send a "write" command to another node. The MCU fields this and passes in on (subject to security if enabled). The target Node gets the command and prints the value.

Also there's the Sequence diagram quick reference (BUSnet-qr-seq-diagrams-v0-1.pdf)

BTW, the more questions the better it forces me to think about things. I've been doing this alone for some time now and am too close to see many errors I'm sure.
Logged

Rob, aka the GRAYnomad
captcha
Newbie
*
Posts: 7


View Profile
« Reply #2 on: January 30, 2011, 03:53:58 PM »

Hi Rob,

I had to post the java app via email as the forum didn't allow me to post '.jar' files and there's probably a very good reason for that.

The app displays values that it reads from a CSV file. Since the busnet protocol is serial/sequential is will be a similar method to listen for incoming data on the serial port and unravel the frames. This way you can see which packets were sent down the line, what is the included data and so forth. Another option that I provided a button for (but doesn't work yet) is a record function. Here you can record busnet packets into an ascii file for later debugging or replaying what was sent.

Apart from reading frames and displaying their contents the software must also have another feature that works on a lower level. This will monitor raw 'marks' and 'spaces' layed out against a time scale to see if the frames meet the specification of the protocol. Things like trigger on a rising edge or so should be incorporated amongst the functions of the software. Again, here you want to be able to record to a logfile for later debugging.

Am I on the right track?

Cheers,
marcel
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #3 on: January 30, 2011, 03:55:35 PM »

Ok I get it.

All you said is bang on.

Quote
the software must also have another feature that works on a lower level. This will monitor raw 'marks' and 'spaces' layed out against a time scale to see if the frames meet the specification of the protocol.

An inbuilt poor-man's logic analyser, sounds good. Can the PC read logic levels from the USB port via an FTDI chip or something. If not then maybe a dedicated AVR to grab the data and package it for the PC. This would need timestamping etc as well. One thing that makes a protocol analyser of this type easier than a logic analyser (at the hardware level anyway) is, as you say, we're just looking at sequential bytes. I started a spec for an analyser chip.

http://www.robgray.com/busnet/documentation/docs/BUSnet-tm-bdt-v0-3.pdf

Quote
Things like trigger on a rising edge or so should be incorporated amongst the functions of the software.


Also, and probably more inportant in a protocol analyser, triggering on frame types, addresses, data types, etc.
Logged

Rob, aka the GRAYnomad
captcha
Newbie
*
Posts: 7


View Profile
« Reply #4 on: January 30, 2011, 04:00:17 PM »

Rob,

Would it be feasible to have an MCU in between the pc running the protocol analyser software and the busnet signals? I was thinking that if for some reason I can't get low level access under java I might make a small board that listens for busnet signals and then sends out a response over (faster) serial to the listening pc. Would that be fast enough? 115200 is 24x faster than the 4800 that BUSnet runs on. Would it have to be that fast or is 10x faster enough (transmitting one bit state as a new serial character (including start and stop bits) would take 10 times as long)? Hopefully I'm explaining this properly.

I don't have the experience to confirm that this would work but it's a question that came up at some stage whilst programming the serial part of the software over the weekend.

Personally I'd rather have it fully in software though.
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #5 on: January 30, 2011, 04:01:37 PM »

I think it won't be possible to get the control required with Java and 100 levels of Windows crap between the program and the data line. So I think the front end for the PA has to be a piece of hardware and probably written in ASM (at least the low-level stuff). I have a rough design for this (using my Quub processor) but some prototyping could be done with an Arduino. I think the PC GUI has to be just that, a UI that sends commands to the PA and receives/stores/displays data from it.

The PA can filter and save bytes read from the line and data levels at slow rates (say 1mS but not the 209uS bit time, much as it would be neat there is no real need for high-speed LA in a protocol analyser as it's purpose is to debug code not hardware, if required I have a real LA), add time stamps and send the data to the PC. The PC can do what it's good at, displaying and saving the data. So on the average the PA would have to send 4-5 bytes to the PC for every byte read from the line, that should be easy.

I think my Quub would be good for this, but meanwhile a prototype could be done on an Arduino.

If this is the way we go then we have to design a simple protocol and data format for the PA and PC. Once this is done the two parts can be developed seperately.

Quote
Personally I'd rather have it fully in software though.

Yep, cheaper and easier, but not up to the real time requirements here (not from a PC anyway), it's still software, just on a different platform.
Logged

Rob, aka the GRAYnomad
garylcamp
Newbie
*
Posts: 10


View Profile WWW
« Reply #6 on: February 11, 2011, 05:07:14 AM »

Hello, Gary here.
Sticking my nose where I probably should not but if you are willing to do Assembly on PICs and Arduinos why not 86 code in the PC? In a pinch you could allocate an old PC or laptop with Dos and use Debug for some quick and dirty access to serial port at the bit level. With the old GW Basic (or BasicA? needs a REALLY old computer) you can do peek and Poke and Get and Put directly to bit level too. May be better (read easier) but a little loss of timing precision. Just a thought.
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #7 on: February 11, 2011, 10:57:29 AM »

The idea is to produce an application that is portable across current platforms, namely Windows and Unix. Hense the thoughts about using Java. My current code doesn't even need a custom application, just a dumb terminal program.

As the protocol requires the timing of the first character I feel this is not possible with any bloated OS, when the start bit goes low you have to respond within micro seconds if you are going to reliably time the ensuing low period.

Any embedded system can do this and for me the most obvious choice is and Arduino with a 485 tranceiver. As it's easy to make an Arduino clone I can knock a board up that does the lot and only be about 1" square if necesary.

This way the "analyser" just assembles frames and ships them to the PC.

NOTE: Thinking, it's possible that the analyser won't even assemble frames, just read and upload bytes.
« Last Edit: February 11, 2011, 11:15:44 AM by Graynomad » Logged

Rob, aka the GRAYnomad
garylcamp
Newbie
*
Posts: 10


View Profile WWW
« Reply #8 on: February 11, 2011, 04:29:38 PM »

Ah, I did not know you were making this as a released tool. Should have guessed from the title of the forum. It would be cleaner if you knew an Assembly guy who could do a dll so you could call it from almost any high level language. Even then it would not work in Unix.
Logged
captcha
Newbie
*
Posts: 7


View Profile
« Reply #9 on: March 28, 2011, 02:32:24 PM »

As per previous posts, the idea was to have an mcu detect busnet activity and then send this as rs232 to client software on a PC (running a java version of the busnet protocol analyser software which is about 10 per cent ready, haha..).

Over the weekend I programmed an ATtiny85 do some bit banging and successfully send RS232 data to my laptop. The speed I have so far is 38400bps. For faster speeds and tune the timing I may need to revert to use plain asm NOP instructions.

After setting the fuses to disable CLKDIV8 the t85 is now running at 8MHz. This should be enough for faster comms rates but I may need to go faster still to properly deal with reading incoming activity (probably interrupt driven) AND sending it in RS232 format back to the PC at the same time (I don't think the avr-gcc supports threading?).

Before I post this question the avr forums, does anyone know what maximum speed I can squeeze out of a t85 with and without using external parts?

Also, any suggestions for running two processes (reading busnet activity and sending serial) on the same mcu? I was thinking of creating a joblist buffer and alternating between the two. Maybe using internal timers or so.

Dunno yet..

Any feedback is welcome.
Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #10 on: March 28, 2011, 07:19:51 PM »

Currently the BUSnet speed is specked at 4800bps, however I'm going to aim for 9600 and even 19200.

So let's assume the worst case of 19200. Obviously to keep up the chip has to transmit to the PC at least as fast as that. So we have two bit-banged "processes" one to receive and one to transmit.

The catch is that they have to run simultaneously so I don't think you can alternate between the two, you have to receive and transmit at the same time because there are no long idle times in which other stuff can be done.

(NOTE: How will this sync with the data stream?)

I'm sure this is doable but will need some clever programming and won't allow any other "work" to be done as well.

One easy way to do this is to forget about "serial" and just pass the data through, read a 1, write a 1, read a 0, write a 0, in a tight ASM loop.
    
But if you do this you may as well just use the output of the RS-485 transceiver.

None of the above allows for any buffering of data, and I guess that's the reason for using a chip at all, because we can't rely on Java to get all the bytes. Is that the case though, surely the PC low level code buffers incoming characters.

If so we don't need any hardware at all except a transceiver.

Certainly I've got code that writes to a PC serial port at 115200 and AFAIK it never looses a character.

So is that the answer, a simple 485 transceiver into a USB-serial cable?

BTW, the 85 can be run at 16MHz by using the internal PLL.

ANOTHER NOTE: I'm about to post about an evaluation board I'm designing. That can probably be used as a protocol sniffer.

Se here http://www.robgray.com/forum/index.php/topic,25.0.html

 
« Last Edit: March 28, 2011, 07:43:46 PM by Graynomad » Logged

Rob, aka the GRAYnomad
captcha
Newbie
*
Posts: 7


View Profile
« Reply #11 on: March 31, 2011, 10:33:51 AM »

There won't be many cycles to process things in the mean time but I'm sure there will be enough if the maximum busnet speed is 19200.

One thing that needs consideration is that the mcu that's monitoring the bus may come across incomplete or not properly timed RS485 packets. The protocol analyser I have in mind should be able to detect even one stray bit.

Quote
So is that the answer, a simple 485 transceiver into a USB-serial cable?

If the goal is to inspect the bus at bit level than I would think the answer would be no.

I like the idea of being able to detect one bit on the bus *and* still have enough time to send an RS232 character to the PC (1 Byte at 115200 to the pc takes about 87 microseconds, one bit at 19200 takes about 52 microseconds).

Sounds reasonable?

Logged
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #12 on: March 31, 2011, 01:10:32 PM »

What a shame there are any better low end AVRs with uarts.

Can you fit the code into a 2313 (4313?), that's the smallest chip with a hardware uart. OTOH the chips are so cheap these days maybe just put a mega328 in there. The other advantage to using a larger chip is that it can provide real time filtering and also triggering for a logic analyser.  

Initially I did want bit-level analysis on the PA, partly because of the interrupt feature (which no longer exists) and also because of the autobaud detecting by nodes and the bit-level bus clash detecting. However the autobaud is an internal thing for a node, the base data rate is crystal controlled so a PA doesn't have to adjust it's bit rate because the bits on the bus will always be a standard width.

The bit-level bus clash detecting is nice to have but was really only needed for the interrupts.

I'm now happy with byte-level clash detecting, this may mean packets are corrupted and have to be resent, but it does reduce the complexity of the interface software.

I'm wondering if it's better to use a logic analyser for low level timing issues and leave the protocol analyser as a byte-level device.

Another thing to think about it the line polarity. Nodes are polarity blind because the polarity can change after every node when daisy chaining. This means that a PA will have to have that ability as well.

It shouldn't be very hard, you already have to sync with the bus frames, it's just a matter of testing the line level once synced and either inverting or not inverting the data stream to/from the network.

Anyway the bit-level stuff will need some very tight assembly code that at the end of the day will do little more than echo the bytes. Is it worth it?

EDIT: Just thought of another thing. Packets (maybe even every byte in some cases) sent to the PC should have a time stamp, probably 3-4 bytes in length, so analysis can be done on the timing. I think that will totally blow the bit-level code out of the water?

 
« Last Edit: March 31, 2011, 01:14:46 PM by Graynomad » Logged

Rob, aka the GRAYnomad
Graynomad
Administrator
Jr. Member
*****
Posts: 55



View Profile WWW
« Reply #13 on: March 31, 2011, 01:33:02 PM »

OK I've had a bit of a think and here's how I reckon the PA should work.

At the coal face there is a processor, this is a large chip because it should do the following

a) read and write to the bus using one serial port
b) read two more serial connections, these being two applications talking to the network, this needs two more serial ports
c) read at least two digital inputs so it can trigger on a node digital in/output changing state
d) read at least two analogue inputs so it can trigger on a node analogue in/output reaching certain levels
e) filter frames of various types, ie no point uploading 1000s of polls
f) filter frames to/from certain addresses
g) insert deliberate errors for stress testing
h) provide a trigger output for a logic analyser
i) talk to the PC via USB
j) a stack of things I haven't thought of yet

Due to the 4 serial requirement this probably has to be a mega2560, although I'd prefer a mega1284 because it has 16k RAM but that only has two serial ports.

As it happens I'm designing a node very similar to this at present, it could be used for it's main purpose (a network UI) or a protocol analyser by loading different components onto the PCB.

The PA software then really just provides a GUI for this chip and does nice formatting of the data etc.

Now if it goes this way that doesn't mean the low-level code you are working on is/will be wasted, far from it because the BNIC chip (the node's network interface) does have to be a tiny84/85 running some very tight code. So anything you do will be directly usable for that I would think.
 
« Last Edit: March 31, 2011, 01:38:38 PM by Graynomad » Logged

Rob, aka the GRAYnomad
Pages: [1]
  Print  
 
Jump to: