View previous topic :: View next topic |
Author |
Message |
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Sat Jan 09, 2016 9:26 pm Post subject: Printbin/Inputbin strange problem with Words |
|
|
Hi,
Two Xmegas are coupled via RX,TX and GND.
Printbin and Inputbin are used symmetrically.
This works as expected:
Code: | 'Sender:
Dim Daten(255) as Bytes 'Daten filled with curve(i) data
printbin Daten(1)
'Receiver:
Dim Daten(255) as Bytes
Inputbin Daten(1) |
Daten(1:255) are filled with the full 255 curve data, ok.
'-----------------------------------------------------------------------------------------
Now, the same code but with Words:
Just half of the data, Daten(1:127) is ok, the rest (Daten(128:255)) are Zero!
Code: | 'Sender:
Dim Daten(255) as Word
'filled with curve(i) data
printbin Daten(1)
'Receiver:
Dim Daten(255) as Word
Inputbin Daten(1)
'See only half of the curve, rest=0
|
Am I missing something?
Regards, Meister
(BASCOM-AVR version : 2.0.7.9 , Latest : 2.0.7.8 ) |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Sat Jan 09, 2016 9:37 pm Post subject: |
|
|
the help says : When you need to print the content of a big array(array with more then 255 elements) you need to use the CONFIG PRINTBIN option.
But that seems wrong. At least, after support for non-bytes was added. it now should read :
When you need to print the content of a big array(array with more then 255 elements) or with a data size that exceeds 255 bytes, you need to use the CONFIG PRINTBIN option. _________________ Mark |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Sat Jan 09, 2016 9:40 pm Post subject: |
|
|
Hi,
I imagine that print/Input bin only handles Bytes. What you could do is create a Byte Array overlayed over the word Array.
Code: |
'Sender:
Dim Daten(255) as word 'Daten filled with curve(i) data
Dim Datenb(510) as Byte at Daten overlay
printbin Datenb(1)
'Receiver:
Dim Daten(255) as word 'Daten filled with curve(i) data
Dim Datenb(510) as Byte at Daten overlay
Inputbin Datenb(1)
|
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Sat Jan 09, 2016 11:04 pm Post subject: |
|
|
Mark,
I had added the CONFIG PRINTBIN=extended option. That did not make any difference.
But i.dobson said:
Quote: | I imagine that print/Input bin only handles Bytes. |
Mark, does this still apply, since you mentioned that non-bytes have been added?
i.dobson: I will check your suggestion tomorrow, it's too late already here.
Regards, Meister |
|
Back to top |
|
|
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Sun Jan 10, 2016 2:16 pm Post subject: |
|
|
Good morning,
I made the test proposed by I.Dobson.
Result: Does not work, same result as without the Byte overlay because:
Inputbin only reads 254 Bytes,
Apparently Config Inputbin=extended would be needed but does not exist
I tested with a Logic-analyzer. that printbin indeed transmits all of the 510 bytes,
but Inputbin receives only 254 Bytes =127 words.
So, if I am right it would be nice if Mark could either add to the help that inputbin only receives 254 bytes
(it had cost me two days to find that out, involving two RX/TX line monitors and a LA)
or
-better- add Config Inputbin=Extended.
Now I am stuck with develepment since I need to transfer more that 127 words. Originally I tried with Input, but that turned out to be very slow and when I tested with words, the Input just took the first byte... I gave up with that because of the slowness.
Edit: I am just thinking if I could split up the 255-element Word array to transmit in two chunks.
I had started using DMA instead of Inputbin, but I was having difficulties with synchronization of the two Xmegas. So, I will try again.
Regards, Meister |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Jan 11, 2016 12:03 am Post subject: |
|
|
Once you start transmitting data in separate chunks you run increasing risks of having a single corruption upset the sync, and losing or corrupting a whole chunk of data.
Even if the transmit distance is only very short, I have seen signals between processors get corrupted for all sorts of reasons.
Personally, I would use some sort of protocol with headers and checksum to ensure the data is received without error. I use SNAP protocol, but MODBUS, which is built into Bascom, or many others work well. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Mon Jan 11, 2016 9:09 am Post subject: |
|
|
Adrian:
You were right, transmitting with inputbin in chunks does not work. But the reason is different.
This is what I am doing:
Code: | Input s 'Initial synchronisation. That's sufficient when using a single inputbin transmission!!
do
loop until s="A"
do
inputbin Daten1(1)
inputbin Daten2(1)
for i=1 to 254
print #2, Daten1(i) 'Monitor in terminal emulator
print#2, Daten2(i)
next
|
When not using the second inputbin, this works like a clockwork, the initial synchronization remains locked. That shows that the hardware is ok.
When using both inputbins, I get the most strange results. I worked all Sunday on that but did not get it to work.
Most remarkably, Daten2 is equal to Daten1!
I tested with Waits on both the sender and the receiver side, that made some difference, but I did not get reasonable results.
So, I wonder how the input buffer (I did not use buffered input) is cleared and ready to get new data.
So, this is very disappointing and I am looking foward if Mark could incorporate this Config Inputbin=extended. I wonder if I am the first to discover this.
Best regards, Meister |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Mon Jan 11, 2016 10:32 pm Post subject: |
|
|
I have only ever used inputbin or any of the other 'chunk' type inputs for very simple comms, usually only while testing. Otherwise I always use buffered serial input, with an ischarwaiting .. inkey sequence to get data one byte at a time, and do all the parsing into chunks myself. Yes its much more work, but once you get it right, it can never fall over, get out of sync, or do any of the other horrible things serial input is prone to.
But that said, I cannot see why two successive inputbin statements as you have it should fail in normal use ( ie without external errors giving problems ).
Something wrong with this though:
Quote: |
Input s 'Initial synchronisation. That's sufficient when using a single inputbin transmission!!
do
loop until s="A"
|
Should that not be:
Code: |
do
input s
loop until s = "A"
|
else the input is only read once.
If you dont use buffering, then a read of the uart clears the uart receiver ( a 1 byte buffer ) at each read. That must work. Inputbin when receiving an array just reads the uart in a loop for as many bytes as there are in the array, again that obviously works for one inputbin, so it must also work for the following one too. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Tue Jan 12, 2016 12:25 am Post subject: |
|
|
The post was duplicated - I deleted this copy.
Last edited by Meister on Tue Jan 12, 2016 12:29 am; edited 1 time in total |
|
Back to top |
|
|
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Tue Jan 12, 2016 12:26 am Post subject: |
|
|
Adrian:
the input code was indeed as you had suggested.
As I said, this - employing the two printbin/inputbin - drove me crazy. I have no idea why the two subsequent inputbins behave that strange. The first Daten1 reflects the changed sent data, the second Daten2 either got all over zero's or was the same as the first one - but without the "A"CRLF that always was present in the first inputbin data - although "A"CRLF was sent only once upon startup and never again. Since all of my experiments involved changes in two programs, it was finally hard to recover which combination caused which peculiarity. However, I checked with a LA that the two chunks were sent correctly (sending the sequences 1 2 .... for the first printbin and some different series for the second printbin).
So, I am quite sure that this will never work - at least with my setup.
I gave up and stayed with 127 word transfers which does work partially correctly, except for the fact that the first six bytes in the received Daten(I) are always wrong, keeping the same values even when the data changed. So instead of transmitting 127 words there are only 124.
I use Compiler version 2.0.7.9, Compiler build 2.0.7.9.004. There had been some issues with Dim in 2.0.7.9. I am just thinking about that.
Which version are you using?
I you could post a working example for this problem it would be a big help.
Best regards, Meister |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Tue Jan 12, 2016 1:04 am Post subject: |
|
|
I cant really show you a working example of how I would do this. As I said, I almost never use inputbin in this way. I can show you how I do it with SNAP protocol, but its quite a lot more complex.
I posted this a long time ago about how I use SNAP protocol. This is just the receive section:
http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=6876&highlight=snap
and some discussion about how to handle errors.
Maybe you could try something like this:
Code: |
do
Input s 'Initial synchronisation for the first chunk
loop until s="A"
do
inputbin Daten1(1)
do
input s 'wait for sync to the second chunk
loop until s="B" ' the second sync byte
do
inputbin Daten2(1)
for i=1 to 254
print #2, Daten1(i) 'Monitor in terminal emulator
print#2, Daten2(i)
next
|
I dont know if this helps, just an idea to separate out the two data chunks.
I use Bascom version 2.0.7.9.004 too. Never noticed a problem, but then my way of doing things never uses inputbin.
If you stick with inputbin, I would suggest you do it with byte arrays, rather than words or anything else. Then use overlays if you want to convert to longer representations for external use. That way at least a single byte error tends not to corrupt the whole chunk. When you use words, think about what happens when one byte in the word has a data glitch, so that byte is dropped, putting every succeeding byte in the wrong place, and upsetting the count for the receive loop, which probably affects the next chunk, somewhat like you are seeing. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
toto
|
Posted: Tue Jan 12, 2016 10:35 am Post subject: |
|
|
Hello AdrianJ,
I have a long time a program run with ischarwating and inputbin, it works good, but in noisy environments some time it freeze on inputbin an cause the WDT to reset the micro,
unfortunately, the Inputbin does not support the ability to define a "Timeout"
I must say that the same program run with version 2.0.7.2 and when i compile it with version 2.0.7.8 i must after ischarwaiting write a waitms 3 to work
I began by trying to experience the same program with "Inkey". It works, but it happened several times that the program stops treat Interrupts, in this case the
Watchdog not actived, but causes other problems in my application. I think that perhaps the lot of noise originate the constant busy of the Inkey so that the other
interrupts donīt treated. Anyone have experience problems like this?
I have write allready to suppot, and hope Mark can help
Regards
toto |
|
Back to top |
|
|
AdrianJ
Joined: 16 Jan 2006 Posts: 2483 Location: Queensland
|
Posted: Thu Jan 14, 2016 12:33 am Post subject: |
|
|
@toto
Noise enough to stop the processor from responding to interrupts is BAD !
That suggests the noise spikes are at least well over the Vcc or below ground, causing the internal diodes to switch on and try to pass the spikes to either ground or Vcc. Operating like this is a recipe for disaster.
You must find a way of filtering or limiting the spikes before they get to the processor. No software will work properly with that going on.
My general practice is that ALL signals from the processor to the outside world go through some sort of buffer chip or even just transistors, together with capacitor/resistor bypasses to limit the currents and voltages to the rails, well before the signals get to the processor. There should be no direct connection from any processor line to the outside, even to a switch mounted 5 cm away, if its outside the box and shielding.
When you have done all that, then you can think about how to organise the software to cope with the remaining noise causing unexpected digital levels appearing on the port lines. That can be any combination of multiple sampling to ignore short spikes, or long term averaging, or whatever the application needs. _________________ Adrian Jansen
Computer language is a framework for creativity |
|
Back to top |
|
|
Evert :-)
Joined: 18 Feb 2005 Posts: 2156
|
Posted: Thu Jan 14, 2016 9:09 am Post subject: |
|
|
A function that's not used a lot but is there a long time. $SERIALINPUT
With this you can make your own "inputbin" etc. including timeout and >255 bytes.
Have fun.
Edit: Sorry, is only suitable for input and not for inputbin. _________________ www.evertdekker.com Bascom code vault |
|
Back to top |
|
|
Meister
Joined: 27 May 2010 Posts: 319
|
Posted: Thu Jan 14, 2016 10:37 am Post subject: |
|
|
After all, hopefully somebody investigates the "Inputbin".
I had contacted support, but no answer yet. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|