brubetinha

Hi Bruna,
 
I'm using EXT4. According to my research (but I'm not an expert to be completely sure) good quality cards already do wear leveling internally and so it is kind of hard to wear out the memory. 
 
See this topic, for example: http://electronics.stackexchange.com/questions/27619/is-it-true-that-a-sd-mmc-card-does-wear-levelling-with-its-own-controller
 
The hard part is to make sure you're buying authentic SD cards... here in Brazil I'm having some difficulties - the last approach we took was to contact Sandisk directly in order to have supplier references and increase our chances to get original Sandisk or Kingstom ones. I've checked few we bought on Brazilian's ebay like site and they were not original (I could corrupt them in the first power loss try or even before!) This page helped me a lot on testing SD cards: http://www.bunniestudios.com/blog/?page_id=1022(but there is no 100% method).
 
Regards
Luiz

Hi,
 
I am not an expert in that domain, but I am also interested in RS-485 communication on Allwinner based SBC.
For your information OMAP is a series of CPU for Texas Instrument, so the OMAP UART driver is only used on these CPUs. The BeagleBone Black is made of an OMAP processor for example.
 
What I found is that RS-485 drivers only exists for few devices likes the AT91 series from Atmel, OMAP serias from Texas Instruments, i.MX28 series from Freescale (now NXP)...
 
One solution is to use the RTS signal of the UART to drive the RS-485 direction. But I have measured a 3 ms delay for the turnaround on a H3 based Orange Pi One, that delay is too big for my application.
 
So I am finally using a USB-RS485 adapter from Devantech which manage the RS-485 direction automatically. I did not measured the turnaround yet but it worked well for my tests and they advertise a 3uS delay turnaround. But note that this module cost two times the price of my Orange Pi One
http://www.robot-electronics.co.uk/htm/usb_rs485_tech.htm

Hello Luiz!
 
Thank you for sharing, we were facing the same problems here and recently we decide to change to SD card. Our idea is to create 3 partitions: 1 read only, 1 "data" partition and 1 backup partition, but we are concern about the maximum write cycles. So we thought about using a different filesystem, like JFFS2 or UBIFS rather than EXT2/3/4, even we knowing that they aren't meant for block devices. Did you try somenthing like this ? What do you think about it ?
 
Thanks
 
Bruna

Hello guys,
 
This is not a question, but a feedback I think may be useful for some.
 
I have a cubieboard 2 server application using Igor's armbian running for 8 months in several places (~40 installations). In my application:
 
The OS in installed on NAND Armbian 3.8 + wheezy + kernel 3.4.107 There is a postgresql instance running, writing approx. 25kB/s average (not constant) Ordered data mode journaling on From time to time I've problems on clients with system corruption (not only the database, but the whole filesystem - sometimes I couldn't event boot the cubieboard anymore, had several kernel panics and more weird stuff like thousands of filesystem errors at once on fsck). Problems usually (but not always) appear after unclean shutdowns, due to power loss.
 
Recently I've decided to give a try and test the system running on the SD card. For my surprise, it is working smoothly without corruptions!. I've now created a read-only partition for the system and isolated the database, logs and other stuff (tomcat, /var/*, among others) on a "data" partition. I've conducted a test here with "pseudo-aleatory" automatic power downs during the system regular operation - I could turn it down (uncleanly) more than 200 times on different moments without problems, even on the database.
 
I'm not sure if moving to the SD card is the key point here (or the ro only partition + armbian 4.7 + jessie + kernel 3.4.110), but as I've seen other threads in other forums questioning the NAND drivers and physical bus routing on cubieboard2, I think it will be nice to share my experience and recommend users with heavier read-write requirements not to use the cubieboard 2 NAND!
 
If any of you had similar (or completely different) experiences, please share - I'm curious to have feedback and maybe reach a definitive answer about the problems I've been experiencing here (which costs a lot of money to us on tech support calls). Now, on SD card, it is rock solid - I couldn't break the system, even trying it hard!
 
Thanks
Luiz