hi, all
we know that distinguish the deck board with 1-wire eeprom DS28E05, but firstly we must write the id to the chip,
how to write? crazyflie2 write or other tool ?
about deck board , how to write id into eeprom DS28E05 ?
-
justinleeyang
- Expert
- Posts: 186
- Joined: Mon Dec 28, 2015 5:07 am
Re: about deck board , how to write id into eeprom DS28E05 ?
(bump)
I'd like to write to identify my experimental decks automatically, too. Does anyone happen to have any utilities for writing to the DS28E05?
The main problem I'm having is that the DS28E05 only supports overdrive mode. I tried talking to it using the BusPirate, but the BusPirate doesn't support overdrive. I'm also looking into programming it from an Arduino, but I can't seem to find a 1wire library that supports overdrive either.
Next up is to program using the Crazyflie directly, which seems a little less than ideal (and slightly prone to accidentally overwriting EEPROMs).
Any ideas appreciated!
I'd like to write to identify my experimental decks automatically, too. Does anyone happen to have any utilities for writing to the DS28E05?
The main problem I'm having is that the DS28E05 only supports overdrive mode. I tried talking to it using the BusPirate, but the BusPirate doesn't support overdrive. I'm also looking into programming it from an Arduino, but I can't seem to find a 1wire library that supports overdrive either.
Next up is to program using the Crazyflie directly, which seems a little less than ideal (and slightly prone to accidentally overwriting EEPROMs).
Any ideas appreciated!
Re: about deck board , how to write id into eeprom DS28E05 ?
Hi,
We are using the Crazyflie to write the one-wire memories. There is no risks as long as you install only the deck you want to program. To program prototypes I am using the write-ow example: https://github.com/bitcraze/crazyflie-l ... rite-ow.py
One important point (and the main reason there is no gui/tab in the client to set the OW memory yet), is that writing the OW memory does not work if the Crazyflie has bluetooth enabled. So to write a one-wire memory the procedure is:
- Compile the crazyflie2-nrf-firmware project with "make BLE=0"
- Flash it "make BLE=0 cload"
- Modify the write-ow.py example to fit your data, run it
- You can read back the memory with the read-ow.py example
- If you want bluetooth back you can compile again the nrf firmware (make clean all) or flash the latest released firmware package.
We are using the Crazyflie to write the one-wire memories. There is no risks as long as you install only the deck you want to program. To program prototypes I am using the write-ow example: https://github.com/bitcraze/crazyflie-l ... rite-ow.py
One important point (and the main reason there is no gui/tab in the client to set the OW memory yet), is that writing the OW memory does not work if the Crazyflie has bluetooth enabled. So to write a one-wire memory the procedure is:
- Compile the crazyflie2-nrf-firmware project with "make BLE=0"
- Flash it "make BLE=0 cload"
- Modify the write-ow.py example to fit your data, run it
- You can read back the memory with the read-ow.py example
- If you want bluetooth back you can compile again the nrf firmware (make clean all) or flash the latest released firmware package.
Re: about deck board , how to write id into eeprom DS28E05 ?
Arnaud,
Thanks, that's perfect!
The risk I was talking about was flashing a special firmware onto the Crazyflie that forced an EEPROM program on boot, and forgetting that I had that firmware flashed and overwriting something. Being able to trigger it from the host side is much better.
I take it that the normal flow is that the nrf queries all the OW memories on power-up, caches all that, then enabled Bluetooth?
Thanks, that's perfect!
The risk I was talking about was flashing a special firmware onto the Crazyflie that forced an EEPROM program on boot, and forgetting that I had that firmware flashed and overwriting something. Being able to trigger it from the host side is much better.
I take it that the normal flow is that the nrf queries all the OW memories on power-up, caches all that, then enabled Bluetooth?
Re: about deck board , how to write id into eeprom DS28E05 ?
Yes this is correct, the memory are read before switching ON the bluetooth stack.
The problem is that reading these memories requires real-time behavior of the software to generate and read data bits. As soon as we switch ON the bluetooth start it will take time from the CPU using the highest priority interrupt and so we cannot guanrantee real-time response anymore. There is two solution I imagine to solve the problem:
- We manage to switch OFF the bluetooth stack when writing the memory. That would be the simplest but when I tried it froze the CPU when disabling the stack ...
- We can use the 'timeslot' mechanism of the stack to transfer bits: we are currently sharing the radio with bluetooth using timeslot mechanism, it means that the stack guarantee us full access to the radio and the CPU for some time (currently set to 1ms) extendable as long as possible. The problem with that is that it would means breaking-up read/write operation of the memory in small asynchronous chunk (there is no OS in the nrf51 so this would need to be implemented as a state machine). This would be the best solution but it not obvious to implement.
We have never gotten the time to get into solving this problem yet. When it is solved we can add a GUI to program the memories to the client and do fun stuff like adding driver data to the memories to personalize each deck.
/Arnaud
The problem is that reading these memories requires real-time behavior of the software to generate and read data bits. As soon as we switch ON the bluetooth start it will take time from the CPU using the highest priority interrupt and so we cannot guanrantee real-time response anymore. There is two solution I imagine to solve the problem:
- We manage to switch OFF the bluetooth stack when writing the memory. That would be the simplest but when I tried it froze the CPU when disabling the stack ...
- We can use the 'timeslot' mechanism of the stack to transfer bits: we are currently sharing the radio with bluetooth using timeslot mechanism, it means that the stack guarantee us full access to the radio and the CPU for some time (currently set to 1ms) extendable as long as possible. The problem with that is that it would means breaking-up read/write operation of the memory in small asynchronous chunk (there is no OS in the nrf51 so this would need to be implemented as a state machine). This would be the best solution but it not obvious to implement.
We have never gotten the time to get into solving this problem yet. When it is solved we can add a GUI to program the memories to the client and do fun stuff like adding driver data to the memories to personalize each deck.
/Arnaud