Smaller picaxe to store 1kb comming from the serial port

[djsoftlayer]

Hi guys!, I have a very simple protocol, is just a serial line where I need to connect some picaxes, in this serial bus some time a 1kbit word is send from a computer (they are always 1kbit fixed), from this 1000 bits of data the first 8 are the address of the microcontroller who needs to save the next 992 bits, this address is store on the picaxe program by just a simple var.

So the program is always listening to the serial port, when something comes it read the first 8 bits and if they match the micro address continues reading the next 992 bits and store them. Every micro will only save one set of 998 bits at the same time.

My problems are two, for a long time I don’t use picaxe so I don’t very well the new M2 models and I am not very good at programing with picaxe, the last time I implemented a serial in was something like: serin serpin,N2400,(27),seraddr, b4,b5 that obviously does not serve for this long set of data, I know that the micro can hold this amount of data using peek and poke, but I really don’t know how.

The solution have to be the most cheaper micro because they will be about 100 micros connected to this serial line and my budget is very low .

Thanks for any help!

 

[hippy]

So the program is always listening to the serial port, when something comes it read the first 8 bits and if they match the micro address continues reading the next 992 bits and store them. Every micro will only save one set of 998 bits at the same time.

The first question is are you receiving 1000 bits or receiving 125 serially framed bytes with start and stop bits ?

Do you have any link to anything which describes where this data is coming from and details exactly what format it is in ?

 

[djsoftlayer]

Mod

The first question is are you receiving 1000 bits or receiving 125 serially framed bytes with start and stop bits ?

Do you have any link to anything which describes where this data is coming from and details exactly what format it is in ?

Is a theoric protocol im inventing so i can modified it based on your suggestions...

 

[westaust55]

Does the received data need to be retained in the even of a reset or power off condition?
the (larger) 20/28/40 pin X2 parts have a 1024 byte scratchpad

If you need non-volatile storage then an external EEPROM may be required.

What is the intended baud rate (bits/second including any satrt and stop bits)?
Higher data rates will make it difficult for the PICAXE to receive and have time to store the data unless there are gaps between each or small groups of bits/bytes.

Seems you need to take some time to step back and think about the protocol you are inventing then explain in some more detail your expectations.
Then we are better equipped to guide you to a solution.

 

[BeanieBots]

Seems you need to take some time to step back and think about the protocol you are inventing then explain in some more detail your expectations.
Then we are better equipped to guide you to a solution.

Or, explain the hardware in more detail and we can help with the protocol.

 

[djsoftlayer]

hi

Thank you guys for the feedbacks!, no need to futher explanations about the protocol, imagine that it does not exist. The problem in a few words is; you have a bus of data with many microcontrollers attached, once in while in that bus 1kb of data is sended (you can choose how to send it too, all at once, in bytes packege, etc), from this 1kb of data the first 8 bits are the address of the micro how need to store the next 998 bits. Because the my small budget and the large quantity of micros attached to this bus (about 100 micros) i need to choose the cheaper picaxe capable of doing just this, and how to use the peek and poke commands to store the info in ram.

 

[srnet]

So since we are given no detail of what the protocol does,(and apparently how it does it is not important anyway) or what the application is, or what it does, all we have to go on is you want a a PICAXE that can;

Store 998 bits ?

Sounds a complex project, and peek and poke are failry basic commands and well explained in the manuals.

If you want to know how much RAM the various PICAXEs have for storage (using PEEK and POKE) its explained on page 11 of Manual 2

 

[hippy]

This will read a byte header ( 8 bits ) plus a subsequent 124 bytes ( 992 bits ), and store those in RAM using POKE if the header matches a specific PICAXE's ID.

#Picaxe 08M2

Symbol MY_ID = 0

Do
  SerIn 1, N2400, b0
  For ptr = 4 To 127
    SerIn 1, N2400, b1
    If b0 = MY_ID Then
      Poke ptr, b1
    End If
  Next
Loop

That assumes serial transfer of data and does nothing but read each packet and either put it in RAM if directed at that PICAXE or discard it. If you want anything beyond that you will have to define the protocol and explain more about what the application is intended to do.

 

[djsoftlayer]

Thanks

This will read a byte header ( 8 bits ) plus a subsequent 124 bytes ( 992 bits ), and store those in RAM using POKE if the header matches a specific PICAXE's ID.

#Picaxe 08M2

Symbol MY_ID = 0

Do
  SerIn 1, N2400, b0
  For ptr = 4 To 127
    SerIn 1, N2400, b1
    If b0 = MY_ID Then
      Poke ptr, b1
    End If
  Next
Loop

That assumes serial transfer of data and does nothing but read each packet and either put it in RAM if directed at that PICAXE or discard it. If you want anything beyond that you will have to define the protocol and explain more about what the application is intended to do.

Thanks Hippy, that should solve the problem, but about the address check, you are using a 4 bits var b0, i can use an 8 bits var like w0 for example right? because 4 bits are not enough to address 100 micros. Do you think if i use a higher bit rate, lets say about 115200bit/s the picaxe will have time to save to the ram and at the same time read the serial port? what do you think will be the maximun speed based in your experience? THANKS!

 

[srnet]

Do you think if i use a higher bit rate, lets say about 115200bit/s the picaxe will have time to save to the ram and at the same time read the serial port? what do you think will be the maximun speed based in your experience? THANKS!

I dont know the answer, but I do know that the bit rate in itself may not be the limiting factor.

What is generating this data and if its being sent as standard serial bytes, what is the gap (time) between each byte ?

Its a mystery to me what problem it is you are trying to solve here.

 

[djsoftlayer]

I will try to explain this the best i can (i dont have a very good english). From my computer i have to send packege of data of a fixed dimension 1kb, this information will be sended using a serial cable, how this is information is sended is to be defined, thats why im asking here, because i know you guys have more experience than me in this field. To this serial bus will be always listening a huge quantity of micros, about 100. Every package of 1kb is destinated to one micro, as i said before the firts 8 bits indentified wich micro the package is destined for.

I was thinking to send the 1kb in package of 8 bits in a syncronous way, so i was thinking in this way to go:

Imagine that i send the firts package, 1000 bits, 8 of address and 992 of data, ALL the micros connected to the serial line are listening, ALL compares 8 bits to their own address and the one who match answer "Im here" (will be an 8 bits response like AF or FF it doesnt matter) so the pc knows that the micro exist in the line and will start the sending of the rest 992 bits in packeges of 8 bits, the rest 99 micros will be also listening to the hole process but they "know" that they have to ignore the "Im here" answer and the next 992 bits of data that belongs to other micro. Once i send the respect pack of info to each micro in the serial bus i send another command that obligade all the micro to output (output pin could be a led) all the data they previously stored in ram.

My worrys are two, one the speed, i have to send the 100 packege of data to the 100 micros in maximun 10 seconds, and second one is to desing the slave micros the most cheap as possible. Thanks again!

 

[srnet]

How long (in distance) is this serial cable ?

And do you really mean synchronous or are you sending normal asynchronous data ?

 

[hippy]

about the address check, you are using a 4 bits var b0, i can use an 8 bits var like w0 for example right? because 4 bits are not enough to address 100 micros.

The 'b' variables are byte variables and hold 8-bits. The 'w' variables are word variables and hold 16-bits.

Do you think if i use a higher bit rate, lets say about 115200bit/s the picaxe will have time to save to the ram and at the same time read the serial port? what do you think will be the maximun speed based in your experience? THANKS!

If you use SERIN, you are limited to supported baud rates ( see Manual 2 ); you can use any baud rate but you have to provide enough time between bytes for the receiver to do whatever it has to do.

If you want to have back-to-back data byte reception you'll have to use high-speed full background receive which means moving up to an X2 PICAXE.

There are two ways to approach things; define the protocol then choose a PICAXE which can support that, or choose a PICAXE and define the protocol to match what it supports.

 

[srnet]

My worrys are two, one the speed, i have to send the 100 packege of data to the 100 micros in maximun 10 seconds, and second one is to desing the slave micros the most cheap as possible

Thats very useful for us to know (hint !).

So you have to broadcast a packet of 1000 bits every 100mS, or 1 bit every 100uS, is that so ?

Thats the equivalent of (approx) 9600baud.

 

[hippy]

i have to send the 100 packege of data to the 100 micros in maximun 10 seconds

100 sets of 125 bytes, framed with start and stop serial bits is 125000 bits. Over 10 seconds that's 12500 bits per second so 19200 baud should achieve that.

There however has to be time provided between data bytes for the PICAXE to do whatever it needs so it may be best to transmit at 38400 baud and add delays between the bytes sent. The problem then is in inserting those delays on the sending PC. If the sender suspends between sending each byte this may add milliseconds between each byte sent which increases the transmission time and can exceed the time you need to update everything within.

Probably the best solution is to place an X2 using high-speed background receive between the PC and 08M2's then you can send full-speed to the X2 and have that send the data to the 08M2's with suitable pacing.

You can optimise the 08M2 code to receive data using SERIN packets as quickly as possible using 124 sequential "SERIN pin, N38400_32, @bPtrInc" commands which will help to improve things but true performance won't be known until things are prototyped.

 

[djsoftlayer]

for those curious about what i'm trying to build http://www.youtube.com/watch?v=gusJeslMbLc

 

[srnet]

What is it ?????

 

[hippy]

for those curious about what i'm trying to build http://www.youtube.com/watch?v=gusJeslMbLc

This seems to be a waterfall curtain, taps turned on and off to give a graphic display in real time. It may be possible but it's an ambitious project.

On using 'cheapest PICAXE' you may have to reassess that. I imagine each of the 100 PICAXE control a tap / column of water. Rather than have an 08M2 for each tap receiving 992 bits it may be more cost effective to use 28X2's receiving 7936 bits and control eight taps.

08M2, 100 x £1.50 = £150
28X2, 13 x £4.49 = £59

 

[g6ejd]

Thanks Hippy, that should solve the problem, but about the address check, you are using a 4 bits var b0, i can use an 8 bits var like w0 for example right? because 4 bits are not enough to address 100 micros. Do you think if i use a higher bit rate, lets say about 115200bit/s the picaxe will have time to save to the ram and at the same time read the serial port? what do you think will be the maximun speed based in your experience? THANKS!

Var b0 is an 8-bit byte so up to 256 devices can be stored. if Var w0 (b1,b0) was used that's a 16-bit variable and 65536 devices. So you only need var b0 as one byte. The serial speed is likely to be too fast, as the protocol is not yet designed why use that speed. Have you worked out your time budget to get all 100 readings of 1000-bits in a given time?

 

[womai]

The easiest way do to this that I can see is about as follows:

Use Picaxe X2's (e.g. 20X2) which can do background hardware serial receive into scratch RAM. Hook them all up to one serial (RS-232) data line from the host PC. Hardware serial receive (hserin) lets you receive data at pretty much at any speed (115.2 kbaud is possible, though you won't need quite as much for your application) for blocks up to the size of the scratch RAM - large enough to hold your 125 bytes. Here I assume the scratch RAM is at least twice as large (250 bytes) for the algorithm to work:

1. The PC sends the 100 packets, with short pauses inbetween. Then it send the next set of 100 packets, and so on.
2. At the beginning, all 100 Picaxes just wait for and then receive each packet.
3. Once they have one one packet (125 bytes) in their buffer (easy to check through hserptr location) they immediately check the first received byte (first byte in the scratch buffer).
4. If it matches their address (for each packet this will only be true for one Picaxe out of the 100), they copy the 125 bytes to some other place in the scratch buffer so it won't get overwritten by subsequent receives. Then they can go back to listening for new packets. The pause between packets must be sufficiently long so the copy process has finished before the next packet.
5. If there is no match, they back right away to listening. That way they will be all ready for the very next packet to arrive.
6. That way one Picaxe after the other will correctly receive the packet intended for it, with minimum processing in the actual Basic program (all the heave receive lifting is done in the background by the firmware).

If the required pauses are too long one could think about using specific signature strings at the beginning of each packet which hserin can use to determine the packet boundaries.

 

[djsoftlayer]

This seems to be a waterfall curtain, taps turned on and off to give a graphic display in real time. It may be possible but it's an ambitious project.

On using 'cheapest PICAXE' you may have to reassess that. I imagine each of the 100 PICAXE control a tap / column of water. Rather than have an 08M2 for each tap receiving 992 bits it may be more cost effective to use 28X2's receiving 7936 bits and control eight taps.

08M2, 100 x £1.50 = £150
28X2, 13 x £4.49 = £59

Thanks for the help, this is the smartest way to go

 

[Paix]

Given that this display is likely to be nine or ten feet across, any thoughts about the communication of this RS232 signal to a tight bunch of processor boards with attendant extended lines to the water jets, or a distributed array of processor boards, with much shorter lines to the water jets?

TTL and twisted pair, or what and has this aspect been considered yet?

 

[djsoftlayer]

Given that this display is likely to be nine or ten feet across, any thoughts about the communication of this RS232 signal to a tight bunch of processor boards with attendant extended lines to the water jets, or a distributed array of processor boards, with much shorter lines to the water jets?

TTL and twisted pair, or what and has this aspect been considered yet?

I think is the second one, more reliable.

 

[srnet]

I think is the second one, more reliable.

Many will puzzle over what you meant there.

TTL defines switching levels, twisted pair is a cable type.

 

[djsoftlayer]

SImple

Many will puzzle over what you meant there.

TTL defines switching levels, twisted pair is a cable type.

...a distributed array of processor boards...

 

[Paix]

My question really was seeking whether you had given sufficient thought about how to connect the 13 nodes + 1 PC node?

Hippy not only solved for a reduced chip count, but that also brought the communications budget down to a significantly more manageable number of total nodes.

It is not un-common to think RS232 when meaning 'standard serial communications'. Srnet has pointed out that TTL refers to a set of signal levels, as does RS232.

Neither is directly compatible one-with-the-other and for simple one-to-one solutions the 10k, 22k resistor interfacing solution is satisfactory. Also on a one-to-one basis TTL inputs and outputs can be connected over extended distances (12"+) by the use of twisted pair connections. viz DB18B20 sensors or disk cables.

Attempting to make this into a multi-drop solution though is likely to be impracticable. Your data bus, assuming that the entry point of your RS232 serial signal is physically half the distance between extremities, and a likely best guess would be, six foot in either direction.

So what's the Real Solution to this problem?

AXE027 USB to TTL interface cable or Serial port to MC1489 RS232 to TTL receiver http://docs-europe.electrocomponents.com/webdocs/0608/0900766b806085f7.pdf

That could give you more than a few options for £0.35, but that is only part of it.

[HUMOUR]
The answer has to be "8"

8 = "1" +" 7"

17 = "4" + "8" + "5"

Highlight the next line for the Real Solution:
>> RS485 <<
[/HUMOUR]

Hippy, Dippy and a few others saw that coming, via the ol crystal orb, but fortunately this time there are no outlandish protocol demands (from original correspondents that don't return to the questions) and it's one way send and forget. You know it makes sense, but I'm happy to hear the (simple) alternatives.

Other than that, I think that Hippy and Womai, with Srnet on the tooth-pulling team have it pretty well sussed.

@djsoftlayer, I do have a question and a request. The request is, please update your profile so that we get to know what part of the world at least you hail from.

The question is can you give us a link to the water valves that you have identified as being suitable please. 1. because I'm a nosey bee and 2. because there might be interfacing issues that where you will need further assistance.

It certainly sounds like an exciting project and I wish you every success with it. Where would you put it if you actually built it?