Here are todays pictures.
Keep in mind, none of the cables are tidy, or cut to length yet because the cabinet isnt built right this minute.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Great !
All we need now is the schematic :lol:
Making dinner (French quisine time), will be back in a few hours.
cheers
↧
↧
BASCOM-AVR : DS1307 xMega issue : REPLY
Changed to 4.7K Resistors, I was using 1K resistors for some strange reason. Its too strong for 3.3V Even though my 128K eeprom worked, the DS1307 did not.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Bedtime here.
Here is something to chew on:
[code:1:0a20d8a1ee]
' ******** scanner_framework1.bas for Techknight Bascom forum ******************************
' Since I do not know how the led matrix is connected with the Cat4016, I adapted
' my program to get it as close as possible to what I think you designed yours
' Note that this code is for a Mega328P, not your Mega8
$crystal = 18432000
$regfile = "m328pdef.dat"
$hwstack = 80
$swstack = 20
$framesize = 40
'For BT module on UART
Config Com1 = 19200 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
Dim Tile_command As String * 20
Cat4016_clk Alias Portb.5 'SCK
Cat4016_data Alias Portb.3 'MOSI
Cat4016_strobe Alias Portd.7 'just an I/O pin
Cat4016_enable_output Alias Portd.6 'OC0A
Rowsel_a Alias Portc.0
Rowsel_b Alias Portc.1
'portB.2 is /SS and we don't want surprises when using SPI to send serial data to the CAT4016's
Set Portb.2
Ddrb = &B11111111
Reset Rowsel_a
Reset Rowsel_b
Dim Select_a_not_b As Bit
Ddrc = &B00000111
Ddrd = &B11111110
'Timer0 will generate an interrupt every 0.888 millisecond ; 1.125 kHz
'and generates a PWM for Res_Red on OC0A
'Mode 3 ; Fast PWM, Clear OC0A on match, set at bottom ; /64 clock
Tccr0a = &B10000011
Tccr0b = &B00000011
On Timer0 Scanner
On Compare0a Disable_pwm0a Nosave
Enable Timer0
'This interrupt will set the row multiplexer to 7 (which is not used, so all leds dim)
'CBI TCCR0A,COM0A1 (and CBI TCCR0A,COM0A0) to force OC0A off
Intensity Alias Ocr0a
'Matrix in ram
Dim Row0(16) As Byte
Dim Row1(16) As Byte
'This may come in handy
Dim Seq_row(32) As Byte At Row0(1) Overlay
Config Spi = Hard , Interrupt = Off , Data Order = Lsb , Master = Yes , Polarity = High , Phase = 1 , Clockrate = 4 , Noss = 1
Set Spsr.spi2x
Spiinit
Enable Interrupts
'Set intensity
Intensity = 65 'safe value to start with
Main:
Do
Input Tile_command
'and process the received data
'There is nothing else that needs to be done in Main
Loop
End
'-----------------------------------------------------------------------------------
'------------------------ Interrupt Handlers -------------------------------
'-----------------------------------------------------------------------------------
Disable_pwm0a:
cbi Tccr0a,com0a1
Return
'Note to self: I decided to use this mechanism as it prevents a glitch on OC0A
'Although harmless, I found it more neat to handle it like this
'-----------------------------------------------------------------------------------
Scanner:
'stop driving anode leds with AO4441
Reset Rowsel_a
Reset Rowsel_b
Toggle Select_a_not_b
If Select_a_not_b = 1 Then
Spiout Row0(1) , 16
Else
Spiout Row1(1) , 16
End If
'Now transfer the shifted-in data to the outputs of the SRs
Set Cat4016_strobe
nop
Reset Cat4016_strobe
Set Tccr0a.com0a1 're-enable fast PWM
'Turn on one bank of AO441's @ anode leds a or b
If Select_a_not_b = 1 Then
Set Rowsel_a
Else
Set Rowsel_b
End If
Return[/code:1:0a20d8a1ee]
Have fun !
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Wow! Impressive project.
A few thoughts:
A big concern regarding the trashed data is this:
Plons mentioned that running both the Transmitting and the Receiving micros on a non-baudrate friendly frequency is fine, as they will both be out of spec, either high or low.
That is usually the case, but in this case you have different hardware, an Xmega and A Mega, at the ends of the communications link.
Those have very different hardware USART modules within them.
Therefore, it is wise to specifically check the baudrate error at each end of the link, based upon that micro's clock frequency.
You have an Xmega transmitting to a Mega, so one has to look carefully at the baudrate and make sure it is within spec at both ends.
If the baudrates don't match, (within tolerance, typically 2% IIRC), then you can't possibly get reliable comm's.
For the Xmega128A, at 32 MHz:
115.2K BR gives < 1% BR error
230.4K BR gives < 1% BR error
So, IF you are using an external Crystal and the PLL to get the 32 MHz clock then the transmitting baudrate will be right on.
Know that the Xmega's can use an external Xtal of up to 16 MHz, (so don't use a 32 MHz Xtal).
Use a 2, 4, 8, 16 MHz Xtal and the PLL to multiply the clock frequency.
Know that the Xmega series has a 32 MHz RC Int Oscillator.
It is far more accurate from the factory than the Mega and Tiny processors are spec'd at, but for reliable comm's I'd still use an external Xtal to keep it simple.
(You can use the 32 kHz clock to calibrate the 32 MHz clock, but that is a bit tricky, AND it might not work on the original Xmega128's, you would have to look carefully at the version number of the Xmega128 and at the Errata page for the series...)
KISS and use an external Xtal.
When you want to build a million of them we can talk about calibrating the internal Osc and saving a few pennies...
And then we can talk about environmental temperature compensation....
Anyway, back on track:
Mega 8 with a 14.7456 MHz Xtal:
115.2 K BR gives 0 % BR error
230.4 K BR gives 0 % BR error
Again, that is perfect. The Xmega and the Mega, both with different hardware USARTS inside of them, and with different clock frequencies, can communicate without any significant baudrate error.
Now, what about the Mega 8 at 16 MHz:
With U2X = 0:
115.2 K BR gives -3.5 % BR error
230.4 K BR gives 8.5 % BR error
Wow, both are well beyond 2% BR error, especially the 8.5 %.
That would never reliably communicate with the Xmega with its accurate baudrate.
With U2X = 1:
115.2 K BR gives 2.1 % BR error
230.4 K BR gives -3.5 % BR error
Again, both outside of the 2% baudrate error limit.
So, short version:
I'd use the 14.7456 MHz Xtal for the Mega 8's for now, to get reliable communications with the Xmega running at 32 MHz, and either 115.2 K or 230.4 K baud rate.
I'd use an external crystal on the Xmega and use the PLL to get 32 MHz.
(Unless you either manually or through software calibrate the internal 32 MHz RC Osc., which will work for your office's room temp, but will drift with temperature)
Next:
Does the Xmega send the data to Tile #1 which then re-transmits the data to Tile #2, which then re-transmits the data to Tile #3....Tile #21
or are they all on the same bus in parallel, (multi-drop)?
I suspect the latter setup, but either would, I think, be possible, (more hardware to do repeater style...).
I think you might have mentioned having a 485 breakout box, so my suggestion of building one is unnecessary.
I think you said you see good data on the bus.
It would be very helpful, from a trouble shooting perspective to have a single LED on each Mega 8 (each tile), on the back side of the board, that lights up (briefly) when that particular Tile receives a message for that particular Tile. It would make it easy to trouble shoot the communications using some simple test programs to send data to Tile 1, wait 1 sec, repeat several times; and then send data to Tile 2, wait a second and repeat a few times, ...Tile #21. You could then watch Tile 1 through 21 sequentially flash there LED a few times, in sequence. If any Tile flashed out of sequence, then you would know there was a comm's problem.
If you have a spare I/O pin on the Mega 8's you could easily add that on, and reflash each one with new code to flash them briefly upon receipt of their address.
(Or, better, upon receipt of their address and a valid Checksum byte, see below)
Next:
I think USARTS are fine for sending binary data, BUT you have to packetize your data.
Otherwise, as mentioned above, data and addresses can get confused, (which could be part of your garbage data display problem).
I don't recall your having described how you transmit your data, and how you decode it within the Mega 8s.
If this is old news to you, sorry, just say so.
Otherwise, using a simple packet allows each Tile to recognize its data, and with minimal overhead to verify the data.
A simple packet might be along the lines of:
"<" Start of Packet Character, the Mega 8 watches for this to signify the start of the packet, and to synch on it.
ADDR 1 Byte Address bytes for each Tile, 0 - 99, for example.
ADDR 2 Byte
DB 1 Data Byte one, (upper byte, for example)
DB 2 Data Byte two, (lower byte)
CheckSum A checksum byte
< AD AD DB DB CS
< AD AD DB DB CS
...
The Checksum is simply the 8-bit addition of the prior Address and data bytes, ignoring any carry out.
The Xmega calculates the Checksum and sends it with each packet.
The Mega 8's look for a "<" Start of Packet Character, ignoring anything until they see it.
Then they read in the data, (AD AD DB DB CS).
Then they calculate the Checksum based on the address and data bytes they received, and compare it to the transmitted Checksum.
If they match then one assumes that the Mega 8 received the data correctly.
If the Address matches that Tiles's address, then it acts on it, otherwise it ignores it.
If the Checksum that was calculated doesn't match the Checksum that was received, then there is an error in the packet, and that packet is ignored.
(Some systems would have the target Tile send an ACK, but it sounds like you are using one way comm's only)
With only 21 Tiles a Message sent to Tile 99 could mean all Tiles turn OFF.
A message to Tile 98 could mean All Tiles turn on for 2 Seconds, then turn off, (assuming your power supplies can handle it), (Test pattern).
If you implement Tile-based intensity, several "Tile" Commands could tell the entire board to use dim, 2/3's, or full intensity, etc.
If you have a "spare" Tile PCB, then perhaps you could add it to the bus, but its code is in "promiscuous" mode, where it watches for traffic for any and all nodes, and uploads it to a PC running a terminal program. It can also send a message for any partial packets or error containing packets it receives. Ideally you will see a screen full of only good data, with the tiles accessed sequentially with the desired test data.
Last comment, I am a big proponent of interrupt driven, ring buffered serial communications.
There are several examples in the Samples files.
It takes a while to understand it, and get it working, but it is WELL worth it.
An interrupt driven USART uses very, very little processing time to receive the data and stuff it in the buffer.
When a byte arrives, the ISR fires, and the data is stuffed into the buffer, the buffer pointers are updated, and the ISR exits.
All very fast, and already debugged.
You just have to tell Bascom to use it, you don't have to write it all yourself.
Without that, with your high speed comm's one could easily imagine a Mega 8 missing a data byte coming down the high speed data bus.
I'm not a big YouTube user, but when you get it working you will definitely have to post a video of it working!
JC
↧
↧
BASCOM-AVR : Serialin and data corruption : REPLY
@ JC
WOW, Jay :) What a post. Good point about the different architectures. And I fully agree on the KISS :P
Buffered Serial In and Out: At high baudrates the effect is less. Mark explains it in the Help. And yes, I am a fan too.
High baudrates ? Only when it makes sense.
About the communication protocol: Good suggestions. But OP sees flickering tiles, and HW-wise it's not stable. So IMO he needs to fix that first. Exactly like you recommended in your earlier post: take one step at a time.
@ Techknight
Without schematics (last hint) it's hard to give solid recommendations. But from the pictures: it looks like the ribboncables at the top are supplying 5V to the Tile. Phew. That's not good. Use your scope and look at what happens on the groundlead when a tile is displaying. The more leds, the more noise and plain voltage level shifts.
Oh well, you have plenty on your plate now.
Cheers !
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Ribbon cable is the only way I know of to feed power to the tiles. Keeping things around for molex connectors and cabling (i did in the past) was a nightmare, and ribbon is so much easier to make and its already pre-existing inventory. So I have the cable split up into Odd/Even power/ground.
Anyways.... KISS, whats that? Surely your not talking about the band?
But let me streighten something out. Once I switched to 16Mhz crystals, all COMM problems went away. the tiles are now functioning correctly. If I put the 14.7456, or 18.432Mhz crystals back it, it all goes to hell.
Funny thing, I use the bluetooth to communicate back to the PC at 57,600 baud for bootloading, and updating the sign. That works perfect with no error. Go figure!
↧
BASCOM-AVR : Serialin and data corruption : REPLY
Schematic of the tile.
↧
BASCOM-AVR : Serialin and data corruption : REPLY
[quote:6b48c03327="techknight"]
Anyways.... KISS, whats that? Surely your not talking about the band?
[/quote:6b48c03327]
Keep It Stupid Simple
https://en.wikipedia.org/wiki/KISS_principle
↧
↧
BASCOM-AVR : Serialin and data corruption : REPLY
And it's not a kiss either :D
One more thing on Buffered Serial In: for that to use, you need to define a terminating character. Usually ASCII 10, <LF> That rules out the use of binary data as such.
If the com works fine now, not using a crystal, probably results in mis-comm when the billboard is out in the sun.
I wouldn't go there. Solve the issue for now and ever. Yep, I needed to learn that too.
↧
BASCOM-AVR : Bascom AVR and windows 10 compatibility ? : NEWTOPIC
Is BascomAVR compatible with Windows 10 ?
[b:0149abdb38][color=red:0149abdb38](BASCOM-AVR version : 2.0.7.8 )[/b:0149abdb38][/color:0149abdb38]
↧
BASCOM-AVR : Serialin and data corruption : REPLY
HW:
If the AO4441's run hot, replace them with FDS4435A. Pin compatible AFAIK.
I understand why you used that Push-Pull driver: that works fine with 8 to 12V supply voltage, but here the outputswing is 5 - 2x 0.7V.
Rds on of the AO4441 is around 130 mOhm when driven with Vgs = - 4.5V. Close huh ?
↧
BASCOM-AVR : I2C: Writing / reading a Si5351 clock generator IC : REPLY
Hello.
Could you share the code for Si5351A control?
↧
↧
BASCOM-AVR : Write string variable to the DATA EEPROM : REPLY
Hello,
And how to write strings to external eeprom like 24c64 ?
Regards
toto
↧
BASCOM-AVR : Serialin and data corruption : REPLY
[quote:6fdea16903="Plons"]HW:
If the AO4441's run hot, replace them with FDS4435A. Pin compatible AFAIK.
I understand why you used that Push-Pull driver: that works fine with 8 to 12V supply voltage, but here the outputswing is 5 - 2x 0.7V.
Rds on of the AO4441 is around 130 mOhm when driven with Vgs = - 4.5V. Close huh ?
The CAT4016: Rset is 680 Ohm in your design. So each led is driven with 80+ mA. Can your leds handle that @ 50% duty cycle ?
[quote:6fdea16903]In the future I can probably just clock the xMega at 3.6864Mhz, and use the PLL x8. Itll be a little under 32, but should be proper for bauds? yes? [/quote:6fdea16903]YES ! :)
And use the 14.7456MHz for the Mega8's.
About ribbon cable for power: I know it's convenient. And you're lucky that the RS485 brings in 6 extra conductors. What AWG is the ribboncable ?
Edited (again)[/quote:6fdea16903]
They get warm, that was the best I could come up with. My tile revision 1 was 12V, as I was using that for 1 to 16 mux. That didnt work out at all, hence the redesign, however I kept the same push pull configuration.
the LED max current rating is 70mA, I figured if I set hte current at 80mA, dividing it between the two LEDs in multiplex would knock it down to roughly 40mA.
↧
BASCOM-AVR : esp8266 web server : NEWTOPIC
Hello!
How can I contact the esp8266 with bascom avr to make web server Page on the net to control turn ON/OFF the 2 lamp
And send data to the 3 temperature sensors :?:
[b:c933391711][color=red:c933391711](BASCOM-AVR version : 2.0.7.8 )[/b:c933391711][/color:c933391711]
↧
BASCOM-AVR : Serialin and data corruption : REPLY
My ribbon cables are 28AWG. With 5 + 6 wires this boils down to 0.88 sq mm.
...
Okay, time will tell if that's enough.
↧
↧
BASCOM-AVR : Analog comparator interrupts : REPLY
there are 3 interrupts associated with each analog comparator.
ACA_AC0
ACA_AC1
ACA_ACW
you use them as all other interrupts :
ON ACA_AC0 ISR_ACA_AC0
ENABLE ACA_AC0
enable interrupts
↧
BASCOM-AVR : Serialin and data corruption : REPLY
well it isnt getting hot under load.
↧
BASCOM-AVR Old versions : esp8266 web server : REPLY
Hello studet
All that you need for a web server is here http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=12358
While the small wireless module is good you will have a lot of work to do.
The easy way is to use the W5100 board and a wireless access point you then get encryption with a user name/password
The W5100 board takes a mini SD card to put your web pages on.
I have written all the code it can read the temperature using thermistor type probes
As it returns raw data via the web pages you can display that data any way you want by making your own web pages
and putting them on the SD card
I have already posted sample pages to work with
I am still working now on the server interfacing it with my solar inverter.
Regards Paul
↧