Welcome, Guest. Please login or register.

Login with username, password and session length
ArdweeNET forum

  Show Posts
Pages: [1] 2 3 4
1  Web site, blog, forum / General / Re: Current "website" on: December 08, 2012, 12:23:41 PM
Yep that's the new style, partly because that's the best background I could get on the new blog


and I wanted to have (as far as possible) the same look and feel between the blog, site and forum.

2  ArdweeNET / Protocol / CRC algorithm on: November 29, 2012, 02:14:09 PM
It looks like I'm settling on the CAN 15-bit CRC algorithm with the 0x62CC polynomial.

This is optimised for small data packet sizes and has a hamming distance of 6 (up to 5 corrupted bits detected) for data between 64 and 112 bits. As the checked part of an ArdweeeNET frame is 96 bits in length this is a good match.

This does however mean using software to generate the CRC as opposed to using the LPC's built-in hardware CRC generator. Probably a price worth paying to get the best CRC.
3  Web site, blog, forum / General / New domains on: November 29, 2012, 01:49:07 AM
I've grabbed the following domains for use by the ArdweeNET project


Don't bother going there yet though.
4  Web site, blog, forum / General / Current "website" on: November 29, 2012, 01:47:11 AM
There is currently a "website" which is part of my main site.


I'll be moving this to it's own domain before long.

EDIT: Moved

5  User interface(s) / General / Read me on: November 28, 2012, 01:38:05 PM
At some point I see a slick-looking GUI for an ArdweeNET network. This is not a trivial project so maybe some discussion can be held here.

For example what platform? In the past I've always liked the idea of a custom LCD with controller etc. But that make absolutely no sense in the day of $50 tablet computers. Currently I'm thinking Android tablets, but there are a lot of options out there.

And what should a GUI do? Maybe interrogate the network and display nodes and IO modules connected. Maybe talk directly to a node's processor in "monitor mode". Maybe remote flashing of application processors.

At this point it's totally open.
6  About / Read me / Read me on: November 28, 2012, 01:07:36 PM
This forum is for those interested in the ArdweeNET project, it's just been started so there's really nothing here at present.

For the time being new users cannot be created by anyone except admin, this is because of the prevalence of spammers and frankly life's too short for me to spend time sorting out all those @rsholes.

That said I welcome people with a genuine interest so if you want to join in email me with your preferred user name and I'll set up an account for you.

Also if you think a new categories is needed let me know.

7  ArdweeMODs / General / About on: November 28, 2012, 01:00:37 PM
ArdweeMODs are small IO modules designed to plug into an ArdweeNODE.

This section is for discussions about their design, interfaces, proposed modules etc.
8  ArdweeNET / General / Read me on: November 15, 2011, 09:47:16 AM
This section of the forum is brand new as I've just totally redesigned BUSnet into ArdweeNET.

I have closed the forum to new members for the time being because there is too much spam and I'm often out of touch for days at a time and can't delete them.

There is a special login you can use though if you feel the urge to comment

User: ardweenet
Password: ardweenet

Feel free to use that and if you're keen email me (rob@robgray.com) and I'll set up an account for you.

9  BUSnet (old version of this network, no longer active) / Read me first / Major changes on: November 13, 2011, 02:16:50 PM
As of October 2011 the BUSnet design underwent a major change (and rename to ArdweeNET), from master-slave to multi-master, and from bus to ring topology.

This means that all the current posts on the forum probably have no meaning with regard to the current design.

So most (all?) of the discussions on this part of the forum are redundant. Future discussions should be on the ArdweeNET section but I'll leave this board here for the time being.

10  BUSnet (old version of this network, no longer active) / Development tools / Re: Evaluation/test board on: April 27, 2011, 07:25:43 PM
PCB finished, see


For some details.
11  BUSnet (old version of this network, no longer active) / Documentation / New schematics on: March 31, 2011, 02:58:03 PM
New schematics for several IONs have just been posted.

12  BUSnet (old version of this network, no longer active) / Development tools / Re: Protocol analyser software 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.
13  BUSnet (old version of this network, no longer active) / Development tools / Re: Protocol analyser software 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?

14  BUSnet (old version of this network, no longer active) / Development tools / Evaluation/test board on: March 28, 2011, 07:43:04 PM
Something I've had in mind to do for a while is an "evaluation" board to use as a basic proof of concept. I have now started the design and am planning the following...

A single PCB with several independent components

a) A master controller (MCU). An ATmega1284 with RTC and USB interface. MCUs will typically be hidden somewhere behind the scenes, the USB allows field upgrades and diagnostics but MCUs don't normally talk to humans. A network has a single MCU.

b) A network control node (NCN). NCNs do talk to humans, they are normal nodes but they have a user interface and the "authority" to ask for information about points and also read/write system parameters. An NCN can therefore be used as the main display for the network. The NCN I'm designing has a 3.2" LCD with touch, USB, SD card, buzzer etc. A network can have as many NCNs as makes sense, normally to allow displays in separate areas.

The board will have one MCU and one NCN.

c) Nodes. Between 5 and 10 nodes of various types. Just to get the ball rolling I'm thinking the following simple types


but maybe a couple of more complex nodes like GPS should be added as well, plus a prototyping node.

All the above will be on a single PCB with the network "wiring" being some traces on the board. Thus an entire network can be emulated on a single PCB.

However, just so this isn't wasted, all the above can be snapped off, put in an enclosure and used for real.

Any thoughs in this welcome before I get to into the design.
15  BUSnet (old version of this network, no longer active) / Development tools / Re: Protocol analyser software 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

Pages: [1] 2 3 4