Will this card reader work same way as the openlog from page 1 ?
would love to log engine values to read and understand the Digifant Chip and can send data to Digifant Online for improved chip values.
Support Micro SD Card (<=2G), Micro SDHC card (<=32G) (high-speed card)
The level conversion circuit board that can interface level is 5V or 3.3V
Power supply is 4.5V ~ 5.5V, 3.3V voltage regulator circuit board
Communication interface is a standard SPI interface
4 M2 screw positioning holes for easy installation
Size: 4.1 x 2.4cm
A total of six pins (GND, VCC, MISO, MOSI, SCK, CS), GND to ground, VCC is the power supply, MISO, MOSI, SCK is the SPI bus, CS is the chip select signal pin
3.3V regulator circuit:
LDO regulator output 3.3V as level converter chip, Micro SD card supply
Views: 3064 • Comments: 12 • Write comments
Welche connector brauchst mann fur MD01 , am photo sind kurze und lange und gekrümmte.
In partslist wird nur die info von Reichelt BL und SL klären das um mann oder weiblich version geht.
Sollte diese handmassig abgeändert werden ?
Views: 61 • Comments: 3 • Write comments
ARM vs AVR8: yes, thats a stuff for another thread.
but let me say a few words to ARM-Boards: these ARM MCUs are a hell faster than the ATMega2560. but are they better suited for our application on the multidisplay pcb?
We want data acquisition at a constant frequency (for example 12Hz) and need also some advanced hardware features like input capture interrupts.
btw: Data acqusition at defined time intervals is a sort of real-time computing (RTC).
Its much easier to implement this on a dedicated mcu where I'm responsible (and in control) of the complete running firmware.
An ARM board (raspi, cubietruck etc) has a lot more computing power but it runs a full bloat operation system and is therefore not as predictable as the ATMega which is 100% under my control.
Imagine what happens under high system load on an operating system: maybe the linux kernel is busy with memory swapping and therefore the multidisplay process wouldnt get processor time even though it its needed at this point because we want to acquire our data at a constant rate.
Yes, there are some possibilities like RT-Linux to handle such realtime tasks. But it would be a hell more complex than running dedicated firmware on a simple MCU which is controlled 100% by our firmware.
In my opinion, the low-level data acquisition should always be done on a dedicated ATMega.
An ARM board could be an extension to the ATMega instead of a replacement.
btw: ARM extension is already in use: the android smartphone. it handles the visualization and data storage (mUI app).
If we're talking about an in-car graphical OLED / TFT display (i.e. dashboard) with expensive animations the mUI app could be moved from the smartphone to an in-car raspberry pi or similiar ARM board.
Views: 358 • Comments: 18 • Write comments