Yes, and yes. Also the RS-485 is hardwired to transmit all the time. its a single-direction bus.
I removed the 18.432 and 14.7456 crystals, and stuck 16Mhz crystals on the Tiles, and that seems to have fixed it for 115,200 baud. My guess is the 0.1% Error on the ATXmega128 was just enough to break the whole system.
I have a total of 21 tiles hooked up.
So now thats fixed, they all change instantly instead of percolating. But, Tile number 13, and 21 dont recieve data. And its an addressing issue, because I can change Tile #1 to address of 13, and 21, it does exactly the same thing. it doesnt get data 90% of the time, every once in awhile it does update.
So, that tells me I have to do some further looking into the code to figure out why those 2 addresses break the program ;-)
↧
BASCOM-AVR : Serialin and data corruption : REPLY
↧
BASCOM-AVR : Serialin and data corruption : REPLY
[quote:c7fe201205="Plons"]Are you sure about the hardware ? Current limit resistors ?
An AVR getting warm sounds supicious.
If you don't have an external crystal, the PLL at 32MHz has nothing to sync with. Yeah, the internal RC oscillator. But that's a poor reference for the PLL.
Your program spends a lot of time in the ISR. Bad practice. Set a flag in the ISR and do further handling in the main loop.[/quote:c7fe201205]
No, its me purposely warming it up and cooling it down to introduce drift.
↧
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Commercial PCB, or your own design?
I'm not familiar with RS-485, but is timing "critical" like with normal USART usage?
If so, why are you running on the internal RC Osc, instead of using an external crystal?
Additional hardware questions:
Do you have EVERY Vcc and the AVcc pin connected to V+ ?
Do you have all of the Grounds and AGround connected to Ground?
Do you have a 0.1 uF By-Pass cap across EVERY Vcc/Ground and AVcc/AGround pair of pins?
Are these caps mounted very close to the uC's body?
Many of my projects contain sub-projects, to help get the main project up and running.
You might want to use another micro to build an RS-458 decoder / breakout box with an LCD or PC interface and put it on the end of the RS-485 string.
Then you can monitor the RS-485 signal and make sure it is getting down the line correctly.
As you turn on lots of LEDs is your power supply up to the task?
Is your power supply voltage dipping low, (brown out), when you power up the LEDs?
Easy to eliminate this as a problem, while developing your project, but using separate power supplies for the micro and for the LEDs, (with a common Ground connection).
Can you simplify the system for testing?
If a PC sets the LED patterns, then remove that part of the code and hard code some simple patterns.
Why are you running the baud rate so fast?
For testing, can you slow it down?
So what if it flickers for now, you need to isolate the problem ( s ) and then decide how to resolve them.
It helps if you can reduce the project to a simpler system that works, then expand upon it.
Can you get an 8x8 matrix working, before you conquer the 16x16 matrix?
Start small and slow, and work upwards from there.
When the small and slow system works, use your O'scope to watch the interrupts and see how long they take, and hence how much time the Main Loop (etc) has to run.
As a last resort, consider migrating your project to an Xmega.
It gives you a 32 MHz clock, so LOTS more instructions / Second to work with.
It also gives you a priority interrupt controller, if needed.
And although significantly more complex (in my opinion), you have a DMA module that might be useful for auto-sending your output data.
The upgrade to the Xmega is a good option if micro throughput is truly the limiting factor.
Switching micros won't help if there is a fundamental flaw in the program structure and design.
JC
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Most of your questions will answer yes as far as the design requirements, decoupling, etc...
Also the system is of my own design, and they are seeed produced boards for me. Ran the gerbers, etc...
Power supplies are 320Watts at 5V. 3 of them. Its going to be a school LED sign.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
[quote:f7212e1f0f]I removed the 18.432 and 14.7456 crystals, and stuck 16Mhz crystals on the Tiles, and that seems to have fixed it for 115,200 baud. My guess is the 0.1% Error on the ATXmega128 at 32Mhz was just enough to break the whole system. But since 16Mhz, and 32Mhz is evenly divisible, both the tile and the master have error, and they match. So therefore, no error. Ponder that one for awhile. :-S [/quote:f7212e1f0f]
18.432 and 14.7456 crystals are baudrate crystals: 115200 bd is no problem with these crystals.
OTOH: 16 and 32 MHz are not the best choice for hi-speed 115200 bd USART. Look at the report the compiler generates: quite at the beginning it tells the deviation in %.
When Master and Tiles use the same clock, then of course there is no baud-mismatch between them. Lucky you :wink:
How do I explain the flag mechanism ? Hmm, I'll give it a try (not at my workdesk right now)
Attached a picture from an AVRcalc written by Kevin (AVRfreak)
↧
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Well 32Mhz is what the ATXmega uses, I thought it had a fractional divider to make it perfect. Guess not.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
A baud-error of 2.5% is the absolute max you can afford. The slewrate of the RS485 will take care of that tiny bit spare you have.
Also note that the Calculator suggests better crystal values.
Working on a demo program for flags and stuff
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Okay, here is an example that uses flags.
The interrupt handlers are done in the blink of an eye.
As long as the program lives in the Main loop, another interrupt source can interrupt Main and get serviced.
And even when an interrupt is pending, it's so quick that the waiting interrupt hardly realizes that it had to wait for let's say, 15us.
( I hope this listing looks good )
It's quite late at this side of the pond, so : have fun. I'll be back .... in 12 hours,
cheers
[code:1:c2a98858c5]Config Timer1 'etc .... 'for 1ms interrupts on overflow
'....
On Ovf1 Ovf1_int_handler
'etc
Enable Ovf1
Enable Interrupts
Dim Ms_counter As Word
Dim Ms_status As Byte
Ms_flag Alias Ms_status.0
Seconds_flag Alias Ms_status.7
Config Com1 = Com_speed , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
Config Serialout = Buffered , Size = 250
Config Serialin = Buffered , Size = 40 , Bytematch = 10 '<LF> terminates but <CR> is required for Input !!
Dim Cmd_string As String * 20
Dim Temp_string As String * 20
Dim Strl As Byte 'used for stringlength
Dim New_cmd As Bit
Set Ddrd.1 'for UART
Dim Tile_counter As Byte
Print "Start of Main Program"
Main:
Do
If Ms_flag = True Then
Ms_flag = False
'Spit out the data for the Tile as pointed by Tile_counter in ISR
'Preferably use HW SPI
'...
'....
End If
'Other tasks, but no Waits !
'This loop has to run fast
'Because we use Buffered Serial Out, this structure takes just a few 10's of us's
If Seconds_flag = True Then
Seconds_flag = False
Print "Another second wasted ;-) "
End If
'Command interpreter
'Every character that is typed by you is handled and stored
'Until a CR LF is found: then Serial0charmatch kicks in and informs Main
If New_cmd = 1 Then
New_cmd = 0
Select Case Cmd_string
Case "T5" 'Do something with Tile 5
'etc
End Select
End If
Loop
End
'****************************************************************
Ovf1_int_handler:
Set Ms_flag 'This informs Main
Incr Ms_counter
If Ms_counter = 1000 Then
Ms_counter = 0
Set Seconds_flag
End If
Incr Tile_counter
If Tile_counter > 16 Then
Tile_counter = 1
End If
Return
Serial0charmatch:
Pushall
Input Cmd_string Noecho
Clear Serialin0
Set New_cmd
Popall
Return
[/code:1:c2a98858c5]
↧
BASCOM-AVR : Serialin and data corruption : REPLY
That would work great for strings... But... not binary packets.
my tiledata is all in binary. Cant really byte match binary, because pixel data can accidentally trip it.
Back to the drawing board...
↧
↧
BASCOM-AVR : DS1307 xMega issue : REPLY
For battery backup just use two diodes. One from battery to vcc (ds1337) one from 3,3V supply to vcc.
Voltage drop caused by the diodes is no problem, because the chip works with a minimum of 1,8V.
I use the ds1337 with xmega for over 2 years now with battery - always a stable sytem.
↧
BASCOM-AVR : DS1307 xMega issue : REPLY
Real Time Clock Module DS1338
A Real Time Clock Module with battery backup using the easy to use DS1338 chip. The DS1338 is functionally the same as the popular DS1307 chip with the difference being that the DS1338 works at any voltage from 3V to 5V making it easy to use on either 3.3V and 5V systems without modification or logic level conversion.
Just my two Euro-cents
Ben Zijlstra
↧
BASCOM-AVR : mathematical equation : REPLY
Thanks [b:1c2eeb72cc][color=red:1c2eeb72cc]AdrianJ[/color:1c2eeb72cc][/b:1c2eeb72cc] ;Thanks [b:1c2eeb72cc][color=red:1c2eeb72cc]Duval JP[/color:1c2eeb72cc] [/b:1c2eeb72cc]
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Given the number of problems you ran into the last few weeks, could it be that your HW is damaged in an earlier state, by overvoltage, static electricity, wrong connection, etc ?
With such big panels (which look very nice), with beefy PSU's, wiring becomes an issue. Are you familiar with what's involved ?
UARTs are not for binary transport by design. There are ways and tricks to do it, X-modem protocol and such.
And if this is a one-mans project (you), there is the big risk of persisting in believing "I checked that, I know that should work, etc" Also thinking in circles is a risk in a one-mans project.
If fellow users ask questions, they do so because they are trying to help you: they invest time and effort. Take time to really read what they are saying, and give clear answers. That forces you to think and re-think, and prevents pre-mentioned persisting in what you THINK is right.
:wink: Lots of thinking. Makes me think of "Little John Henry, the thinking man", an American folksong, Brothers Four. 1960 ?
↧
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Yep, its a one man project. nobody else that works with me has a clue...
Anyways, I understand what your saying, and what you and others are asking are fundamental issues with anything. I have gone over the schematics 2 or 3 times but if I didnt realize a mistake then, I still dont now.
As far as ESD is concerned. Maybe? But overall it seems to work... the problem lies with communication. Either my implementation of it in code which you can see, or the hardware supporting it.
The tiles all have 10 pin connectors feeding 5V power from distribution PCBs that I have designed, which hook into the 5V power supplies using phoenix style connectors. There are 3 rows of tiles. Each row has its own power supply.
Also each tile has electrolytic, and ceramic decoupling bypass caps right at the connector. And of course all the ICs on the tile have their own decoupling caps. The filter caps are 3 470uf. Are they sufficient for the design? I dont know. Not sure how to run the math on it so I just guessed what I thought was good. I chose to use 3 instead of a single to keep the ESR down.
I am thinking high frequency switching noise is getting back to the power supplies because the master board is run off of 1 of the 3 power supplies. It keeps killing my DS1307, so I decided to say hell with it.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Okay, I see. Thanks.
Can you post a block schematic ?
I am confused on how the tiles are arranged. I count 24 elements in height, 48 wide.
Is it one led per plastic square element, or 4 ?
Monochrome ?
Tiles are 16x16 leds, right ? Is that 8x8 plastic elements, with 4 leds per element ?
What drivers are used for the leds ?
Max current per panel with all leds on ?
One Mega8 per tile ?
Killing the DS1307's is a clear sign of trouble, power-wise.
Maybe you can post a picture of the backside of the panel. Power distribution is what I'd like to see.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Keep in mind that [u:abf5fa6784]every[/u:abf5fa6784] packet send over the rs485 is handled by ALL the tiles. If the tile is doing something with the data will depend on the address.
This makes me curious about your protocol.
To get the data to the correct tile you need something like an address in your protocol, however if you send the data binary it could be possible that a part of the data stream looks exactly the same as the part with the address and therefore will trigger the wrong tile to do something with some garbage data.
Btw, very nice board on the picture. Looks fun the work on. :D
↧
BASCOM-AVR : Serialin and data corruption : REPLY
[quote:4a0ea5f29e="Evert :-)"]Keep in mind that [u:4a0ea5f29e]every[/u:4a0ea5f29e] packet send over the rs485 is handled by ALL the tiles. If the tile is doing something with the data will depend on the address.
This makes me curious about your protocol.
To get the data to the correct tile you need something like an address in your protocol, however if you send the data binary it could be possible that a part of the data stream looks exactly the same as the part with the address and therefore will trigger the wrong tile to do something with some garbage data.
Btw, very nice board on the picture. Looks fun the work on. :D[/quote:4a0ea5f29e]
Precisely, There in lies the problem.
↧
↧
BASCOM-AVR : Serialin and data corruption : REPLY
[quote:27eeb92af1="Plons"]Okay, I see. Thanks.
Can you post a block schematic ?
I am confused on how the tiles are arranged. I count 24 elements in height, 48 wide.
Is it one led per plastic square element, or 4 ?
Monochrome ?
Tiles are 16x16 leds, right ? Is that 8x8 plastic elements, with 4 leds per element ?
What drivers are used for the leds ?
Max current per panel with all leds on ?
One Mega8 per tile ?
Killing the DS1307's is a clear sign of trouble, power-wise.
Maybe you can post a picture of the backside of the panel. Power distribution is what I'd like to see.[/quote:27eeb92af1]
16x16 Tiles. 3 tiles high, 7 tiles wide.
the CNC machine cuts a hole every 4 LEDs instead of each and every LED otherwise ill burn the bit up.
Not monochrome, its 1-bit black and white. (well, red).
CAT4016 as the current Sinks. 8 of them. Then I am using AO4441 with some transistors for the gate drive as current source for column switching.
Max current needs calculated. I have no idea. Maybe 2 to 3 amps?
1 Mega8 per tile, 8 CAT4016s and 6 AO4441s, 3 paralleled per column drive. They get warm. The CAT4016s get pretty warm as well when fully energized.
DS1307 god only knows. Ive never had issues with that chip in any other design of mine, except for this one. Seems to eat them. I can disconnect all the tiles and remove all the heavy current consumption from that and still lose a DS1307, possibly from ESD. Dont know.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
So now I find myself building a schematic in my head, reading your description. I think I get the idea, but to get things straight I need to keep asking for confirmation of what I think the design looks like. Let's shortcut that, post a schematic of the tile to start with.
Three areas need to be tackled on tile-level: HW (power, multiplexing), SW Mega8 to ensure flickerfree multiplexing of the led matrix, and a communication protocol.
I recommend to take one step at a time.
Don't try to fix all the problems at the same time. As recommended by JC.
I did a simular project, with 7 x 238 leds , that's 1666 leds. 1:7 multiplex, 160Hz refresh for the complete tile (yeah, a very stretched tile it is), intensity control and no flicker whatsoever.
The hardware for the Tile is frozen, I presume ?
↧
BASCOM-AVR : Serialin and data corruption : REPLY
it is, yes. For this particular sign. It can change in the next run of things.
Best I can do right this second is the PCB layout.
↧