Back
[08:11:56] <megal0maniac> I have an idea. And it's very likely to be crazy, but I'd like input from anyone who might know a bit about this stuff
[08:12:38] <Tom_itx> it's crazy
[08:13:37] <megal0maniac> Most dumb desktop switches are driven by a switch IC which supports tagged VLAN, mirroring etc. Lots of fancy stuff that you don't get to use. They can be controlled by reading an I2C EEPROM or by a management interface to a computer (which is also I2C)
[08:14:13] <megal0maniac> How about using an AVR, or PC software (to control an I2C bus) to "manage" the switch and enable/disable features?
[08:14:59] <Tom_itx> you'd have to capture the data and decipher it
[08:15:21] <megal0maniac> It's mostly documented in the datasheet, though
[08:15:24] <Tom_itx> and do it quick
[08:15:35] <megal0maniac> I'm thinking state machine
[08:15:47] <megal0maniac> But it's more to control the switch than read its status
[08:18:00] <megal0maniac> Thinking it might be cool to unlock all the potential, especially with an AVR. Switches are cheap.
[08:18:30] <Tom_itx> document it and post it somewhere :)
[08:18:49] <megal0maniac> Well I need to make sure it's viable first
[08:19:29] <specing> interesting
[08:19:37] <specing> I did not know that
[08:20:04] <megal0maniac> specing: Open up a little 5/8 port switch and find the datasheet. You'll be surprised
[08:21:47] <megal0maniac> Like this one is commonly used in dumb switches, but also my router. And OpenWRT can configure port mirroring and tagged/untagged VLAN for each port including the MII to the processor. You can literally isolate the switch from the router and mirror the upstream port to the MII to capture packets from your 'dumb' switch. The router part is invisible
[08:21:52] <megal0maniac> http://realtek.info/pdf/rtl8366_8369_datasheet_1-1.pdf
[08:22:09] <megal0maniac> *invisible to the network
[08:26:51] <specing> so are we going to blenda up and create a switch?
[08:27:43] <megal0maniac> Well, make a switch smarter
[08:28:10] <megal0maniac> Turn a $20 switch into a $200 switch for an extra $10 and some creative programming
[08:30:34] <megal0maniac> I can view stats for each port since power-up. How many packets of various sizes have passed through, broadcast, multicast, which features are enabled, the rate the LED is set to blink when there's traffic, link status, everything.
[08:31:39] <megal0maniac> First, though, I need to learn I2C on AVR
[08:36:26] <specing> can you make a board? How much would it cost to get it manufactured and populated?
[08:36:36] <specing> because I would be very interested in such a switch ^_^
[08:36:59] <megal0maniac> Hahaha! Well, get a router supported by OpenWRT and have a look at swconfig
[08:37:47] * specing sshs into his OpenWRT router with 100Mb/s switch
[08:38:08] <megal0maniac> swconfig list
[08:38:17] <specing> not installed D:
[08:38:18] <megal0maniac> swconfig <switch name> show
[08:38:20] <megal0maniac> Aw
[08:38:34] <megal0maniac> http://wiki.openwrt.org/doc/techref/swconfig
[08:38:34] <specing> cannot find package swconfig :/
[08:38:52] <megal0maniac> Not all switches are configurable
[08:39:35] <specing> Linux OpenWrt 2.4.35.4 #12 Mon Jun 1 21:52:49 UTC 2009 mips unknown 'ole router
[08:40:41] <megal0maniac> Yeah, we're at 3.10.49 now... I have another router, it seems the switch is built into the SoC
[08:41:01] <megal0maniac> The one I'm using is a TP-Link WR1043ND v1.8
[10:17:02] <autrilla_> How do you usually handle the situation where you've sent a packet and you're expecting a response? Algorithm-wise, I mean. I am doing this on Python first, to remove the hardware layer, and I have a getPacket() method that returns a packet from the buffer, if there is one, and null if there isn't.
[10:22:22] <vsync1> well
[10:22:24] <vsync1> autrilla_:
[10:22:38] <vsync1> what you do is you put a python interpreter on the avr
[10:22:46] <vsync1> to remove the having to know anything -layer
[10:22:55] <vsync1> to replace it with the ignorance layer
[10:23:07] <autrilla_> vsync1, dumbass.
[10:23:18] <vsync1> right back at you?
[10:23:47] <autrilla_> vsync1, read the topic, moron
[10:23:52] <vsync1> you can just put mains through your arduino and use python
[10:23:59] <vsync1> it's really as easy as abc
[10:24:26] <autrilla_> vsync1, you sure know how to do stuff
[10:24:49] <autrilla_> Removing a layer to develop a protocol on a much more debugging-friendly setup seems like a bad idea to you
[10:44:11] <vsync1> the original example only demonstrates your ignorance
[10:44:19] <vsync1> how about let's make a few classes for this?
[10:45:57] <Tom_itx> how about contributing or being silent on it
[10:47:14] <autrilla_> vsync1, ignorance why, because I'm using python and not some master-race language like C or C++?
[10:47:18] <autrilla_> Thanks tom
[10:48:36] <specing> why are you using python to prototype if you are going to have to rewrite this into some master race language anyway?
[10:49:16] <autrilla_> specing, because I wanted to practise python. Also, because the algorithm is the same, whatever the language
[10:49:41] <autrilla_> And python is easier to debug than C running on an embedded system
[10:49:57] <LeoNerd> I often prototype hardware IO stuff with new chips using my Bus Pirate + perl, so I can play around with the chip itself before I try moving it onto AVR hardware when I understand it and have a good idea of how to use it
[10:50:54] <LeoNerd> E.g. the nRF radio chips - I would have found it much harder to fix all the tricky cornercase details of talking to that, if I had to do it directly from the AVR chip
[10:51:34] <autrilla_> LeoNerd, also, as I said, it removes the physical layer, it's easier for me to know if the error is on the hardware or on the software.
[10:52:08] <LeoNerd> Yah.. fewest moving parts for an initial prototype is always good. Then you can gradually add them and check things are still as you expect
[11:11:21] <Lambda_Aurigae> autrilla_, unfortunately, on microcontrollers, you often have to include the hardware layer and the hardware/software interface layer in your whole protocol layout because it can work different from, say, socket interface on a PC
[11:11:45] <autrilla_> Lambda_Aurigae, I took that into account already
[11:12:19] <autrilla_> Lambda_Aurigae, I'll be using RS485, and I know what happens when multiple devices send at the same time etc
[11:12:24] <Lambda_Aurigae> as for waiting for a packet return, that's totally different on a single threaded processor without an OS than it is on a PC running python with a full OS and whatever python uses for things like exceptions.
[11:13:16] <autrilla_> Lambda_Aurigae, I'm running it single threaded too
[11:14:14] <autrilla_> I'm trying to get this "simulation" as accurate as I can without the hardware layer. It's impossible to get exactly the same.
[11:14:20] <Lambda_Aurigae> as for your packet return, what physical mechanism do you use for comms?
[11:14:41] <autrilla_> Lambda_Aurigae, RS485
[11:15:25] <Lambda_Aurigae> ok..there is your physical signalling layer.
[11:15:41] <Lambda_Aurigae> what protocol layer on top of that?
[11:16:02] <autrilla_> Lambda_Aurigae, one I've designed. The spec is quite long and in spanish, sadly
[11:16:17] <autrilla_> It is similar on some aspects to CAN
[11:16:24] <Lambda_Aurigae> then how you do your packet retrieval depends much on that.
[11:16:55] <autrilla_> Lambda_Aurigae, well, yes, that was my question, how to do that
[11:17:12] <Lambda_Aurigae> depends on your protocol layer and how it is implemented.
[11:17:40] <autrilla_> My question is about the protocol layer. I have a protocol specification but no implementation
[11:17:53] <Lambda_Aurigae> from the microcontroller, how are you sending and receiving signals? bitbanged interface or are you using the USART?
[11:18:03] <autrilla_> Basically, I have: send this packet and wait for a response, etc
[11:18:09] <autrilla_> UART
[11:18:26] <Lambda_Aurigae> so it's rs232 over rs485?
[11:18:42] <autrilla_> Guess so, yes.
[11:18:48] <Lambda_Aurigae> well, not really rs232...but standard UART over rs485
[11:19:01] <autrilla_> rs232 is just another physical layer, right?
[11:19:33] <Lambda_Aurigae> so your program has to watch for a byte coming in and check it for a packet start situation..
[11:19:52] <autrilla_> Yes, I'm doing that already
[11:19:52] <Lambda_Aurigae> the UART will generally be able to generate an interrupt on byte reception..
[11:20:00] <autrilla_> A bit more complex, but mostly that
[11:20:10] <Lambda_Aurigae> in the interrupt routine you would store that byte in a buffer.
[11:20:28] <autrilla_> Lambda_Aurigae, my original question was, what to do on a situation where I've sent a packet and I expect a response.
[11:20:33] <Lambda_Aurigae> once the buffer is full you want to look at it and see if it is a proper packet...if so, move it from the buffer to somewhere you can process it.
[11:20:43] <Lambda_Aurigae> wait and watch for the response.
[11:21:13] <autrilla_> Lambda_Aurigae, blocking?
[11:21:17] <Lambda_Aurigae> up to you.
[11:21:20] <autrilla_> Here is the code, btw
https://gist.github.com/autrilla/b00a7feb02d5de3d2717#file-simulator-py-L56
[11:21:23] <Lambda_Aurigae> can do it blocking or non blocking.
[11:22:05] <autrilla_> How would you do it the non-blocking way? Set a variable, awaiting_response, for example?
[11:22:09] <Lambda_Aurigae> use the interrupt routine to catch and store any incoming data then it can set a flag variable once it has data...in the main program you occasionally test against the flag.
[11:22:42] <Lambda_Aurigae> once the flag is set the main program copies the data to working storage, resets the flag, and clears the buffer.
[11:22:54] <autrilla_> That makes it difficult to really check if the packet that came was the packet I was waiting for...
[11:23:12] <Lambda_Aurigae> you need some kind of ID in the packet.
[11:23:37] <Lambda_Aurigae> something the interrupt routine that is reading data can lock onto and let you know if it is valid or what you are waiting for.
[11:23:49] <autrilla_> My packets have this shape: STX ADDR_TO ADDR_FROM FLAGS LENGTH MESSAGE CRC (2 bytes) ETX
[11:24:16] <autrilla_> Well it wouldn't be that bad if I got interrupted for every packet, it doesn't really matter
[11:24:24] <Lambda_Aurigae> so if you are waiting for a return from a certain address,,,watch for that address in the incoming data.
[11:24:59] <autrilla_> hmmm... yeah, that could work. I could also set what flags I'm expecting to get on the packet, just to double check
[11:25:10] <Lambda_Aurigae> hell, the interrupt routine could do the buffer to working data copy and set the flag for you I suspect.
[11:26:30] <Lambda_Aurigae> I would suggest studying the OSI 7 layer model and how tcp/ip handles packet send and reception.
[11:26:45] <Lambda_Aurigae> probably waaay more complex than you want but it is a good bit of research.
[11:26:56] <autrilla_> Will do, thanks!
[11:27:05] <Lambda_Aurigae> http://www.webopedia.com/quick_ref/OSI_Layers.asp
[11:27:16] <Lambda_Aurigae> quick overview of the osi 7 layer model.
[11:31:59] <Lambda_Aurigae> I actually met and worked with Robert Metcalfe some years back. He was personal friends and had gone to school with the CEO of the company I worked for. He put me onto a lot of the good and bad of the OSI model and the deeper workings of ethernet and networking in general...brilliant guy.
[13:01:47] <hetii> Hi
[13:01:47] <hetii> :)
[13:04:06] <hetii> Q: I have sucj rj45 trafo:
http://www.datasheetarchive.com/dlmain/SFDatasheet-19/sf-00054830.pdf , what I should do with pins 11,14 and 3,6 ?
[13:22:57] <Lambda_Aurigae> hetii, those would be used for POE I do believe.
[13:23:22] <Lambda_Aurigae> though, not sure how exactly.
[13:23:27] <Lambda_Aurigae> they are just center taps.
[13:24:31] <Lambda_Aurigae> maybe they are used for 10MHz vs 100Mhz connection?
[13:25:45] <hetii> http://www.8085projects.info/wp-content/uploads/CS8952%20Network%20Ethernet%20interface%20circuit.jpg
[13:26:05] <hetii> well in different schema i found that they are connected in different way
[13:26:21] <hetii> sometimes by capapitor to GND sometimes to vcc
[13:26:41] <hetii> http://i.stack.imgur.com/i0fnN.png
[13:27:01] <Lambda_Aurigae> noise supression then.
[13:27:07] <hetii> its not clear for me what to do with them
