Go to advanced search

by okenido
Mon Jun 03, 2019 1:54 pm
Forum: General discussion
Topic: Why 80 pin IDE cable fried my Pi
Replies: 11
Views: 325

Re: Why 80 pin IDE cable fried my Pi

That cable WAS DESIGNED and INTENDED FOR USE with IDE drives and NOT FOR THE RPi GPIO. It was your fault for using it, that fried your RPi, not the fault of the designer of the cable. saw this in one article: "....somebody put raw eggs in a microwave oven and it exploded upon turning on....causing ...
by okenido
Mon Jun 03, 2019 1:46 pm
Forum: General discussion
Topic: Why 80 pin IDE cable fried my Pi
Replies: 11
Views: 325

Re: Why 80 pin IDE cable fried my Pi

well, no problem with that, but creating interconnections in a cable with separate pins is misleading in my opinion, such things should be done on the board so the cables stays as standard as possible... but okay !
by okenido
Mon Jun 03, 2019 1:09 pm
Forum: General discussion
Topic: Why 80 pin IDE cable fried my Pi
Replies: 11
Views: 325

Why 80 pin IDE cable fried my Pi

Hello, I know, NOW, that 80 wires IDE cables have pins 2, 19, 22, 24, 26, 30, 34 and 40 shorted together. Misleading design in my opinion... http://lyberty.com/tech/hard_drives/80-conductor-large.jpg But even knowing that, I'm not sure WHY it fried my PI. I provide 5V to pins 2 and 4, and they have ...
by okenido
Sun May 19, 2019 4:55 pm
Forum: General discussion
Topic: Atmega328p + RPI : ICSP programming providing 3.3V
Replies: 6
Views: 208

Re: Atmega328p + RPI : ICSP programming providing 3.3V

we're talking about providing 3.3V though the header pin while everything else is NOT powered -- the raspberry doesn't get its main 5V input You have lost me there. If the RPi does not get its main 5V input, where does the 3.3V output come from? sorry, i talk about providing 3.3V unintentionally wh...
by okenido
Sun May 19, 2019 1:25 pm
Forum: General discussion
Topic: Atmega328p + RPI : ICSP programming providing 3.3V
Replies: 6
Views: 208

Atmega328p + RPI : ICSP programming providing 3.3V

Hi, I made a circuit which uses a raspberry pi and an atmega328p microcontroller, which gets its power from rpi's 3.3V pin. I added an ICSP header so we can program the microcontroller directly on board after everything was assembled. Normally, I would program it before connecting the raspberry pi, ...
by okenido
Wed Apr 03, 2019 12:47 am
Forum: Bare metal, Assembly language
Topic: Setting ARM/core/RAM frequency has no effect
Replies: 2
Views: 731

Re: Setting ARM/core/RAM frequency has no effect

Okay so it took a while to figure it out, I had literally forgot about this problem. I found it wasn't working because my RPI was undervolted ! (power supply lower than 4.8V). I knew it was undervolted so I hid the little bolt icon, but I haven't tought that it could prevent the CPU from running hig...
by okenido
Tue Feb 26, 2019 2:02 pm
Forum: General discussion
Topic: 64-bit operating system
Replies: 350
Views: 60438

Re: 64-bit operating system

I don't think 64 bit is worth for the raspberry pi 3, i did several tests in bare metal and AARCH64 was slower by 15-20%, probably due to the fact that pointers are twice the size compared to 32 bit so the memory bandwidth is more easily saturated. Even my code using NEON instructions performed wors...
by okenido
Fri Jan 18, 2019 4:54 pm
Forum: General discussion
Topic: Obfuscation thread
Replies: 34
Views: 4315

Re: Obfuscation thread

Some forums (or is that fora) have automatic locking of unloved threads after some months of them sleeping. That would so help to prevent the necroing of ancient crap on here. You're so wrong. This topic is about general things, it's never outdated or finished. Like most topics. I don't know but, y...
by okenido
Fri Jan 18, 2019 4:41 pm
Forum: General discussion
Topic: Obfuscation thread
Replies: 34
Views: 4315

Re: Obfuscation thread

Found it with a google search.
Better than re-creating the same posts over and again.
by okenido
Fri Jan 18, 2019 4:13 pm
Forum: General discussion
Topic: Obfuscation thread
Replies: 34
Views: 4315

Re: Obfuscation thread

I don't quite much agree with all of you. We know offline softwares are all crackable, but the point of obfuscation and other techniques is to make them LESS EASY to crack. If you run a business, making your product harder to reverse engineer gives you an advantage over the product which can be dupl...
by okenido
Wed Jan 09, 2019 11:56 am
Forum: Bare metal, Assembly language
Topic: Setting ARM/core/RAM frequency has no effect
Replies: 2
Views: 731

Setting ARM/core/RAM frequency has no effect

Hello, I'm using the mailbox interface of the RPI (https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface) in a bare metal app to change frequency settings of arm/core/ram but none of them seems to make the processing faster or slower. Asking the mailbox for the current frequency re...
by okenido
Tue Dec 18, 2018 3:21 pm
Forum: Official Foundation Display
Topic: New display with better quality possible ?
Replies: 10
Views: 1426

Re: New display with better quality possible ?

I've thought about the CM3 but unfortunately it's not very competitive price-wise, and designing a custom baseboard is far from easy (and adds additionnal cost). The problem here is getting a nice quality touch display and interfacing it with the RPI through its ribbon connector.
by okenido
Tue Dec 18, 2018 2:17 pm
Forum: Official Foundation Display
Topic: New display with better quality possible ?
Replies: 10
Views: 1426

New display with better quality possible ?

Hello, I'd like to know if the Raspberry Foundation is planning to make a new model of the 7 inch touch screen. The current one has a quite poor image quality compared to the current displays we find in products like smartphones, tablets and tactile laptops. Problems sorted by importance from high t...
by okenido
Tue Nov 06, 2018 3:22 pm
Forum: Bare metal, Assembly language
Topic: Optimizing data structures for NEON
Replies: 4
Views: 2238

Re: Optimizing data structures for NEON

I already include this header but it's for the intrinsics which I use manually. Does it make sense to include it by default ? I use those extra types, like uint16x8_t which is a block of eight 16 bit unsigned ints that can be mapped to a single NEON 128 bit register and processed by a single instruc...
by okenido
Mon Nov 05, 2018 3:27 pm
Forum: Bare metal, Assembly language
Topic: Optimizing data structures for NEON
Replies: 4
Views: 2238

Re: Optimizing data structures for NEON

Thanks ! I re-wrote critical parts of my code with manual NEON intrinsics and got +50% performance. It seems GCC is simply unable to vectorize things when it gets more complicated than the obvious parallel addition/multiplication. It's not very pretty since my object get split into multiple variable...
by okenido
Mon Oct 22, 2018 2:57 pm
Forum: Bare metal, Assembly language
Topic: Touch screen sensitivity for official 7" screen (rpi-ft5406)
Replies: 8
Views: 2472

Re: Touch screen sensitivity for official 7" screen (rpi-ft5406)

https://image.noelshack.com/fichiers/2018/43/1/1540219891-rpi.png I noticed with a multimeter that those I2C pins on the display PCB are directly connected to the FT5406, but the RPI doesn't need them since it controls it through the ribbon cable. Is it possible to disable the automatic touch scree...
by okenido
Sun Oct 21, 2018 9:15 pm
Forum: Bare metal, Assembly language
Topic: Touch screen sensitivity for official 7" screen (rpi-ft5406)
Replies: 8
Views: 2472

Re: Touch screen sensitivity for official 7" screen (rpi-ft5406)

Sorry I edited my last post, seeing I2C communication with the chip isn't directly possible.

Maybe the problem about slow touch presses being ignored is related to some sensitivity parameter too. Anyway, thanks for taking my request into account ;)
by okenido
Sun Oct 21, 2018 7:41 pm
Forum: Bare metal, Assembly language
Topic: Touch screen sensitivity for official 7" screen (rpi-ft5406)
Replies: 8
Views: 2472

Re: Touch screen sensitivity for official 7" screen (rpi-ft5406)

Another problem I noticed : If my finger approach the screen slowly before entering in contact, the touch screen doesn't detect the press. If i'm slow enough, I can get to a quite high pressure with my finger and move it on a few centimeters on the screen without triggering any event. That doesn't h...
by okenido
Sun Oct 21, 2018 1:03 pm
Forum: Bare metal, Assembly language
Topic: Touch screen sensitivity for official 7" screen (rpi-ft5406)
Replies: 8
Views: 2472

Touch screen sensitivity for official 7" screen (rpi-ft5406)

Hello, I noticed all touch screens supported by the Raspberry Pi in boot/overlays/ have a sensitivity parameter (see https://github.com/raspberrypi/firmware/tree/master/boot/overlays ), but there is no such option for the official 7" inch screen which uses a FT5406 controller: Name: rpi-ft5406 Info:...
by okenido
Mon Oct 15, 2018 10:33 am
Forum: Bare metal, Assembly language
Topic: Optimizing data structures for NEON
Replies: 4
Views: 2238

Optimizing data structures for NEON

Hello, I want to help GCC generating vectorized neon code for my calculations that works on a lot of structs. (All the same, just a lot of them). Currently the code look like that : struct thing{ int a, b;}obj[4]; obj[0].a += obj[0].b; obj[1].a += obj[1].b; obj[2].a += obj[2].b; obj[3].a += obj[3].b...
by okenido
Sat Oct 13, 2018 9:46 am
Forum: Bare metal, Assembly language
Topic: FT5406 Touch coordinate corruption
Replies: 25
Views: 4696

Re: FT5406 Touch coordinate corruption

Circle is using the original algorithm for detecting touch screen events from the Linux driver. There has been an update to the Linux driver later, which fixes a spurious event issue from the touch screen. This fix has not been applied to the Circle driver yet. I will check this soon. Applying thos...
by okenido
Sat Oct 13, 2018 9:13 am
Forum: Bare metal, Assembly language
Topic: FT5406 Touch coordinate corruption
Replies: 25
Views: 4696

Re: FT5406 Touch coordinate corruption

Okay I found what happens. All the Release events are catch, but sometimes a duplicated Move event is also generated just before, and it has swapped X/Y coordinates. Here is the example #28 from Circle's framework running : https://image.noelshack.com/fichiers/2018/41/6/1539421710-img-20181013-11074...
by okenido
Fri Oct 12, 2018 6:56 pm
Forum: Bare metal, Assembly language
Topic: Bare metal graphics : hardware acceleration ?
Replies: 11
Views: 3823

Re: Bare metal graphics : hardware acceleration ?

It doesn't work that well finally. I get random color corruptions. If I move the vdup call before the x/y loop and use only vst1 to fill the screen I got even more colour corruptions. What I'm doing wrong ? Is neon core/thread safe ? I was thinking about interrupts in my program, that could make use...
by okenido
Fri Oct 12, 2018 1:06 pm
Forum: Bare metal, Assembly language
Topic: FT5406 Touch coordinate corruption
Replies: 25
Views: 4696

Re: FT5406 Touch coordinate corruption

Maybe my problem is related to yours. I'm using the Circle framework to access the touch screen, it's using this code : https://github.com/rsta2/circle/blob/master/lib/input/touchscreen.cpp I call Update() 60 times per sec as suggested, and it's working well except sometimes it misses a Touch Releas...
by okenido
Thu Oct 11, 2018 5:11 pm
Forum: Bare metal, Assembly language
Topic: Bare metal graphics : hardware acceleration ?
Replies: 11
Views: 3823

Re: Bare metal graphics : hardware acceleration ?

Very nice, i'll take a look at it if I need even more performance.

I wrote this little code and it works very well :

Code: Select all

asm volatile
			(
				"   vdup.16 q8, %1\n\t"
				"   vst1.16  {d16-d17}, [%0]!\n\t"

				: "=r"(pDest), "=r"(color)
				: "0"(pDest), "1"(color)
			);

Go to advanced search