View previous topic :: View next topic |
Author |
Message |
chris101
Joined: 01 Sep 2005 Posts: 46
|
Posted: Sun Dec 06, 2015 10:54 am Post subject: Emulate 24C02 with Mega328P and send data to RC522 RFID |
|
|
Hi All,
I have a commercial device that uses an 24C02 eeprom to store data in. Is it possible to replace that 24C02 with an Mega328P, that can then emulate the 24C02 and send the data received on to an RC522 RFID chip?
Where should I start?
Best regards,
Christian
(BASCOM-AVR version : 2.0.7.8 ) _________________ Best Regards from.
Christian |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sun Dec 06, 2015 11:40 am Post subject: Re: Emulate 24C02 with Mega328P and send data to RC522 RFID |
|
|
chris101 wrote: | Is it possible to replace that 24C02 with an Mega328P, that can then emulate the 24C02 |
Either use the I2CSLAVE Library, or program your own slave I2C routines, standard built in Bascom routines support I2C only in master-mode.
Quote: | send the data received on to an RC522 RFID chip |
Most times RFID's are read, while reader/writer HW exists, in this forum there is only one thread about RC522, and it's about reading.
But one thing's for sure: if you have to ask the way you do, this isn't anything for you anyway. |
|
Back to top |
|
|
chris101
Joined: 01 Sep 2005 Posts: 46
|
Posted: Sun Dec 06, 2015 12:32 pm Post subject: |
|
|
WOW. That must be one of the most rude answers I have ever read! If everybody in the World was thinking like you we would all still be in the stoneage.
If you don't have anything positive to say or contribute with, please don't post in this thread. _________________ Best Regards from.
Christian |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sun Dec 06, 2015 1:36 pm Post subject: |
|
|
chris101 wrote: | That must be one of the most rude answers I have ever read! |
You must live in a cave then.
Quote: | If everybody in the World was thinking like you we would all still be in the stoneage. |
I have to disagree. If everybody would have shoved own brainstorming onto others, then we would be nowhere now.
The more as essential info was hidden from you, like purpose of the approach, type/name of the "commercial device", a.s.o.
Something commonly considered unkind in forums.
It's not the answerer's duty to pull out the worms from the TO's nose, it's duty of the TO to provide this info in advance.
Quote: | If you don't have anything positive to say or contribute with, please don't post in this thread. |
In fact I did write positive and useful things, only you can't understand and that's why my statement is true:
If you have to ask this way, and if you're that little prepared before asking, this stuff goes far over your head.
Ok, to prove my point:
First I've pointed you to the primary step, which is creating a I2C slave, able to emulate mentioned EEProm.
This is a feat already, as it depends on the "commercial device" and how I2C, especially timing is handled by its main processor.
Secondly, I've pointed you to the forum's search function, so you can do now, for what you was to lazy before: look up "RC522".
Even if you would be able to master the first feat, you need to send out the derived data.
Here comes the next question, which you should have already answered in your opening post: what type of RFID chip should be used, and why would you want to send data, instead of receiving?
You only got the correct answers to your question, so I don't understand your complaints. |
|
Back to top |
|
|
bzijlstra
Joined: 30 Dec 2004 Posts: 1179 Location: Tilburg - Netherlands
|
Posted: Sun Dec 06, 2015 5:54 pm Post subject: Not a bad idea |
|
|
Some people may have a less than eloquent way of expressing themselves – it may even be offensive, but they are still entitled to do so. They have the right to express their own opinions and we have the right and will power to choose our responses.
I wonder if the initial question was that bad. Looks to me a kind of challenge to get it working. Perhaps split it up, get the i2c eeprom emulation working and after that figure a way how to transfer the data wireless to another device.
Have fun,
Ben Zijlstra |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sun Dec 06, 2015 6:49 pm Post subject: Re: Not a bad idea |
|
|
bzijlstra wrote: | Some people may have a less than eloquent way of expressing themselves – it may even be offensive, but they are still entitled to do so. They have the right to express their own opinions and we have the right and will power to choose our responses. |
Ben, neither you need to justify my, nor the TO's response.
Quote: | I wonder if the initial question was that bad. |
Let's say the quality of the question was at a standard low level seen in many forums.
The TO only went nuclear, as I've doubted his competence to get this - also imo challenging - project running.
If somebody wants to build a car, he should already know how to unscrew a wheel, thus my judgment.
What he obviously did not understand: a better carved out question, more provided info and this way showing more respect for the ones to read and reply to his request, would have also earned him a better and more respectful response.
In this latter case I would have even suggested to build a device to sniff the transfered data, as obviously it doesn't need to be altered.
But boy, this actually would be a real challenge then. |
|
Back to top |
|
|
chris101
Joined: 01 Sep 2005 Posts: 46
|
Posted: Sun Dec 06, 2015 7:44 pm Post subject: |
|
|
Don't feed the troll !!!
Just because MWS doesn't understand the question, he thinks he's a guenius.
MWS your on my ignore list, please don't post in ANY of my threads again.
@Ben thanks for the answer _________________ Best Regards from.
Christian |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Sun Dec 06, 2015 9:50 pm Post subject: |
|
|
chris101 wrote: | Just because MWS doesn't understand the question |
ROTFLMAO. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Sun Dec 06, 2015 10:21 pm Post subject: |
|
|
Please let the topics be about BASCOM-AVR and the connected hardware.
Here is a sample for twi/usi. it gives an idea of how to do it.
Code: |
'-------------------------------------------------------------------------------
' (c) 2004-2015 MCS Electronics
' This demo demonstrates the USI I2C slave and emulates an EEPROM chip
' This is part of the I2C Slave library which is a commercial addon library
' Not all AVR chips have an USI !!!!
'-------------------------------------------------------------------------------
' This is a simple sample. the master sends the address of the slave, the WORD address
' of the memory location, and a byte to store or read
'------------------------------------------------------------------------------
' The matching master code to write
' i2cstart : i2cwbyte &H40 : i2cwbyte low(address) : i2cwbyte high(address) : i2cwbyte value : i2cstop
' The mathing master code to read
' i2cstart : i2cwbyte &H40 : i2cwbyte low(address) : i2cwbyte high(address) : i2crepstart : i2cwbyte &H41 : i2cRbyte value, nack : i2cstop
'See also the eeprom_master.bas
$regfile = "attiny2313.dat"
'$regfile = "attiny85.dat"
$crystal = 8000000
$hwstack = 44
$swstack = 16
$framesize = 28
config CLOCKDIV=1
'I2C pins on tiny2313 connected like :
'PB5 SDA
'PB7 SCL
'I2C pins on tiny85 connected like :
'PB0 SDA
'PB2 SCL
config BASE=0 'arrays start at address 0
Const Cprint = 0 'make 0 for chips that have NO UART, make 1 when the micro has a UART and you want to show data on the terminal
#if cPrint
Config Com1 = 19200 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
print "USI DEMO"
#endif
config usi = twislave , address = &H40 'bascom uses 8 bit i2c address (7 bit shifted to the left with one bit)
dim epr(128) as Eram byte 'for easy access to the memory
dim wAdres as Word, bValue as Byte
dim bAdresL as Byte at Wadres overlay 'overlay with wAdres LSB
dim bAdresH as Byte at Wadres+1 overlay 'overlay with wAdres MSB
'do not forget to enable global interrupts since USI is used in interrupt mode
enable interrupts 'it is important you enable interrupts
do
! nop ; nothing to do here
loop
'The following labels are called from the library. You need to insert code in these subroutines
'Notice that the PRINT commands are remarked.
'You can unmark them and see what happens, but it will increase code size
'The idea is that you write your code in the called labels. And this code must execute in as little time
'as possible. So when you slave must read the A/D converter, you can best do it in the main program
'then the data is available when the master requires it, and you do not need to do the conversion which cost time.
'A master can send or receive bytes.
'A master protocol can also send some bytes, then receive some bytes
'The master and slave address must match.
'the following labels are called from the library when master send stop or start
Twi_start_received:
#if cprint
Print "Master sent start or repeated start"
#endif
Return
Twi_stop_received:
#if cprint
Print "Master sent stop"
#endif
Return
'master sent our slave address and will now send data
Twi_addressed_goread:
#if cprint
Print "We were addressed and master will send data"
#endif
Return
Twi_addressed_gowrite:
#if cprint
Print "We were addressed and master will read data"
#endif
Return
'this label is called when the master sends data and the slave has received the byte
'the variable TWI holds the received value
Twi_gotdata:
#if cprint
Print "received : " ; Twi ; " byte no : " ; Twi_btw ; "-"; usidr
#endif
Select Case Twi_btw
Case 1 : bAdresL=TWI 'first byte is LSB
Case 2 : bAdresH=TWI 'second byte is MSB
case 3 :
#if cprint
print "address:" ; wAdres
#endif
epr(wAdres)=twi 'write to eeprom in case we receive a third byte which should only happen when we write to the slave
End Select
'if you want to auto inc wAdres, use this code instead:
' Select Case Twi_btw
' Case 1 : bAdresL=TWI 'first byte is LSB
' Case 2 : bAdresH=TWI 'second byte is MSB
' case else : epr(wAdres)=twi 'write to eeprom in case we receive a third byte which should only happen when we write to the slave
' incr wAdres
' End Select
Return
'this label is called when the master receives data and needs a byte
'the variable twi_btr is a byte variable that holds the index of the needed byte
'so when sending multiple bytes from an array, twi_btr can be used for the index
Twi_master_needs_byte:
#if cprint
Print "Master needs byte : " ; Twi_btr
print "address:" ; wAdres
#endif
twi=epr(wAdres) 'return the data from EEPROM
'when you want to support auto adres increase add this :
'incr wAdres
Return
|
_________________ Mark |
|
Back to top |
|
|
chris101
Joined: 01 Sep 2005 Posts: 46
|
Posted: Sun Dec 06, 2015 10:41 pm Post subject: |
|
|
Hi Mark,
Thank you very much for your answer. For this sample code to work I would need to buy the "I2CSLAVE Library" right? Does that library support the Mega328P ? It looks very interesting _________________ Best Regards from.
Christian |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Sun Dec 06, 2015 10:44 pm Post subject: |
|
|
yes you would.
it supports soft i2c for some ancient atmel chips, twi slave for chips like m328, usi slave that was used for the sample, and xmega for xmega twi slave.
have a look at the help at config twislave _________________ Mark |
|
Back to top |
|
|
|